MCP Registryのアグリゲーターとは — サーバーマーケットプレイスの裏側

MCPサーバーを探すときに実際に目にするサーバー一覧やマーケットプレイスの多くは、MCP Registryそのものではなく、その先にいる「アグリゲーター」が作った画面です。アグリゲーターはMCP Registryの生データを定期的に取得し、ユーザーレーティングやセキュリティスキャンといった付加価値を載せて配信する下流の消費者です。この記事では、アグリゲーターがMCP Registryのどの部分を使い、どう実装されているかを順に確認します。

「MCP Registry」という言葉が指すものは4通りある

アグリゲーターの立ち位置を理解する前に、用語の指す範囲を先に押さえておきます。公式FAQは「MCP Registry」という呼び方に4種類の意味があると説明しています。

この記事で扱う「アグリゲーター」は、多くの場合この表の3番目「MCP registry(サードパーティが実装したサービス)」として振る舞います。同じ「MCP Registry」という言葉でも、公式のサービスを指しているのか、それを模した第三者の実装を指しているのかで意味がまったく違う点に注意が必要です。

アグリゲーターはMCP Registryの何を利用しているか

MCP Registryは、Anthropic・GitHub・PulseMCP・Microsoftといった主要なMCPエコシステムの関係者が支える公式のメタデータリポジトリです。運営に複数の企業が関わっていること自体が、特定の1社に依存しない中立なデータ源として設計されている根拠になっています。

MCP Registryはサーバーのコードやバイナリそのものではなくnpmパッケージ名やリモートサーバーURLといったメタデータへのポインタだけを保持します。マーケットプレイスのUIやレーティング、検索性の高い一覧画面といった、利用者が実際に触れる体験を作っているのはMCP Registry自身ではなく、その上に立つアグリゲーターの役割です。

MCP Registryはアグリゲーター向けに、認証不要の読み取り専用REST APIを提供しています。アグリゲーター側は1時間に1回程度の頻度でこのAPIを定期的にスクレイピングし、取得したデータを自分のデータストアに保持しておくことが期待されています。MCP Registry自体は稼働率やデータの永続性を保証しないため、アグリゲーターが自前でデータを持っておく設計は前提条件でもあります。

公式ドキュメントは、MCPホストアプリケーション(Claude CodeのようなMCPクライアント)がMCP Registryを直接叩くことを想定していないとも明記しています。ホストアプリケーションが実際に参照するのは、MCP Registryのデータを取り込んだ下流のマーケットプレイスやサブレジストリの側です。つまりアグリゲーターは「あると便利な中間層」ではなく、利用者接点として設計上想定されている主たる経路にあたります。

MCP Registryが扱うのは公開アクセス可能なサーバーだけで、社内ネットワーク限定のプライベートサーバーはそもそも登録できません。アグリゲーターが目にするデータは、すでに「公開されているサーバーだけ」に絞り込まれています。

サーバー一覧の取得(GET /v0.1/servers)

MCP Registry REST APIのベースURLはhttps://registry.modelcontextprotocol.ioで、アグリゲーターが主に使うのは次の3エンドポイントです。

サーバー名にはio.github.username/serverのようにスラッシュを含む形式が使われるため、URLパスに埋め込むときはio.modelcontextprotocol/everythingをio.modelcontextprotocol%2FeverythingのようにURLエンコードする必要があります。

GET /v0.1/serversはカーソルベースのページネーションに対応しています。

curl "https://registry.modelcontextprotocol.io/v0.1/servers?limit=100"

レスポンスのmetadata.nextCursorをそのまま次のリクエストのcursorパラメーターに渡せば、続きのページを取得できます。

curl "https://registry.modelcontextprotocol.io/v0.1/servers?limit=100&cursor=com.example/my-server:1.0.0"

更新分だけを取りたい場合は、RFC 3339形式のタイムスタンプをupdated_sinceパラメーターに渡します。

curl "https://registry.modelcontextprotocol.io/v0.1/servers?updated_since=2025-10-23T00:00:00.000Z"

差分だけを取得できるため、1時間おきのスクレイピングでも全件取得を繰り返さずに済みます。

このAPIが認証不要かつ無料で公開されていること自体、アグリゲーターという仕組みが成立するための前提条件です。もし取得に認証や利用契約が必要だったなら、独自のマーケットプレイスを作ろうとする第三者は限られたはずです。認証不要のREST APIという設計が、結果として複数のアグリゲーターが並立できる状態を支えています。

サーバーのstatusをどう追跡するか

