MCP Registry完全ガイド｜公開手順6ステップ

「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認証を使う場合、サーバー名はio.github.username/*またはio.github.orgname/*の形式にする必要があります。独自ドメインで公開する場合は、ドメインを逆順にしたcom.example/*のような形式を使います。

5分で全体像を掴む：Registry APIを読む

まずは公開APIを叩いて、MCP Registryがどんなデータを返すのか確認してみましょう。読み取りAPIは認証なしで利用できます。

動作環境: macOS / Linux / WSL、curl、任意でjq

# 注意: 本番環境で使用する前に、必ずテスト環境で動作確認してください。
# 公開MCPサーバーの先頭ページを取得する
curl "https://registry.modelcontextprotocol.io/v0.1/servers?limit=5" | jq .

レスポンスには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"
      }
    }
  ]
}

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サーバーの場合

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ステップで進める

1. MCPサーバーを公開可能な形にする: npm、PyPI、Docker、または公開HTTPSエンドポイントを用意します。
2. 名前空間を決める: GitHub認証ならio.github.*、DNS認証なら独自ドメインの逆DNS形式を使います。
3. 所有確認の情報を入れる: npmならpackage.jsonのmcpName、PyPIならREADME内のmcp-nameなどを揃えます。
4. server.jsonを書く: パッケージ型ならpackages、リモート型ならremotesを定義します。
5. mcp-publisherで認証する: 公式CLIでGitHub認証またはDNS認証を行います。
6. publishしてAPIで確認する: 公開後、Registry APIで名前・バージョン・メタデータを確認します。

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.username/*、ドメイン認証なら逆DNS形式、という対応関係を最初に決めます。

失敗3：バージョンを書き換えられる前提で運用する

❌ 一度公開した1.0.0のメタデータを後から直せばいい、と考える。

⭕ 公式ドキュメントでは、公開済みバージョン文字列とメタデータは変更できないと説明されています。修正が必要な場合は新しいバージョンを公開する運用に寄せましょう。

失敗4：プレビュー段階なのに本番依存を強くしすぎる

❌ 社内配布や顧客向けオンボーディングをMCP Registryだけに依存させる。

⭕ 2026年5月時点ではpreviewです。公式Registry、GitHub README、自社ドキュメントの3点で案内を冗長化しておくと安全です。

AIエージェント開発チームでの使いどころ

開発チームにとってのMCP Registryの価値は、単に「公開場所が増えた」ことではありません。むしろ、MCPサーバーをプロダクトとして運用するための共通フォーマットが見えてきた点が大きいです。

例えば、社内のAIエージェント基盤で利用可能なMCPサーバー一覧を作る場合、公式Registry APIをそのまま使うのではなく、いったん自社のサブレジストリやカタログに取り込み、セキュリティスキャン、承認状態、対応部署、利用手順を_metaに追加する設計が現実的です。公式ドキュメントでも、下流アグリゲーターが評価やセキュリティスキャンなどの独自メタデータを付与する想定が示されています。

すでにMCP認可やOAuth 2.1対応を検討している場合は、公開メタデータと認可設計をセットで考えるのがおすすめです。認可まわりは MCP認可の実装ガイド で詳しく解説しています。エージェントから決済やSaaS操作につなげる文脈では、Stripe Agents Toolkit完全チュートリアル もあわせて確認すると、ツール公開後の実業務フローがイメージしやすいはずです。

参考・出典

• The MCP Registry — Model Context Protocol公式ドキュメント（参照日: 2026-05-09）
• Quickstart: Publish an MCP Server to the MCP Registry — Model Context Protocol公式ドキュメント（参照日: 2026-05-09）
• MCP Registry Supported Package Types — Model Context Protocol公式ドキュメント（参照日: 2026-05-09）
• Publishing Remote Servers — Model Context Protocol公式ドキュメント（参照日: 2026-05-09）
• MCP Registry Aggregators — Model Context Protocol公式ドキュメント（参照日: 2026-05-09）
• How to Automate Publishing with GitHub Actions — Model Context Protocol公式ドキュメント（参照日: 2026-05-09）
• MCP Registry OpenAPI spec — GitHub（参照日: 2026-05-09）

まとめ：今日から始める3つのアクション

1. 今日やること: GET /v0.1/serversを叩いて、公開メタデータの構造を確認する。
2. 今週中: 自社MCPサーバーの名前空間、配布形態、バージョン方針を決める。
3. 今月中: server.jsonを用意し、GitHub Actionsで公開フローを自動化する。

この記事はAIgent Lab編集部がお届けしました。