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

MCPサーバーの一覧やマーケットプレイスには、MCP Registryのデータを取り込んだ「アグリゲーター」が作る画面があります。アグリゲーターはMCP Registryのデータを定期的に取得し、ユーザーレーティングやセキュリティスキャンといった付加価値を載せて配信する下流の消費者です。

マーケットプレイスを作る側にとっては取得の実装が、使う側にとっては「一覧に載っているサーバーをどこまで信用できるか」が論点になります。この記事は両方の視点から、アグリゲーターがMCP Registryのどの部分を使い、何を保証されていないのかを扱います。

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

公式FAQは「MCP Registry」という呼び方を4種類に区別しています。

アグリゲーターが自前のAPIを公開して他のクライアントに使わせるなら、3番目の「MCP registry」にあたります。公式のサービスを指しているのか、第三者の実装を指しているのかで、同じ言葉でも意味が変わります。

データはどの順路でユーザーに届くか

MCP Registryは、Anthropic・GitHub・PulseMCP・Microsoftなど、MCPエコシステムの主要な関係者が支える公式のメタデータリポジトリです。コードやバイナリは持たず、保持するのはnpmパッケージ名やリモートサーバーURLといったメタデータだけです。

「MCP Registryは主にアグリゲーターに消費されることを想定している」というのが設計上の位置づけです。

登録できるのは公開サーバーに限られます。インストール方法が公開されている(公開レジストリ上のnpmパッケージやDockerイメージなど)か、サーバー自体が公開アクセス可能であることが条件です。クローズドソースでも構いません。mcp.acme-corp.internalのような社内ネットワーク限定のサーバーや、社内パッケージレジストリ経由のインストールは対象外で、そうしたサーバー向けには自前のプライベートレジストリを立てる方法が示されています。登録の名前空間認証についてはMCP Registryの認証で詳しく扱っています。

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

MCP Registry REST APIのベースURLはhttps://registry.modelcontextprotocol.ioです。アグリゲーターが使うエンドポイントは次の3つで、このうちGET /v0.1/serversが最も多く叩かれる想定です。

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

一覧はカーソルベースのページネーションです。最初のページはlimitで件数を指定して取ります。

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

レスポンスのmetadataにはcount(そのページの件数)とnextCursorが入ります。nextCursorをそのままcursorパラメーターに渡すと、続きのページが取れます。

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

2回目以降の取得は、更新分だけで足ります。RFC 3339形式のタイムスタンプをupdated_sinceに渡します。

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

差分だけを取れるので、1時間に1回程度という推奨頻度でも、全件取得を繰り返さずに済みます。

実装で前提にしておく点が2つあります。1つ目は、MCP Registryが稼働率とデータの永続性を保証しないことです。取得したデータは自分のストアに持っておく必要があります。2つ目はプレビュー段階であることで、GA前に破壊的変更やデータのリセットが起こりうると、各ドキュメントの冒頭に注記されています。

一覧にあるサーバーをどこまで信用してよいか

使う側の視点では、この節が最も重要です。MCP Registryのモデレーションは意図的に緩く、消費者は「最小限、場合によってはまったく行われていない」ものとして扱うよう求められています。運営は限られた体制のコミュニティプロジェクトで、詳しい審査はnpmやPyPIなど上流のパッケージレジストリと、下流のサブレジストリに任されています。

「脆弱性があるサーバーは消えない」という点は、アグリゲーターの価値が出る場所でもあります。MCP Registry自体は名前空間認証とメタデータの保管に専念し、コードのセキュリティスキャンは行いません。その役割は上流のパッケージレジストリと、下流のアグリゲーターやマーケットプレイスに委ねられています。MCP Registryに載っていることは、安全の裏付けにはなりません。