サーバーのメタデータは基本的に不変ですが、statusフィールドだけは例外で、"deprecated"や"deleted"のように後から更新されます。"deleted"は多くの場合、MCP Registryのモデレーションポリシーに違反したことを示すシグナルで、スパムやマルウェア、違法コンテンツの疑いがあることを意味します。公式ガイドはアグリゲーターに対して、自分がキャッシュしている各サーバーのstatusを最新の状態に追随させ、"deleted"になったサーバーは自分のインデックスから外すことを推奨しています。

ただし、この追随は推奨であって強制ではありません。モデレーション側の削除はstatusを立てるだけの仕組みなので、アグリゲーターが同期を怠れば、削除済みのサーバーがそのアグリゲーター上にはまだ表示され続けることがあります。

statusには"deleted"のほかに"deprecated"もあります。両者は扱いが異なります。"deleted"はモデレーション違反の疑いを示すシグナルで一覧から外す対象になりますが、"deprecated"は「まだ動くが後継への移行を促したい」という開発者側の意思表示です。アグリゲーターの実装としては、"deprecated"のサーバーは一覧から消すのではなく、非推奨であることが分かる表示に切り替える方が、ユーザーへの情報提供として適切です。

サブレジストリとして振る舞う — 独自メタデータの注入

アグリゲーターの一部は、MCP Registryが定義するOpenAPI仕様をそのまま実装し、「サブレジストリ」として振る舞うことができます。サブレジストリとして実装すると、MCPホストアプリケーション(クライアント)が標準化されたインターフェース経由でそのアグリゲーターのデータを直接消費できるようになります。

公式のMCP Registryのコードベース自体はセルフホスティング向けに設計されておらず、運営チームもフォークしての自前運用をサポート対象にしていません。フォークして使うこと自体は禁止されていませんが、その場合は運用と保守を独力で担う前提になります。このため、サブレジストリを作る側は公式コードをフォークするより、公開されているOpenAPI仕様を自前で実装し直すアプローチが選ばれやすくなっています。

サブレジストリの仕様は、_metaフィールドを通じて独自のメタデータを注入することを許可しています。

{
  "_meta": {
    "com.example.subregistry/custom": {
      "user_rating": 4.5,
      "download_count": 12345,
      "security_scan": {
        "last_scanned": "2025-10-23T12:00:00Z",
        "vulnerabilities_found": 0
      }
    }
  }
}

公式は、この独自メタデータを"com.example.subregistry/custom"のようにサブレジストリを表すキーの配下にまとめることを推奨しています。ユーザーレーティングやダウンロード数、セキュリティスキャン結果といった、MCP Registry本体が持たない付加情報はこの_meta経由で載せる設計です。

上の例にsecurity_scanというキーが含まれているのは偶然ではありません。MCP Registry自体はセキュリティスキャンを行わず、その役割を上流のパッケージレジストリと下流のアグリゲーターに委ねています。つまりセキュリティスキャン結果は、アグリゲーターが代わりに担っているからこそ_metaに載せる価値がある付加情報です。

アグリゲーターの入れ替わりは、なぜ一様に反映されないのか

MCP Registryは「1時間に1回程度」というスクレイピング頻度を推奨事項として示すだけで、義務付けてはいません。さらにstatusの同期自体も推奨にとどまり、稼働率やデータ永続性の保証もありません。この3つを重ねると、同じサーバーの同じ変更(更新・非推奨化・削除)が、アグリゲーターごとにまったく違うタイミングで反映されることになります。

あるマーケットプレイスでは削除済みと表示されているサーバーが、別のマーケットプレイスではまだ現役として一覧に残っている状況は、バグではなくこの設計から自然に生じる状態です。開発者側から見ると、自分のサーバーのstatusを変更したときに「反映されるまでの時間」を1つの数字で語ることはできず、利用者がどのアグリゲーター経由でサーバーを見つけたかによって体験が変わる、という前提を持っておく必要があります。

まとめ

アグリゲーターはMCP Registryの生メタデータに、レーティングやセキュリティスキャンといった付加価値を載せて配信する下流の消費者です。認証不要のREST API・カーソルベースのページネーション・updated_sinceによる差分取得が土台になっており、statusフィールドの追随とOpenAPI仕様への準拠(サブレジストリ化)が、アグリゲーターごとの実装の違いを生みます。同期は推奨止まりで義務ではないため、削除や更新の反映タイミングはアグリゲーターごとにばらつきます。公開の起点になるGitHub Actionsでの自動化手順はMCP RegistryへGitHub Actionsで自動公開する手順、MCPというプロトコル自体の全体像はMCPとはにまとめてあります。