MCP Registryのモデレーションポリシーとスパム対策の仕組み

MCP Registryのモデレーションは、「かなり許容的(quite permissive)」と自称するほど削除基準が狭い設計です。削除するのは違法コンテンツ・マルウェア・スパム・完全に壊れたサーバーの4種類だけで、低品質なサーバーや脆弱性のあるサーバー、同じ機能の重複サーバーは残ります。

もう1つ押さえておきたいのがstatusのdeletedです。FAQには「公開したサーバーは取り消せない」とありますが、Issue #104は2026年4月24日に完了扱いでクローズされ、公開者が自分でdeletedにする経路が入っています。ライブのAPIで見ると、deletedはスパム削除の印とは限りません。

なぜMCP Registryは「ほぼ何でも許す」設計なのか

MCP Registryが持つのは、npm・PyPI・Dockerといったパッケージレジストリを指すメタデータだけです。サーバーのコードやバイナリは持ちません。たとえばweather-mcpというnpmパッケージがあれば、Registryには「weather v1.2.0」をnpm:weather-mcpに対応づける記録が載ります。

コードを持たない以上、中身の審査はできません。aboutページは、セキュリティスキャンを上流のパッケージレジストリと、下流のアグリゲーター(サーバーのマーケットプレイスなど)に任せると書いています。Registry自身が受け持つのは、名前空間の認証とメタデータの保管です。

ポリシーは、この前提を免責として書いています。モデレーションの保証はなく、利用者は「ほぼ無審査」と考えるよう求められます。削除基準に当たるのに、まだ消えていないコンテンツが残っている可能性もあります。スクレイピングで集めたデータを扱う側は、この前提を織り込む必要があります。

アグリゲーターとの距離感を示す数字もあります。アグリゲーターは1時間に1回程度の間隔で取得し、自前のデータストアに保存する想定で、Registryは稼働時間とデータの耐久性を保証しません。ホストアプリ(Claude Codeなど)がRegistryを直接読む使い方も想定されておらず、マーケットプレイス経由で使う前提です。非公開のサーバーも対象外で、社内ネットワークのmcp.acme-corp.internalのようなサーバーは、自前のレジストリに載せる方針です。

Anthropicが運営するConnectors Directoryは対照的で、提出時にポリシー適合を自動スキャンし、ツール設計・機能品質・API所有権といった基準を設けています。人手の審査を受ける掲載もあります。同じMCPサーバーでも、掲載先で確認の度合いが違います。Directory側の基準はAnthropic Connectors Directoryとはにあります。

なお、このポリシーが適用されるのはregistry.modelcontextprotocol.ioの公式Registryだけです。サブレジストリ(同じAPI仕様を実装して独自に配信するアグリゲーター)には、それぞれ別のポリシーがありえます。特定のサブレジストリの掲載内容に疑問があるなら、問い合わせ先は公式Registryではなくそのサブレジストリです。

何が削除され、何が残るのか

スパムの例は3つ挙がっています。同じサーバーを別名義で何度も投稿するもの、マーケティング文を固定で返すだけのサーバー、実装と無関係なマーケティング文で説明欄を埋めたサーバーです。いずれも「実体がないのに掲載枠だけ使う」型で、品質の低さを理由にした削除ではありません。

削除されない側で目を引くのは、脆弱性それ自体が削除理由にならない点です。脆弱性の検出は、コードを持つ上流のパッケージレジストリの仕事に切り分けられています。

削除されたサーバーはAPIからどう見えるのか

削除といってもレコードは消えません。サーバーのstatusを"deleted"に更新するだけで、メタデータはAPIから引き続き読めます。メタデータそのものが違法な場合のような極端なケースに限り、上書きや消去も行われます。

statusが取る値はactive・deprecated・deletedの3つです。更新できるのはstatusと、理由を書くstatusMessageだけで、それ以外のメタデータは公開後に変えられません。アグリゲーター向けのページは、各サーバーのstatusを最新に保つよう勧めています。

一覧APIにはinclude_deletedというクエリがあり、既定はfalseです。つまり、何も付けずに一覧を取るとdeletedのサーバーは出てきません。ただしupdated_sinceを付けた場合は常にtrueとして扱われるため、差分を追うアグリゲーターには削除の事実が届きます。

実際の中身は、updated_since付きで先頭100件を取り、statusを数えると分かります。

curl -s 'https://registry.modelcontextprotocol.io/v0.1/servers?limit=100&include_deleted=true&updated_since=2025-01-01T00:00:00Z'

deletedの5件のうち、statusMessageが付いていた2サーバーの理由は、違反ではなく整理でした。1つは別名への改名、もう1つは別の名前空間への統合で、次のような記録です。

{
  "status": "deleted",
  "statusChangedAt": "2026-05-30T08:19:59.670246Z",
  "statusMessage": "Consolidated onto ai.deepledger/mcp (DeepLedger)"
}

