MCP Registryとは — Anthropicも支える公式サーバーカタログ

MCP Registryとは何か

MCP Registryは、MCPサーバーの公式カタログです。Anthropic・GitHub・PulseMCP・Microsoftなどが支える、共同のプロジェクトです。Claude Codeに入れるサーバーを探す窓口というより、サーバー開発者が登録し、マーケットプレイスが取り込む上流の台帳にあたります。

載せているのは、公開されたMCPサーバーのメタデータです。サーバーのコードやバイナリは預からず、「どこに実体があるか」「どう起動するか」を記述したメタデータだけを持ちます。

メタデータは server.json という標準フォーマットで保存されます。中身は、サーバーの一意な名前(例: io.github.user/server-name)、実体の所在(npmパッケージ名やリモートサーバーのURL)、起動手順(コマンド引数や環境変数)、説明文や対応機能といった発見用データの4種類です。

プレビュー段階のプロダクトで、正式リリース(GA)より前に破壊的変更やデータリセットが起こり得ます。サーバーごとにバラバラだった起動コマンドや環境変数の書式を server.json の1つの型に揃える点が、このカタログの役割です。

Claude Codeは、Registryを直接は見ていない

Claude Codeの利用者が最初に知っておきたいのは、claude mcp add がRegistryを検索する機能ではないことです。v2.1.287の claude mcp --help を作業用の空ディレクトリで実行すると、サブコマンドは add / add-json / get / list / login / logout / remove などです。Registryを検索・参照するサブコマンドはありません。claude mcp add が受け取るのは、サーバーの名前と、接続先(URLまたは起動コマンド)です。

claude mcp add --scope project --transport http weather-demo https://example.invalid/mcp

プロジェクトスコープで追加すると、作業ディレクトリに .mcp.json が生成されます。実際の中身は次のとおりです。

{
  "mcpServers": {
    "weather-demo": {
      "type": "http",
      "url": "https://example.invalid/mcp"
    }
  }
}

ここで保存されるのは、利用者が付けた名前と接続先だけです。Registryに載っている server.json の情報(登録名・パッケージ種別・環境変数の定義)は引き継がれません。しかも、Registryの登録名をそのまま名前に使うことはできません。

claude mcp add --scope project io.github.alice/weather-server -- npx -y weather-mcp

Invalid name io.github.alice/weather-server. Names can only contain letters, numbers, hyphens, and underscores.

Claude Codeの名前は英数字・ハイフン・アンダースコアに限られ、. と / を含む逆引きDNS形式は受け付けません。Registryの io.github.alice/weather-server を見つけたら、weather-server のような短い名前を自分で付け直します。起動コマンドか接続URLも、READMEやRegistryのメタデータから手で写します。作成した .mcp.json に登録されたサーバーは、承認するまで接続されません(claude mcp get の表示は ⏸ Pending approval)。

NotionやSlackのように接続手順がまとまった記事を参考にする場合も、名前は自分で決めます。企業自身が配布するdraw.io公式MCPサーバーでも同じです。追加後の認証管理はclaude mcp login/logoutが受け持ちます。

メタデータは誰の手を経て利用者に届くか

Registryを取り巻く関係者は、パッケージレジストリ・サーバー開発者・アグリゲーター・他のレジストリ・ホストアプリケーション(Claude Codeなどのクライアント側)の5種類です。届く順に4段で示すと、ホストアプリが最後尾に来ます。

メタデータは意図的に無味乾燥(unopinionated)に保たれ、付加価値はアグリゲーター側の仕事です。Registryは認証なしで読み取れるREST APIを持ちますが、稼働率とデータの耐久性の保証はありません。

登録の対象は、OSS・クローズドソースを問いません。ただしプライベートサーバーは対象外です。mcp.acme-corp.internal のような社内ネットワーク限定のサーバーは登録できません。npx -y @acme/mcp --registry https://artifactory.acme-corp.internal/npm のように社内限定のパッケージレジストリで配るものも同様です。公開したい場合は、自前のプライベートレジストリを立てます。

そのとき、Registryが定めるOpenAPI仕様を実装すれば、ホストアプリ側の既存の対応をそのまま使えます。一方でRegistry自体のコードベースは自前運用を想定しておらず、フォークした場合の保守・運用は自分で負う形です。

npm・PyPIとの関係はどうなっているか

