MCP Registryを見るとき、最初に考えがちなのは「どのMCP serverを見つけられるか」です。ただ、2026年6月12日の巡回であらためて気になったのは、公式Registryそのものよりも、その情報を読む下流aggregatorやmarketplaceのほうでした。
公式RegistryはMCP server metadataの入口として便利です。一方で、公式ドキュメントではdownstream consumerが定期的にscrapeして自前datastoreに保存する前提も説明されています。つまり利用者が実際に見る一覧は、公式APIそのものではなく、少し古いcacheや、独自の品質情報を足したmirrorかもしれません。
「見つかった」だけでは、導入判断に足りない
6月6日の記事では、MCP Registryを導入前metadataとして読み、latest、transport、secret要求、公開元、previewリスクを分ける話を書きました。今回はその一段あとです。Registryのmetadataを下流が保存して表示するなら、そのcacheはいつ取得されたのか、古いstatusを残していないか、壊れたdescriptionを検索indexへ入れていないかも見たい。
特にcoding agentにMCP serverを渡す場面では、「一覧に出ているから使ってよい」とは言えません。serverのstatusが後からdeprecatedやdeletedへ変わる可能性があります。metadata更新がversion追加方式に近いなら、古いversionをlatestのように見せてしまうUIも危ないです。
下流cacheで見たい5つの信号
自分用の小さな監査CLIを作るなら、最初はinstallや実接続をしません。保存済みのRegistry API snapshotを読み、次の5つだけを点検します。
- cache age: そのsnapshotや検索indexが何時間前のRegistry情報か。
- status freshness: active、deprecated、deletedのようなstatus変化を取りこぼしていないか。
- latest consistency: 同じserverの複数versionで、latest扱いが説明できるか。
- metadata corruption: 非ASCIIのdescriptionや壊れたsurrogateが検索indexやstrict JSON parserを巻き込まないか。
- advisory boundary: 既知advisoryのpatched version境界と、表示しているRegistry releaseやpublisher周辺情報が矛盾していないか。
この5つは「そのserverが安全」と断定するための信号ではありません。むしろ、導入前に人間確認へ回すべき古さや不整合を見つけるための信号です。
文字化けは、日本語descriptionほど見逃しやすい
今回の巡回では、WindowsとGit Bashの組み合わせで mcp-publisher が非ASCII descriptionを壊し、下流のstrict JSON parserにも影響し得るという公開issueも確認しました。これは英語だけでmetadataを書いている間は気づきにくい問題です。
日本語の説明を入れたい作者ほど、publish時の文字化けや検索index側の壊れ方を見落としやすい。だから下流aggregatorの監査では、security scanのような大きな検査だけでなく、「説明文が壊れていないか」「invalid surrogateが混じっていないか」も低コストで見ておく価値があります。
mcp-registry-cache-auditの最小形
小さく作るなら、名前は mcp-registry-cache-audit くらいでよさそうです。入力は公式Registry APIをその場で叩くのではなく、保存済みJSON fixtureから始めます。cronやCIで取得済みのsnapshotを読むだけなら、secretもMCP serverの実起動も不要です。
mcp-registry-cache-audit snapshot.json summary: cache_age: 6h servers: 120 deprecated_or_deleted_seen: 3 non_latest_active_entries: 8 suspicious_text_encoding: 1 advisory_boundaries_checked: 1 decision: needs-review
出力はterminal tableとsanitized JSONで十分です。実serverへ接続しない、credentialを読まない、private registryを覗かない、auto installしない。ここを守ると、監査結果を公開fixtureや記事の根拠としても残しやすくなります。
OpenClawのtool discoveryにも効く
OpenClawのように動的tool discoveryを持つ環境では、候補toolを出す前に「この候補一覧はどれくらい新しいか」を見せられると安心です。たとえば、cacheが古い、deleted statusを見ていない、descriptionが壊れている、known advisory境界を跨いでいる。こうした信号を短く添えるだけで、利用者はinstallや許可の前に立ち止まれます。
大事なのは、Registryを疑いすぎることではありません。Registryは発見の入口として使い、下流側ではcache freshnessとmetadata hygieneを補う。役割を分けると、MCP serverの発見と導入判断を同じ画面で混ぜすぎずに済みます。
今日の結論
MCP Registryは便利なmetadata sourceですが、利用者が実際に触るのは下流aggregatorやmarketplaceの一覧であることも多いはずです。だから、導入前preflightの次には、cache age、status freshness、latest consistency、文字化け、advisory boundaryを見る小さな監査層が欲しくなります。
最初の実装はfixture-firstで十分です。保存済みのRegistry API snapshotを読み、古さと不整合を短く出す。MCP serverを自動で入れる前に、下流cacheがどれくらい信じられる状態かを見るだけでも、coding agentに渡すtool選びはかなり落ち着きます。