アグリゲーター向けのページは、deletedは通常ポリシー違反を示すと説明しています。上の記録は、その読み方がすべてには当てはまらないことを示す例です。deletedを機械的に「スパムか悪意あり」とラベル付けすると、改名や統合で身を引いただけの正規のサーバーまで巻き込みます。statusMessageがあれば、そこまで読んで判断する余地があります。

公開してしまったサーバーを取り消せるのか

ここは公式ページ同士で記述がずれています。FAQの「サーバーを削除・unpublishできますか」には、現時点では不可で、議論が続いているとあります。その議論のIssue #104は、2026年4月24日に実質的に完了としてクローズされました。クローズのコメントには、次の3点が出荷済みとして書かれています。

• 公開者がmcp-publisherのステータス操作、またはステータス更新のAPIで、自分のサーバーをdeletedにできる(セルフサービスの取り下げ)
• 例外的なケースのための、管理者による上書き(取り消した削除を元に戻せない保護つき)
• 何を削除するかのポリシーの文書化

ステータス更新のAPIには、特定バージョンだけを更新する経路と、サーバーの全バージョンを一括で更新する経路があります。どちらもpublishまたはeditの権限を持つRegistry JWTを要求します。versionの文字列とメタデータは公開後に不変(npmに近い扱い)なので、できるのはあくまでstatusの変更です。公開者が使える手段にレコードを物理的に消すものはなく、取り下げたサーバーもinclude_deletedを付ければ読めます。

公開前のミスの重さは、この仕様に由来します。メタデータの誤りを直すには、一意のversionで新しいserver.jsonを公開し直すしかありません。しかもバージョン文字列がセマンティックバージョニングとして解釈できる場合、並べ替えで「最新」が決まります。

Issue #104には、この仕組みが招いた実例が残っています。試験公開で1.0.0を載せてしまったプロジェクトが、その後0.y.zの番号で正しく公開し直しても、1.0.0のほうが優先され続ける、という報告です。2025.6.18のようなゼロ詰めのない日付形式は、versioningのページが注意を促している書き方でもあります。最初のバージョン番号をどう置くかは、後から変えにくい判断です。

CIで公開を自動化するなら、タグを打つ前に検証を済ませる流れが前提になります。具体的なワークフローはMCP RegistryへGitHub Actionsで自動公開する手順にまとめています。

状況別の窓口: 通報・異議・脆弱性・取り下げ

窓口は、困っている内容によって別々です。

通報は2段構えです。Registryはコードのスキャンをしないので、スパムの実体を止めるのは配布元の仕事になり、Registry側のIssueは掲載を外す判断のための記録です。

脆弱性の窓口は、Registry自身の脆弱性にだけ向いています。個々のサーバーの脆弱性は削除理由にならないため、報告先もRegistryではありません。FAQが案内するSECURITY.mdはMCPコミュニティ共通のもので、Registry専用の窓口ではない点にも注意が要ります。

名前空間認証を軸にしたスパム対策の3層

スパム対策は、削除という事後対応だけではありません。公開前の仕組みを含めて、次の3層が用意されています。

3つ目は、1つ目と2つ目をすり抜けたものを拾う最後の砦です。なお、独自のカスタムメタデータ(_metaのpublisher-providedの領域)にも4KB(4096バイトのJSON)の上限があり、超えると公開が失敗します。

さらに厳しいレート制限、AIによるスパム検知、コミュニティからの通報機能が検討されています。いずれも、現状の3層に含まれない将来の施策です。

名前空間認証が止めるのは、他人の名前を名乗る投稿です。自分の名前空間で作る大量のスパムまでは止められません。そこを補っているのが、削除という事後対応と、アグリゲーター側の独自判断です。

登録は品質のシグナルにならない

低品質や重複のサーバーを削除しないという方針は、「Registryに載っていること」が品質を示さないことを意味します。同じ機能のサーバーが何十件並んでいても、Registryはどれが優れているかを判定しません。

実質的な品質のシグナルは、レジストリの外側に出ます。アグリゲーターは_metaに独自のキーで、ユーザー評価・ダウンロード数・セキュリティスキャンの結果といった情報を載せられます。公式のRegistryに残っているサーバーが、特定のアグリゲーターの検索には出てこないことがあっても、それは矛盾ではありません。モデレーションの役割分担が、そうなるように設計されているからです。

まとめ

Registryが保証するのは、名前空間の持ち主が本物かどうかと、メタデータの保管までです。サーバーを選ぶ側は、品質や安全性の判断をアグリゲーターと上流のパッケージレジストリに求める必要があります。またdeletedは「違反」の印というより「掲載を外した」という状態で、statusMessageまで見て読むものです。

公開する側は、バージョン文字列と名前の付け方が後から変えにくい点を踏まえて、最初の公開に臨むことになります。MCP自体の基本仕様はMCPとはで解説しています。