スパム対策は、名前空間認証(GitHub・DNS・HTTPのいずれかのチャレンジ)、自由記述欄の文字数制限と形式検証、運営による手動削除の組み合わせです。AIによるスパム検知やコミュニティからの通報機能は今後の検討課題とされています。通報は、元になっているパッケージレジストリ(npm・PyPI・Docker Hubなど)への不正報告と、レジストリのGitHubリポジトリでAbuse report: から始まるタイトルのissueを立てる、の2本立てです。ポリシーの詳細はMCP Registryのモデレーションとスパム対策にあります。

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

サーバーのメタデータは基本的に不変です。変更するときは、一意のバージョン文字列を付けた新しいserver.jsonを公開します。公開済みのバージョンのメタデータは、npmと同様に変更されません。この仕組みはMCP Registryのバージョニングに詳しい説明があります。

例外はstatusフィールドで、"deprecated"や"deleted"のように後から更新されます。アグリゲーターは、キャッシュしている各サーバーのstatusを最新に保つことが推奨されています。

"deleted"は、多くの場合モデレーションポリシーに違反したことを示し、スパム、マルウェア、違法コンテンツの疑いがあるサーバーに付きます。ここで見落としやすいのが削除の中身です。削除といってもstatusを"deleted"にするだけで、メタデータはAPIから引き続き取得できます。アグリゲーターが追随しなければ、削除済みのサーバーが一覧に残ります。

メタデータそのものが違法な場合など、極端なケースに限っては、運営がメタデータを上書きまたは消去することもあります。

公式のMCP Registryには、開発者が自分のサーバーを削除したり非公開にしたりする機能は今のところありません。モデレーションでサーバーを削除するときは、運営がstatusを"deleted"にします。

サブレジストリには、独自のモデレーション方針を持つものもあります。つまり、同じサーバーでも一覧ごとに載る基準が違いえます。

追随は推奨であって強制ではありません。"deleted"のサーバーを自分のインデックスから外すかどうかは、アグリゲーターの判断です。

サブレジストリとして振る舞う

アグリゲーターのうち、MCP Registryが定義するOpenAPI仕様を実装したものを「サブレジストリ」と呼びます。

公式の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"のように、サブレジストリを表すキーの配下に置くことが推奨されています。上の例のsecurity_scanは、先に見たとおり、MCP Registry本体が担わないスキャンをアグリゲーターが肩代わりしたものです。

_metaには、開発者側が書き込む領域もあります。公開時に_meta.io.modelcontextprotocol.registry/publisher-provided以下に入れたカスタムメタデータは、レジストリに保存されます。サイズは4096バイトのJSONが上限で、超えると公開に失敗します。サブレジストリ用のキー(com.example.subregistry/custom)と公開者用のキー(io.modelcontextprotocol.registry/publisher-provided)は、_metaの中で別のキーになります。

反映タイミングがアグリゲーターごとに違うのはなぜか

取得頻度は「1時間に1回程度」という推奨にすぎず、statusの追随も推奨にとどまります。さらに、稼働率とデータ永続性の保証もありません。この3つが重なるため、同じサーバーの更新・非推奨化・削除が、アグリゲーターごとにまったく違うタイミングで反映されます。

あるマーケットプレイスで削除済みと表示されるサーバーが、別のマーケットプレイスでは現役のまま残る。これはバグではなく設計から生じる状態です。開発者から見れば、statusを変えたときの「反映までの時間」は1つの数字では言えません。利用者がどの経路でサーバーを見つけたかによって、見える状態が変わります。

まとめ

マーケットプレイスを作るなら、statusの追随とデータの自前保持を最初から設計に入れる形になります。サーバーを選ぶ側は、掲載が品質や安全の保証ではない前提で、アグリゲーター側の審査や評価を併せて見る選択肢があります。公開の起点になるGitHub Actionsでの自動化手順はMCP RegistryへGitHub Actionsで自動公開する手順、MCPというプロトコル自体の全体像はMCPとはにあります。MCP Registryの全体像はMCP Registryとはが詳しいです。