対応するパッケージ種別は、npm・PyPI・NuGet・Cargo(Rust)・Docker/OCIイメージ・MCPB(GitHub/GitLabリリース経由の実行バイナリ)の6種類です。種別ごとに検証方法が異なり、対応する配布元も限られます。npmなら公開レジストリ(https://registry.npmjs.org)のみ、PyPIなら https://pypi.org のみ、Cargoならcrates.ioのみです。

Docker/OCIが対象にする配布元は次の5つです。

• Docker Hub(docker.io)
• GitHub Container Registry(ghcr.io)
• Google Artifact Registry(*.pkg.dev)
• Azure Container Registry(*.azurecr.io)
• Microsoft Container Registry(mcr.microsoft.com)

社内向けの配布元で配るサーバーが登録できないのは、この制約の裏返しです。

登録するパッケージが自分のものであることは、種別ごとの目印で確かめられます。

Cargoのcrates.ioはHTMLコメントを除去するため、mcp-name は見える文字で書く必要があります。MCPBのハッシュはRegistryでは検証されませんが、MCPクライアントがインストール前に検証します。

Rustで書いたサーバーには、Cargo(registryType: cargo)とMCPB(registryType: mcpb)の2通りの出し方があります。Cargoは利用者側に rustup と cargo install を要求し、MCPBはビルド済みバイナリなのでツールチェーンが要りません。「Rustのツールチェーンを持たない人にも使ってほしい」ならMCPBが向きます。

信頼性とセキュリティはどこまで担保されているか

Registryが担保するのは「名前の持ち主」までです。パッケージの中身の安全性は担保しません。

セキュリティスキャンは委譲されています。npm・PyPI・Docker Hubといった配布元が脆弱性検出を行い、アグリゲーターが追加のチェックやレーティングを足す余地が残されています。

運営の姿勢は、モデレーションポリシーを見るといっそう明確です。削除対象は、違法なコンテンツ、マルウェア、スパム、動作しないサーバーに絞られます。逆に、品質が低い・バグがある・脆弱性を抱える・他と同じ機能のサーバーは、削除の対象外とされています。削除はメタデータの status を "deleted" にする形で行われ、APIからは引き続き見えます。この点でモデレーションは最小限で、掲載されていること自体は品質や安全性の保証になりません。

スパム対策は、名前空間認証の要求、自由記述欄の文字数制限と正規表現によるバリデーション、運営による手動削除の3本柱です。レート制限の強化やAIによるスパム検知、コミュニティ報告の仕組みも検討中とされています。

名前空間認証が効くのは、確認の手間が「登録者に聞く」から「公開情報を見る」に変わる点です。io.github. で始まる名前ならGitHubアカウント、com.example 型ならドメインの持ち主を確認できます。

Anthropic Connectors Directoryとどう違うのか

Anthropicは自社でもConnectors Directoryを運営しています。掲載基準や登録手順は上記の記事にあります。層で言えば、MCP Registryは前節の流れの上流にあるメタデータストアです。Connectors DirectoryはAnthropicが運営する別の一覧で、Registryとは層が違います。

サーバーを登録するには

公式のクイックスタートでは、mcp-publisher というCLIでメタデータを公開します。先に、サーバーのパッケージをnpmなどの配布元へ公開しておく必要があります。Registryはコードを預からないためです。

認証には、GitHubアカウントかドメインを使います。名前空間を確認できないと、io.github.<username>/* のような名前で公開できません。

自分でサーバーを作るなら、APIで重複を調べられる

サーバーを自作する前に、同じ用途のものが既に登録されていないかをAPIで調べられます。GET /v0.1/servers は登録済みサーバーを一覧します。search で名前の部分一致検索、limit と cursor でページ送り、updated_since で更新分だけの絞り込みができます。search はアグリゲーター向けの公式ドキュメントではなく、OpenAPI仕様に載っているパラメータです。説明文やキーワードの検索ではなく、名前の部分一致です。

curl "https://registry.modelcontextprotocol.io/v0.1/servers?search=weather&limit=5"

特定のサーバーの履歴は GET /v0.1/servers/{serverName}/versions、版の指定は .../versions/{version}(latest が使えます)です。

URLパスの serverName はURLエンコードが必須で、io.modelcontextprotocol/everything は io.modelcontextprotocol%2Feverything と書きます。

server.jsonのスキーマは日付で版管理される

プレビュー段階という位置付けは、いま登録する server.json のスキーマ自体が将来変わり得る、という意味でもあります。公式ドキュメントの例では、$schema フィールドに日付入りのURLが使われています。https://static.modelcontextprotocol.io/schemas/2025-12-11/server.schema.json の形です。

公開作業を自動化するなら、スキーマのバリデーションをCIに入れておくと、変更に気付きやすくなります。参照する側にとっても、GA前の search を含むAPIの仕様は細部が変わり得ます。

まとめ

Registryに載っているかは名前の持ち主を確かめる材料になりますが、中身の安全性は配布元とアグリゲーター側の情報で判断する、という分担です。サーバーを公開する側は、名前空間の所有確認が要る点と、プライベートサーバーを置けない点が判断の分かれ目になります。