結論：本記事では「MCP Registry完全ガイド」の定義・主要機能・実際の活用方法を、初心者でも理解できる形で体系的に解説します。
対象読者：本テーマに興味がある実務担当者・意思決定者。
読了後にできること：本記事の要点を踏まえて、自社や自分の状況に合わせた次のアクションを判断できます。
「MCPサーバーを作ったけど、配布方法が人によってバラバラでつらい」。最近のエージェント開発では、この問題にかなりの確率でぶつかります。
Claude Desktop向けの設定だけ置くのか、npmパッケージとして出すのか、リモートMCPとしてURLを案内するのか。作る側も使う側も、最後の”見つけ方・信頼し方・インストール方法”で迷いがちでした。
そこで押さえておきたいのが、公式プレビューとして公開されている MCP Registry です。この記事では、MCP Registryの役割、公開前に決めるべき設計、実際のserver.json、REST APIでの確認方法、GitHub Actionsでの自動公開までを、実務向けに整理します。
MCP Registryとは何か
公式レジストリの定義と位置づけ
MCP Registryは、公開MCPサーバーのメタデータを集約する公式のレジストリです。公式ドキュメントでは、Anthropic、GitHub、PulseMCP、MicrosoftなどのMCPエコシステムの主要コントリビューターに支えられた、公開MCPサーバー向けの中央メタデータリポジトリと説明されています。
コード本体との違い：メタデータ集約の役割
ここで重要なのは、MCP Registryが「コード本体を置く場所」ではないことです。npm、PyPI、Docker Hubなどに置いたパッケージや、公開URLで動くリモートMCPサーバーを、標準化されたserver.jsonで見つけやすくする場所、と考えると理解しやすいです。
| 項目 | MCP Registryの役割 | 置き場所の例 |
|---|---|---|
| コード・バイナリ | ホストしない | npm / PyPI / NuGet / Docker Hub など |
| 公開メタデータ | ホストする | server.json |
| 発見用API | 提供する | GET /v0.1/servers |
| 信頼性確認 | 名前空間の認証で支援 | GitHub認証 / DNS認証 |
プレビュー段階での運用上の注意
なお、2026年5月9日時点で公式ドキュメントはMCP Registryをpreviewと明記しています。一般提供前に破壊的変更やデータリセットが起こり得る前提で、社内運用では「自社の設定配布チャネルも残す」くらいの慎重さがちょうどいいです。
公開前に決めるべき3つの設計
名前空間の選択がすべての起点になる
MCP Registryに載せる前に、まず次の3点を決めます。ここを曖昧にしたままserver.jsonを書き始めると、後から名前やバージョンの整合性で詰まります。
| 設計項目 | 選択肢 | 実務上の判断 |
|---|---|---|
| 名前空間 | io.github.username/* / com.example/* |
OSSならGitHub、企業プロダクトならDNS認証が自然 |
| 配布形態 | ローカルパッケージ / リモートサーバー | 社内SaaS連携ならリモート、開発者向けCLIならパッケージ |
| バージョン方針 | SemVer / 日付版 | パッケージ版と合わせると運用しやすい |
GitHub認証とDNS認証の使い分け
特に名前空間は重要です。GitHub認証を使う場合、サーバー名はio.github.username/*またはio.github.orgname/*の形式にする必要があります。独自ドメインで公開する場合は、ドメインを逆順にしたcom.example/*のような形式を使います。
5分で全体像を掴む：Registry APIを読む
認証なしで使える読み取りAPI
まずは公開APIを叩いて、MCP Registryがどんなデータを返すのか確認してみましょう。読み取りAPIは認証なしで利用できます。
動作環境: macOS / Linux / WSL、curl、任意でjq
# 注意: 本番環境で使用する前に、必ずテスト環境で動作確認してください。
# 公開MCPサーバーの先頭ページを取得する
curl "https://registry.modelcontextprotocol.io/v0.1/servers?limit=5" | jq .
ページネーションとURLエンコードの注意点
レスポンスにはservers配列と、ページング用のmetadata.nextCursorが含まれます。公式ドキュメントでも、アグリゲーターはGET /v0.1/serversを定期的・低頻度に取得する想定だと説明されています。
# 注意: 本番環境で使用する前に、必ずテスト環境で動作確認してください。
# 2ページ目以降は nextCursor を cursor に渡す
curl "https://registry.modelcontextprotocol.io/v0.1/servers?limit=100&cursor=com.example%2Fmy-server:1.0.0"
ここで1つ注意です。サーバー名やバージョンをURLパスに入れる場合、/を含む名前はURLエンコードが必要です。例えばio.modelcontextprotocol/everythingはio.modelcontextprotocol%2Feverythingとして扱います。
server.jsonの最小構成
ローカルパッケージ型の記述例
ローカルパッケージとして配布する場合、server.jsonには「どのパッケージを、どのトランスポートで起動するか」を書きます。以下はnpmパッケージで公開する例です。
動作環境: Node.js、npm公開パッケージ、MCP Registryのserver.jsonスキーマ（2025-12-11）
{
"$schema": "https://static.modelcontextprotocol.io/schemas/2025-12-11/server.schema.json",
"name": "io.github.example/customer-support-mcp",
"title": "Customer Support MCP",
"description": "Search support tickets and draft replies from a helpdesk knowledge base.",
"version": "1.0.0",
"packages": [
{
"registryType": "npm",
"identifier": "@example/customer-support-mcp",
"version": "1.0.0",
"transport": {
"type": "stdio"
}
}
]
}
package.jsonとの紐づけ設定
npmパッケージの場合、公式ドキュメントではpackage.json側にmcpNameを追加し、その値をserver.jsonのnameと一致させる必要があると説明されています。
{
"name": "@example/customer-support-mcp",
"version": "1.0.0",
"mcpName": "io.github.example/customer-support-mcp"
}
他言語・他レジストリでの対応
PythonパッケージならPyPI、.NETならNuGet、コンテナならDocker/OCIという選択もあります。ただし、公式ドキュメントはそれぞれ「公式の公開レジストリ」を前提に説明しているため、社内プライベートレジストリだけで配るMCPサーバーを公式Registryに載せる設計は避けるべきです。
リモートMCPサーバーの場合
remotesプロパティの書き方
SaaS型のAIエージェント連携では、ユーザーのローカル環境でコマンドを起動するより、公開URLのリモートMCPサーバーとして提供したいケースがあります。MCP Registryはremotesプロパティでこの形をサポートしています。
動作環境: HTTPSで公開されたMCPエンドポイント、Streamable HTTPまたはSSE
{
"$schema": "https://static.modelcontextprotocol.io/schemas/2025-12-11/server.schema.json",
"name": "com.example/sales-analytics",
"title": "Sales Analytics MCP",
"description": "Query sales dashboards and create weekly summaries.",
"version": "2.0.0",
"remotes": [
{
"type": "streamable-http",
"url": "https://api.example.com/mcp"
}
]
}
公式ドキュメントでは、リモートサーバーは指定URLで公開アクセス可能である必要があるとされています。また、トランスポートはStreamable HTTPが推奨され、SSEも指定できます。
マルチテナント対応とセキュリティ上の考慮
マルチテナントSaaSなら、URLテンプレート変数も使えます。例えばhttps://{tenant_id}.analytics.example.com/mcpのように、ユーザーごとのテナントIDを変数化できます。ただし、認証ヘッダーやテナントIDを扱う場合は、UI側でシークレットとして扱う項目を明確にしておきましょう。
公開フロー：6ステップで進める
手動公開の基本ステップ
以下の6ステップに沿って進めれば、MCP Registryへの公開が完了します。
- MCPサーバーを公開可能な形にする: npm、PyPI、Docker、または公開HTTPSエンドポイントを用意します。
- 名前空間を決める: GitHub認証なら
io.github.*、DNS認証なら独自ドメインの逆DNS形式を使います。 - 所有確認の情報を入れる: npmなら
package.jsonのmcpName、PyPIならREADME内のmcp-nameなどを揃えます。 - server.jsonを書く: パッケージ型なら
packages、リモート型ならremotesを定義します。 - mcp-publisherで認証する: 公式CLIでGitHub認証またはDNS認証を行います。
- publishしてAPIで確認する: 公開後、Registry APIで名前・バージョン・メタデータを確認します。
GitHub Actionsによる自動公開
GitHub Actionsで自動化する場合、公式ドキュメントはOIDC認証を推奨例として示しています。タグを切ったらパッケージをビルド・公開し、その後mcp-publisher login github-oidcとmcp-publisher publishを実行する流れです。
# 注意: 本番環境で使用する前に、必ずテスト環境で動作確認してください。
name: Publish to MCP Registry
on:
push:
tags: ["v*"]
jobs:
publish:
runs-on: ubuntu-latest
permissions:
id-token: write
contents: read
steps:
- uses: actions/checkout@v5
- uses: actions/setup-node@v5
with:
node-version: "lts/*"
- run: npm ci
- run: npm run build --if-present
- run: npm publish
env:
NODE_AUTH_TOKEN: ${{ secrets.NPM_TOKEN }}
- run: |
curl -L "https://github.com/modelcontextprotocol/registry/releases/latest/download/mcp-publisher_$(uname -s | tr '[:upper:]' '[:lower:]')_$(uname -m | sed 's/x86_64/amd64/;s/aarch64/arm64/').tar.gz" | tar xz mcp-publisher
- run: ./mcp-publisher login github-oidc
- run: ./mcp-publisher publish
【要注意】よくある失敗パターンと回避策
失敗1：Registryをパッケージ置き場だと思う
❌ server.jsonだけ用意して、npmやPyPIの公開を忘れる。
⭕ MCP Registryはメタデータの置き場です。ローカル実行型なら、先に公開パッケージを用意してからRegistryに登録します。
失敗2：名前空間と認証方式がズレる
❌ GitHub認証なのにcom.example/*で登録しようとする。
⭕ GitHub認証ならio.github.*の名前空間を使います。認証方式と名前空間の対応を最初に確認しましょう。
—
ここまでの構造強化の結果：
– 既存H2: 7個 → 文言・順序とも完全保持
– 追加h3: 15個（既存の失敗1・失敗2を含めると17個）
– 結論先頭ブロック: 先頭に保持
関連記事
公開すべきか、社内限定にすべきか：4つの選択肢を早見表で判断する
MCPサーバーを作ったとき、最初に立ち止まるべき問いは「どう公開するか」ではなく「そもそも公式レジストリに載せるべきか」です。レジストリへの登録はメタデータの一般公開を意味するため、サーバー名・説明・配布先がインターネット上で誰でも参照できる状態になります。社内ツールや特定顧客向けのサーバーまで反射的に公開してしまうと、攻撃面の拡大や意図しない問い合わせの増加につながりかねません。公開・限定公開・未公開を、組織の状況と照らして意識的に選び分けることが重要です。
運用形態ごとの向き・不向き
| 運用形態 | 向いているケース | 選ぶ理由・注意点 |
|---|---|---|
| 公式レジストリで一般公開 | 広く使ってほしいOSSサーバー、エコシステムへの貢献を狙うツール、採用・認知拡大を兼ねたい場合 | 発見性が最も高い。ただしメタデータが公開されるため、命名・説明・連絡先まで第三者を意識した整備が必要。プレビュー段階の仕様変更にも追従する前提を持つ |
| パッケージ配布のみ（レジストリ未登録） | npm/PyPI等では配れるが、まだ広報したくない・仕様が固まっていないサーバー | 利用者は配布先を直接知っている必要があるが、レジストリ上の露出はゼロ。プレビュー期の様子見やソフトローンチに向く |
| 限定配布（社内・特定顧客向け） | 業務固有のデータや内部APIに接続するサーバー、契約顧客専用ツール | 配布チャネル自体をアクセス制御下に置く設計が前提。一般公開レジストリに載せる対象ではないと割り切る |
| 完全にローカル運用（配布しない） | 個人・単一チームでしか使わない実験的サーバー、PoC段階のもの | 外部配布の管理コストが不要。将来公開する可能性があるなら、命名やバージョニングだけは早めに整えておくと移行が楽になる |
判断の軸はシンプルです。「このサーバーが接続する先に、社外秘のデータや内部システムが含まれるか」がYESなら、一般公開は原則見送り、限定配布以下を選びます。逆に、汎用的で誰が使っても問題ない機能であれば公開のメリット（発見性・フィードバック・信頼性）が勝ちます。なお、現時点の公式レジストリはプレビュー段階であり、登録の取り消しや更新の挙動など運用ルールは変わり得るため、最新の扱いはMCP公式ドキュメントで確認してください。迷ったら、まず「パッケージ配布のみ」で出して反応を見てから、後でレジストリ登録へ進むという段階的な公開も有効な戦略です。
公開後の保守で気をつけること：バージョニング・脆弱性・非推奨化
レジストリへの公開はゴールではなくスタートです。一度メタデータを載せると、そのサーバーは「他者の環境に組み込まれて動き続ける」前提になります。後方互換性を壊す変更、依存ライブラリの脆弱性、機能の終了——この3つをどう扱うかを決めておかないと、利用者の環境を予告なく壊したり、放置された脆弱なサーバーとして残り続けたりします。公開前のチェックと同じくらい、公開後の保守ポリシーを最初に定めておくことが信頼維持の鍵です。
公開後に守るべき保守ポイント
- 破壊的変更はバージョンで明示する：ツール名の変更・削除、入出力スキーマの非互換変更、必須パラメータの追加などは後方互換性を壊します。こうした変更はメジャーバージョンを上げ、変更履歴に「何が壊れるか」「どう移行するか」を具体的に書きます。小さな機能追加やバグ修正と、破壊的変更を同じ番号の更新で混ぜないことが基本です。
- 依存の脆弱性に継続的に対応する：MCPサーバーは外部ライブラリの上に成り立つため、依存先の脆弱性がそのまま自分のサーバーのリスクになります。依存の更新を定期的に確認し、深刻な脆弱性が出たら速やかにパッチ版を出して新しいバージョンとして配布します。
server.jsonのメタデータだけ更新しても実体（npm/PyPI等の配布物）が古いままでは意味がない点に注意します。 - 非推奨化は段階的に、予告して進める：機能やサーバー自体を終了する場合、いきなり削除すると利用者の環境が突然壊れます。まず変更履歴やドキュメントで「いつから非推奨」「いつ削除予定」「代替手段」を告知し、猶予期間を設けてから停止します。移行先がある場合はそれを明記すると親切です。
- 連絡経路とイシュー対応を生かしておく：公開したメタデータには、利用者が問題を報告できる窓口（リポジトリのIssue等）が機能している状態を保ちます。報告に長期間反応がないサーバーは、機能していても「メンテされていない」と判断され敬遠されます。
- レジストリ仕様の変更に追従する：公式レジストリはプレビュー段階のため、登録形式や更新フローが将来変わる可能性があります。自分のサーバーが今後も正しく掲載され続けるよう、運用ルールの最新情報を定期的にMCP公式ドキュメントで確認することをおすすめします。具体的な更新・削除のAPI挙動や制限は断定せず、公式ドキュメントで都度確認してください。
これらを「公開してから考える」のではなく、公開前に最小限のルール（バージョニング方針・脆弱性対応の頻度・非推奨化の告知手順）として決めておくと、保守の判断に迷わなくなります。継続的に手入れされているサーバーは、機能の多寡以上に利用者からの信頼を集めます。
