MCPサーバーが1万個を超えた。目当ての1つをどう見つけるか

この記事のポイント

MCPサーバーが1万個を超えた。問題は、その中から自分が欲しいサーバーをどうやって見つけるかだ。

月間SDKダウンロードは9,700万回。対応クライアントは300以上。2025年のOpenAI正式採用を皮切りに、Microsoft、AWS、Linux Foundationと移管先まで決まった規格がここまで拡大すると、「どのサーバーが何をできるか」を人間が目視で確認するのは現実的でなくなる。エージェントが自律的にサーバーを発見して接続する仕組みが必要になる——その答えとして提案されているのが、Server Cardsだ。

発見問題の構造

現状のMCP接続フローはシンプルだが、手作業に依存している。ユーザーがサーバーURLを手動で設定ファイルに書き、クライアントが初期化リクエストを送り、初めてサーバーの能力（tools/resources/prompts）が分かる。接続してみなければ何ができるか分からない設計だ。

これは1,000サーバー時代には許容できた。1万サーバーを超えると、カタログを人間が管理するコストが際限なく膨れ上がる。エージェントが「このドメインはMCPサーバーを持っているか」「持っているとすれば何ができるか」を事前に確認できる仕組みが求められていた。

Server Cardsの仕組み

SEP-2127として現在GitHubでPRレビュー中のServer Cards仕様は、/.well-known/mcp/server-card.jsonというURLにサーバーメタデータを置くルールを定める。エージェントはこのエンドポイントをGETするだけで、接続前にサーバーの詳細を把握できる。

JSONスキーマの概形はこうだ。

{
  "$schema": "https://modelcontextprotocol.io/schemas/server-card/v1.0.json",
  "version": "1.0",
  "protocolVersion": "2025-11-25",
  "serverInfo": {
    "name": "example-mcp-server",
    "version": "2.1.0",
    "description": "Example MCP server providing database access tools"
  },
  "transport": {
    "type": "streamable-http",
    "url": "https://api.example.com/mcp"
  },
  "capabilities": {
    "tools": true,
    "resources": true,
    "prompts": false,
    "sampling": false
  }
}

エージェントの自動発見フローは4ステップに整理される。ドメインURLを受け取り、/.well-known/mcp/server-card.jsonをGET、transport/capabilitiesを確認してから、MCPセッションを初期化する。接続試行の前に「このサーバーは自分が求める能力を持っているか」を確認できるため、無駄な接続試行が減る。

類似仕様との比較

.well-knownパターン自体は新しくない。robots.txtはクローラーへのアクセス制御宣言、OAuth2の.well-known/openid-configurationは認証エンドポイントの自動発見に使われてきた。Server Cardsはそのパターンを「AIエージェントによるサーバー発見」に応用したものだ。

OpenAPIとの違いも明確だ。OpenAPIはREST APIのエンドポイント・パラメータ・レスポンス形式を記述するが、Server CardsはMCP固有の能力宣言に特化している。MCPプロトコル上で何ができるかを、MCPクライアントが直接解釈できる形式で伝える。

先行実装として参考になるのがReplicate。2026年2月に独自のサーバー自動発見機能を実装しており、標準仕様に先んじて「エージェントが接続前に確認できる」体験の有効性を実証している。

残る疑問

仕様自体は合理的だが、実運用上の問いはいくつか残る。

server-card.jsonの内容が実際のサーバー能力と乖離した場合、エージェントはどう扱うか。能力の更新頻度とキャッシュ戦略をどう設計するか。認証が必要なプライベートサーバーの発見フローはどうなるか——これらはSEP-2127のPRコメント欄でも議論が続いている段階だ。

Linux Foundation移管後のガバナンス体制のもとで、Server Cards標準化は2026年ロードマップの筆頭課題に位置づけられている。Streamable HTTPのステートレス化、エンタープライズ向け監査ログ、A2Aパターンとの統合と並んで、MCPエコシステムが「接続する規格」から「発見して接続する規格」へと成熟する最初の一手がこれだ。

1万個を超えたサーバーの中から目当てのものを見つける仕組みが固まれば、エージェントが自律的にツールを調達するシナリオはぐっと現実に近づく。仕様がどこまで合意されるかは、今後数週間のPRレビューにかかっている。

MCPサーバーが1万個を超えた。目当ての1つをどう見つけるか

発見問題の構造

Server Cardsの仕組み

類似仕様との比較

残る疑問

関連記事

Sources