MCP Registryのモデレーションポリシーとスパム対策の仕組み
MCP Registryが違法コンテンツ・マルウェア・スパムだけを削除する理由と、公開後にunpublishできない制約、名前空間認証によるスパム防止の仕組みを確認します。
MCP Registryのモデレーションポリシーは、「かなり許容的(quite permissive)」と説明されるほど削除基準が狭いことが特徴です。削除対象になるのは違法コンテンツ・マルウェア・スパム・完全に機能しないサーバーの4種類だけで、低品質なサーバーやセキュリティ脆弱性を抱えるサーバー、同じ機能を持つ重複サーバーは削除されません。この記事では、なぜこの設計になっているのか、削除の実装がどう動くのか、そしてスパム対策が何に依存しているのかを順に確認します。
なぜMCP Registryは「ほぼ何でも許す」設計なのか
MCP Registryは、サーバーの実体(コードやバイナリ)を持たず、npm・PyPI・Dockerといったパッケージレジストリへのポインタとなるメタデータだけを保持します。実体を持たない以上、コード自体の深いセキュリティ審査や品質審査はMCP Registryの役割ではなく、下流のパッケージレジストリと、さらに下流のアグリゲーター(サーバーマーケットプレイス等)に委ねるという設計方針が採られています。
これは「コミュニティが支える運営で、能動的なモデレーション能力には限りがある」ためです。npm・PyPI・Dockerのような上流パッケージレジストリや、GitHub MCP Registryのような下流のサブレジストリがより踏み込んだモデレーションを担うことを前提にしているため、本来この方針のもとで削除されるべきコンテンツが、まだ削除されずに残っている可能性があるという前提も明記されています。スクレイピングしたデータを扱う側はこの前提で扱う必要があります。
Anthropicが運営するConnectors Directoryは、これとは対照的に提出前審査(ツール設計・機能品質・API所有権などの基準)を課す仕組みです。同じMCPサーバーでも、掲載先によって審査の厳しさがまったく異なります。Connectors Directory側の審査基準はAnthropic Connectors Directoryとはにまとめています。
なお、このモデレーションポリシーが適用されるのはregistry.modelcontextprotocol.ioで運営される公式MCP Registryだけです。サブレジストリ(MCP Registryと同じAPI仕様を実装して独自にサーバーを配信するアグリゲーター)は、それぞれ独自のモデレーションポリシーを持つことがあります。特定のサブレジストリに掲載されている内容に疑問がある場合は、公式ではなくそのサブレジストリの運営に直接問い合わせる必要があります。
削除される4条件と、あえて削除されない5条件
モデレーションポリシーが線を引いているのは、次の表の2グループです。
| 分類 | 該当する内容 |
|---|---|
| 削除される | 該当する内容違法コンテンツ(わいせつ・著作権侵害・ハッキングツールを含む) |
| 削除される | 該当する内容意図を問わないマルウェア |
| 削除される | 該当する内容スパム(同一サーバーの別名義での複数回投稿、マーケティング文のみを返す固定応答サーバー、実装と無関係なマーケティング文で説明欄を埋めたサーバーなど) |
| 削除される | 該当する内容完全に機能しないサーバー |
| 削除されない | 該当する内容低品質・バグの多いサーバー |
| 削除されない | 該当する内容セキュリティ脆弱性を持つサーバー |
| 削除されない | 該当する内容他のサーバーと同じ機能を提供するサーバー |
| 削除されない | 該当する内容アダルトコンテンツを提供・含むサーバー |
削除されない側のリストで目を引くのは、セキュリティ脆弱性それ自体は削除理由にならないという点です。脆弱性の扱いは、コードの実体を持つ上流パッケージレジストリでのセキュリティスキャンに委ねられており、MCP Registry自身はメタデータの正しさと名前空間の認証に責任範囲を絞っています。
削除されたサーバーはどう扱われるか — statusフィールドの実装
サーバーが削除されるとき、MCP Registryはメタデータそのものを消去するわけではありません。サーバーのstatusフィールドを"deleted"に更新するだけで、メタデータ自体はAPI経由で参照可能な状態のまま残ります。アグリゲーターはこのstatus変化を見て、自分のインデックスからサーバーを外すかどうかを判断する仕組みです。
メタデータそのものが違法な場合など、極端なケースに限っては上書き・完全消去も行われます。ただし基本の削除フローは「ステータスを立てるだけで、記録は残す」という設計です。
削除に異議がある場合は、GitHub Issueでサーバー名と削除基準に該当しないと考える理由を添えて申し立てる、appeal(異議申し立て)の窓口が用意されています。申し立て先は、モデレーションポリシー自体を公開しているmodelcontextprotocol/registryリポジトリで、スパム通報用のAbuse report:Issueとは別枠のIssueとして起票します。GitHub Issueでのやり取りは公開の記録として残るため、判断の経緯を後から追いやすいという利点もあります。逆に、unpublish(自主的な取り消し)を望む場合の窓口は用意されていません(GitHub Issue #104)。削除できるのは運営側の判断による場合に限られます。
利用者側からスパムを通報する手順
削除の判断は運営側が行いますが、通報自体は利用者からもできます。スパムや悪意あるサーバーを見つけたときの手順は次の2段階です。
- 上流のパッケージレジストリへ通報する: npm・PyPI・DockerHubなど、そのサーバーが実際に配布されているパッケージレジストリの通報窓口を使う
- GitHub Issueを立てる: MCP Registryのリポジトリに
Abuse report:で始まるタイトルのIssueを作成する
セキュリティ脆弱性そのものは削除対象にならないと説明しましたが、MCP Registryの実装自体に脆弱性を見つけた場合は扱いが別です。この場合はMCPコミュニティ全体のSECURITY.mdに従って報告する経路になり、個別サーバーの脆弱性報告とは窓口が分かれています。個別サーバーの脆弱性についての公式な報告先は明記されていませんが、MCP Registry自身がサーバーのコードを審査しない設計である以上、実務上はSECURITY.mdではなく当該サーバーの配布元(npmやDockerHub、GitHubリポジトリのIssue)へ直接届けることになります。窓口が分かれているのは、Registryの実装そのものの脆弱性と、Registryが仲介するだけのサーバーの脆弱性とで、責任を持つ主体が違うからです。ここで案内されるSECURITY.mdは、MCP Registry固有の窓口ではなく、MCPコミュニティのリポジトリ群で共有される報告窓口である点にも注意してください。
名前空間認証を軸にしたスパム対策の3層
MCP Registryのスパム対策は、削除という事後対応だけに頼っているわけではありません。公開前の仕組みとして次の3層があります。
- 名前空間認証: GitHub・DNS・HTTPのいずれかの方式でサーバー名の名前空間の所有権を証明しないと公開できません。誰でも任意のサーバー名を名乗って大量投稿することを防ぐ、最初の関門です
- 文字数制限とバリデーション: 自由入力欄には厳格な文字数上限と正規表現による検証がかかります
- 手動でのtakedown: 運営者が手動でスパム・悪意あるサーバーを削除できる、最後の砦です
今後の対策としては、より厳格なレート制限・AIによるスパム検知・コミュニティからの通報機能が検討されています。裏を返せば、レート制限・AIによるスパム検知・コミュニティからの通報機能の3つは、まだ実装されていません。
この事後対応の緩さを補っているのが、アグリゲーター側の独自の判断です。MCP Registry自身が低品質・重複機能のサーバーを削除しない一方、個々のアグリゲーターは自分のマーケットプレイスで表示するかどうかを独自に決められます。公式のRegistryには残り続けても、特定のアグリゲーター上では検索結果に出てこない、という状態は矛盾ではなく、モデレーションの役割分担がそう設計されている結果です。
「削除しても消えない」設計は開発者の運用をどう変えるか
MCP Registryのモデレーションは事後対応が基本で、しかも削除はstatusを立てるだけでメタデータ自体は残ります。加えてFAQでは、公開済みのバージョンはunpublish(取り消し)ができないことも明記されています。この2つを組み合わせると、公開前に間違いに気づくコストと、公開後に間違いに気づくコストの非対称性が普段のパッケージ公開よりも大きいと分かります。
npmのようなパッケージレジストリなら公開の取り消しに一定の猶予がありますが、MCP Registryでは巻き戻しの手段そのものが存在しません。GitHub Actionsでタグpushをきっかけに公開を自動化する場合は、公開ステップの手前にテストとビルドの検証を必ず挟む設計が、通常のCI/CDパイプライン以上に効いてきます。自動化していない手作業での公開でも、この不可逆性そのものは変わりません。
もう1つ導ける結論があります。低品質・重複機能のサーバーをあえて削除しないという方針は、裏を返せば「登録されること自体は品質のシグナルにならない」ということです。同じ機能のサーバーが何十件並んでいても、MCP Registry自身はどれが優れているかを判定しません。利用者から見た実質的な品質シグナルは、アグリゲーターが_metaに載せるユーザーレーティングやセキュリティスキャン結果のような、レジストリの外側にある付加情報の側に移ります。
まとめ
MCP Registryのモデレーションは、違法コンテンツ・マルウェア・スパム・非機能サーバーの4種類だけを削除対象にする、意図的に狭い基準で運用されています。低品質・脆弱性あり・重複機能のサーバーはあえて削除せず、深い審査は上流のパッケージレジストリと下流のアグリゲーターに委ねる構造です。削除はstatusフィールドの更新にとどまりメタデータは残り、公開済みバージョンの取り消しもできないため、公開前の検証コストは他のパッケージエコシステムより重く見積もっておく必要があります。スパム対策の実務側は名前空間認証が中心で、その具体的な設定方法はMCP RegistryへGitHub Actionsで自動公開する手順にまとめ、MCP自体の基本仕様はMCPとはで解説しています。