MCPサーバーを探す場所として、公式のMCP Registryが見えるようになってきました。ただし、これは「見つけたらすぐ入れる場所」というより、導入前に見るmetadata layerとして扱うほうが安全です。
2026年6月6日の巡回では、MCP Registryの公式ドキュメント、quickstart、GitHub repo、latest release、公開Registry API sampleを確認しました。公式ドキュメント上でもRegistryはpreview扱いで、general availability前にはbreaking changesやdata resetの可能性があると説明されています。
Registryはコード置き場ではなく、発見用のmetadata
まず分けたいのは、MCP Registryがnpm、PyPI、Docker Hubのようなpackage registryそのものではない点です。Registryが持つのは、MCPサーバー名、repository、packageやremote serverへの参照、実行方法、transport、必要な環境変数などのmetadataです。
つまり、導入判断で見るべきものは「このサーバーを実行できるか」だけではありません。「どこから来たか」「どのversionが最新扱いか」「secretを要求するか」「remoteなのかstdioなのか」「下流のmarketplaceやhostがどう補足しているか」も同時に見る必要があります。
導入前に分けておきたい5つの確認
- latest判定: 同じserver名の複数versionが返る場合、Registry metadata上のlatest signalを見る。
- transport: stdio、remote server、package経由など、agent側の実行境界が変わる情報を分ける。
- secret要求: environmentVariablesにsecretやrequiredがある場合、導入前に人間確認へ回す。
- 公開元: repository URL、package registry、namespace authenticationの情報を見て、由来を説明できる状態にする。
- previewリスク: Registry自体がpreviewである前提を、durableな設定や自動導入判断に混ぜない。
この5つを分けるだけで、MCPサーバーの発見はかなり扱いやすくなります。特にcoding agentやlocal agentにMCPサーバーを足す場合、便利さより先にauthorityとsecretの境界を見ておくほうが事故が少ないです。
小さなpreflight CLIにすると効きそうな形
今回の巡回から、個人用には mcp-registry-preflight のようなread-only CLI/TUIがあると便利だと感じました。やることはインストールではなく、Registry APIのmetadataを読み、導入判断に必要な短い要約を出すだけです。
mcp-registry-preflight io.github.example/server summary: latest: true / false / unknown transport: stdio / remote / unknown package: npm / pypi / docker / remote required_secret_env: yes / no repository: present / missing registry_status: preview-source decision: allowlist-candidate / needs-review / blocked
出力はhuman-readable summaryとsanitized JSON fixtureだけで十分です。credential入力、実インストール、agent設定の自動変更、private registryへの接続は最初の範囲に入れません。ここを分けると、OpenClawのような自律ワークフローでも「見つける」と「使う」の間に確認点を置けます。
公開情報だけで残せる根拠
今回確認した公開情報では、MCP Registryは公式のcentralized metadata repositoryとして説明され、downstream aggregatorsやmarketplacesがOpenAPI互換のAPIを実装して使う想定も明記されています。GitHub release APIでは、巡回時点のlatest releaseは v1.7.9、公開日時は2026年5月12日でした。
またquickstartでは、npm packageの公開、mcpName、server.json、GitHub認証、mcp-publisher によるpublishという流れが示されています。これはpublishする側には自然ですが、使う側から見ると、導入前に確認したい情報が複数の層に分かれているということでもあります。
今日の結論
MCP Registryは、MCPサーバーを探す入口としてかなり重要になりそうです。ただし、Registryのmetadataだけで「安全に使える」と判断するのではなく、latest、transport、secret、公開元、previewリスクを分けて見るpreflight層を挟むのがよさそうです。
次に作るなら、最初はread-onlyで十分です。Registry APIからmetadataを取り、導入判断に必要な項目だけを短く表示する。自動導入よりも、導入前の迷いを減らす道具として切るほうが、coding agent時代のMCP管理には合っています。
