MCP Registryとは何か — 公式サーバーカタログの仕組み

MCP Registryとは何か

MCP Registryは、公開されているMCPサーバーのメタデータを一元管理するカタログです。運営を支えるのはAnthropic・GitHub・PulseMCP・Microsoftという、MCPエコシステムの主要な担い手4社です。サーバーのコードやバイナリそのものは扱いません。「どこに実体があるか」「どう起動するか」を記述したメタデータだけを預かるのが役割です。

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

MCP Registryはプレビュー段階のプロダクトです。正式リリース(GA)より前には、破壊的変更やデータリセットが起こり得ます。試験的に触るのはよくても、唯一の情報源として本番運用に組み込むにはまだ早い段階です。

MCP Registryが提供する4つの機能

MCP Registryが提供する内容は、次の4つに絞られます。

実務でいちばん効いてくるのは最後の「標準化」です。サーバーごとにバラバラだった起動コマンドや環境変数の書式が、server.json という1つの型に揃います。読み手が違うツールを使っていても、同じファイルを見れば起動条件がわかる状態になります。

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

MCP Registryを「もう1つのパッケージレジストリ」だと捉えると、設計意図を見誤ります。npm・PyPI・Docker Hubのようなパッケージレジストリは、コードとバイナリそのものをホストします。MCP Registryはそこへのポインタとなるメタデータだけをホストします。役割が違う、と考えるのが正確です。

たとえば weather-mcp というパッケージがnpmで公開されているとします。MCP Registry側では「weather というサーバーのv1.2.0は npm:weather-mcp に対応する」という対応関係を記録するだけです。実体のコードはnpm側に置いたままで、MCP Registryが二重にホストすることはありません。

対応するパッケージ種別は現時点でnpm・PyPI・NuGet・Cargo(Rust)・Docker/OCIイメージ・MCPB(GitHub/GitLabリリース経由の実行バイナリ)の6種類です。コミュニティの要望次第で、対応レジストリは今後も増える可能性があります。

誰がMCP Registryを直接使うのか

パッケージレジストリとの役割分担を踏まえたうえで、MCP Registryを取り巻く関係者は、次の4種類です。

サーバー開発者は、OSS・クローズドソースを問わず登録できます。ただし条件が1つあります。インストール方法が公開されている(npmパッケージやDockerイメージが公開レジストリにある)か、サーバー自体が公開アクセス可能であることです。プライベートサーバーには対応していません。社内ネットワーク限定のサーバー(mcp.acme-corp.internal のような例)や、社内限定のパッケージレジストリで配布されるサーバーは登録できません。これらを公開したい場合は、自前のプライベートレジストリを立てるのが選択肢になります。

ダウンストリームアグリゲーター、つまりMCPサーバーのマーケットプレイスのような立場が、MCP Registryの主な想定利用者です。メタデータは意図的に無味乾燥(unopinionated)に保たれています。評価やレーティングのような付加価値は、アグリゲーター側が独自に足す設計です。更新頻度は「1時間に1回程度の低頻度なポーリング」が想定されています。

他のMCPレジストリは、MCP Registryが定めるOpenAPI仕様を実装することで、同じインターフェースを提供できます。ただしMCP Registry自体のコードベースは自前運用(self-hosting)を想定した設計ではありません。フォークした場合の保守・運用は自己責任になります。

MCPホストアプリケーション(クライアント側のアプリ)は、MCP Registryを直接参照する想定ではありません。ダウンストリームのマーケットプレイスなど、MCP RegistryのOpenAPI仕様に準拠した別のレジストリ経由で消費する設計です。この一段クッションを挟む構造が、MCP Registry自体をシンプルに保つ理由になっています。

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

MCP Registryは、パッケージの中身までは検証しません。信頼の仕組みは主に3層に分かれます。

サーバー名のネームスペース認証が最初の防波堤です。サーバー名は逆引きDNS形式(io.github.username/server や com.example/server)を取り、検証済みのGitHubアカウントかドメインに紐づきます。この方式によって、他人の名前を騙って登録することができなくなります。認証方式にはGitHubアカウントによるOAuth認証、ドメインのDNS TXTレコードによる認証、ドメイン上のファイル設置による認証の3種類があり、選んだ方式がそのままサーバー名の名前空間の形式を決めます。

