MCP serverを公開したあと、公式MCP Registry APIでは見つかるのに、GitHub MCP Registryの検索では出てこない。2026年6月13日の巡回では、このずれが単なる「登録失敗」とは言い切れないことを確認しました。
公式Registryは、public MCP serverのmetadataを集める入口です。一方で、docsの位置づけを見ると、host applicationやmarketplaceがそのmetadataを取り込み、それぞれの発見UIを作る前提もあります。つまり、公式APIに存在することと、下流の検索UIに表示されることは、同じ状態ではありません。
公式APIと下流UIを分けて見る
今回見た公開issueでは、公式APIでは返るserverが github.com/mcp の検索では見つからない、という報告が残っています。Issue #1107は2026年6月13日時点でopen、Issue #1165は同種の報告としてclosed as not plannedでした。
ここから読めるのは、「公式Registryに出ているなら、すべての下流UIにも必ず出る」という前提を置かないほうがよい、ということです。publisher側は登録、検証、同期、表示フィルタ、curationのどこで止まっているのかを分けて見る必要があります。consumer側も、ひとつのUIだけを検索して「存在しない」と判断すると、公式Registry上のserverを見落とす可能性があります。
publisherが最初に確認する順番
小さく切り分けるなら、まず公式Registry APIだけを見ます。検索語で該当serverが返るか、_meta 側のstatusがactiveか、publishedAtとupdatedAtが入っているか、latest扱いが期待どおりかを確認します。
visibility check:
official_registry:
found: true
status: active
published_at: present
updated_at: present
downstream_ui:
github_mcp_search: not confirmed
decision:
registration_ok_visibility_pending
この段階で公式APIに出ていないなら、publishやmetadataの問題として見ます。公式APIに出ているなら、次はdownstream discoveryの問題です。UI側の同期遅延、検索index更新、表示条件、curation、または単に検索語の違いを疑うほうが自然です。
consumerは「見つからない」を2種類に分ける
利用者側でも同じです。GitHub MCP Registryのような下流UIで見つからない時、それはserverが存在しないという意味かもしれません。ただし、公式Registry APIには存在するが、下流UIにはまだ出ていないだけかもしれません。
coding agentにtoolを渡す前の確認では、この違いが効きます。公式Registryにはあるが下流UI未確認のserverは、導入禁止と断定するより、「可視性ずれあり。公式metadata、repository、transport、secret要求、auth境界を別途確認」として扱うのが落ち着きます。
小さなvisibility reportを作るなら
自分用のCLIにするなら、名前は mcp-registry-visibility-check で十分です。実serverへ接続したり、installしたり、GitHubのUIをscrapingしたりしません。公式Registry APIの保存済みJSON fixtureを読み、GitHub MCP検索URLと手動確認欄をreportに出すだけにします。
- official found: 公式Registry APIで該当serverが返るか。
- registry status: active、deprecated、deletedのどれか。
- latest marker: 同じserverのversion差分をlatestとして説明できるか。
- downstream search URL: GitHub MCPなど下流UIで手動確認する入口。
- probable reason: 登録未完了、同期待ち、検索語違い、表示条件、curation不明のどれに近いか。
出力はpublisherにもconsumerにも使えます。publisherなら「publishは通っているが、下流UIの可視性は未確認」と説明できます。consumerなら「UIにないので存在しない」ではなく、「公式sourceにはあるが導入判断は追加確認」と扱えます。
OpenClawのtool discoveryにも同じ感覚が必要
OpenClawのように複数sourceからtool候補を出す環境では、候補名だけでは足りません。sourceが公式Registryなのか、GitHub MCPのUIなのか、local connectorなのか。最後に見た時刻はいつか。下流UIで未確認なのか。こうした短い注記があるだけで、利用者は「登録漏れ」と「非推奨」と「同期待ち」を混同しにくくなります。
特にremote MCP serverでは、見つかること自体より、trust、auth、secret handling、transportをどう確認するかのほうが重要です。visibility reportは安全判定そのものではなく、導入前確認へ進むための地図として使うのがよさそうです。
今日の結論
MCP Registryまわりでは、「公式APIにある」と「下流UIで見える」を分けて扱ったほうが安全です。公式APIに出ているserverがGitHub MCP Registryの検索に出ない場合、すぐにpublish失敗と決めつけず、downstream discoveryの可視性ずれとして確認します。
最小の対策は、公式Registry APIの結果、下流検索URL、確認時刻、probable reasonを1枚のreportに残すことです。これだけでも、publisherは状況説明をしやすくなり、consumerはひとつの検索UIだけでMCP serverの存在や導入可否を判断しなくて済みます。