セキュリティスキャンは委譲されています。npm・PyPI・Docker Hubといった配布元のレジストリが独自の脆弱性検出を行い、ダウンストリームのアグリゲーターがさらに追加のチェックやレーティングを実装する余地を残す設計です。MCP Registry自身が担うのはネームスペース認証とメタデータのホスティングまでで、コードの中身の安全性審査は範囲外です。

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

ネームスペース認証が効くのは、確認の手間が「登録者に聞く」から「公開情報を見る」に変わる点です。io.github. で始まる名前なら、そのGitHubアカウントの活動履歴や所属Organizationを外部から確認できます。com.example のような逆引きDNS形式なら、ドメインのWHOIS情報や運営会社と突き合わせられます。自己申告のプロフィール文よりも、検証可能な手がかりが1つ増えるという理解が実態に近いです。

Anthropic Connectors Directoryとどう違うのか

Anthropicは自社でもConnectors Directoryを運営しています。掲載基準や登録手順の詳細は別記事に譲りますが、性格の違いは押さえておく価値があります。MCP Registryはクライアントを問わない汎用のメタデータストアで、Claudeに限らずどのMCPホストからも参照され得る土台です。対してConnectors Directoryは、Claude向けにキュレーションされた一覧という位置付けです。両者は競合ではなく層が違います。1つのサーバーがMCP Registryに登録され、かつConnectors Directoryにも掲載される、という重複も起こり得ます。

Claude Codeでサーバーを使う側は何を得るか

MCP Registryの主眼はサーバー開発者側の公開フローですが、利用者側にも実利があります。あるMCPサーバーを claude mcp add する前に、そのサーバーの名前がネームスペース認証を通っているか(io.github. で始まるならGitHubアカウント、com.example のような逆引きDNS形式ならドメイン所有者)を確認できます。NotionやSlackのように広く使われているサーバーであっても、READMEに書かれた自己申告だけでなく、第三者が検証可能な所有権の裏付けがあるかどうかは、見知らぬサーバーを実行する前の最低限のチェックポイントになります。

もちろん、ネームスペース認証は「このアカウント・ドメインの持ち主が登録した」ことを示すだけで、コードの安全性そのものを保証するものではありません。名前の出どころが確認できることと、中身が安全であることは別の話です。この区別を混同しないことが、MCP Registryを実務で使うときの前提になります。

もう1つ実務で押さえておきたいのが検索APIの存在です。MCP RegistryはサーバーをJSON形式で検索できるREST APIを公開しており、名前やキーワードで既存の登録状況を照会できます。自分でMCPサーバーを作る前に、同じ用途のサーバーが既に登録されていないかをこのAPI経由で確認すれば、車輪の再発明を避けられます。ダウンストリームのアグリゲーターだけでなく、開発者自身がこのAPIを叩いて重複調査に使う、という使い方も成立します。

プレビュー段階のserver.jsonスキーマは公開後に変わり得る

プレビュー段階という位置付けは、単なる注意書きではありません。破壊的変更やデータリセットが起こり得るということは、いま登録した server.json のスキーマ自体が将来変わる可能性があることを意味します。実際、server.json の $schema フィールドには 2025-12-11 のような日付ベースのスキーマバージョンが埋め込まれており、スキーマ自体がバージョン管理の対象であることが構造からも読み取れます。

サーバー開発者としては、公開作業を自動化するにしても、スキーマの変更を検知できる仕組み(CIでのバリデーションなど)を合わせて用意しておくと、GA後の移行で慌てずに済みます。エンドユーザー側としても、プレビュー段階のインフラである以上、GA後にサーバー名の扱いや検索APIの仕様が細部で変わり得る前提で参照するのが安全です。

まとめ

MCP Registryは、MCPサーバーのコードではなくメタデータだけを扱うカタログです。npm・PyPIのようなパッケージレジストリとは役割が別で、実体は既存の配布先に置いたまま、発見と検証の窓口だけを一本化します。プライベートサーバーには対応せず、信頼の担保はネームスペース認証が中心です。プレビュー段階のプロダクトなので、公開・登録の具体的な手順に進む前に、この設計思想を押さえておくと迷いが減ります。次のステップとして、server.json の書き方と、公開に必要な認証方式の選び方を確認してください。