MCP Registryとサーバーの配布

MCP サーバーを公開・配布する方法と、組織内で利用を許可するサーバーを管理する方法を解説します。公開する側は、公式の MCP Registry にメタデータを登録し、パッケージやリモートの URL を見つけてもらえるようにします。利用する側 (組織) は、公式 Registry を直接の入口にせず、承認したサーバーだけを提供する仕組みを自分で持ちます。サーバーの実装は MCPサーバーの実装 - SDKとGo・C#、運用は MCPサーバーのデプロイと運用、ローカルサーバーの導入時の確認は ローカルMCPサーバーの安全な運用 を参照してください。

確認日と状態

公式 MCP Registry は、執筆時点でプレビュー版です。破壊的な変更やデータのリセットが、一般提供の前に起こり得ます。コマンド、server.json のスキーマ、対応するパッケージの種類は、公開の前に 公式のドキュメント で最新を確認してください。

1. このドキュメントで扱うこと

• 公式 MCP Registry
• 公開のクイックスタート
• サポートされるパッケージ種別
• リモートサーバーの公開
• 公開時の認証
• バージョニング
• GitHub Actions による自動公開
• Server Cards
• モデレーションポリシー
• 組織内での承認とガバナンス

公式 MCP Registry

MCP Registry は、公開されている MCP サーバーのメタデータを集めた、公式の中央リポジトリです。Anthropic、GitHub、PulseMCP、Microsoft などの支援を受けています。提供するものは次のとおりです。

• サーバーの作者が、メタデータを公開する 1 か所の場所
• DNS による検証を含む、名前空間の管理
• MCP クライアントやアグリゲーターが、サーバーを発見するための REST API
• 標準化された、インストールと設定の情報

メタデータは server.json という標準の形式で、サーバーの一意の名前 (たとえば io.github.user/server-name)、場所 (npm のパッケージ名、リモートの URL)、実行の手順 (コマンドライン引数、環境変数)、説明などの発見のための情報を持ちます。

Registry は、成果物をホストしません。パッケージの実体は、npm、PyPI、Docker Hub などのパッケージレジストリにあり、MCP Registry は、そこを指すメタデータを持ちます。たとえば、weather-mcp が npm にあるとき、Registry のメタデータが、「weather の v1.2.0」を npm:weather-mcp に対応づけます。

関係者ごとの位置づけを整理します。

• サーバーの開発者: オープンソースでも、クローズドソースでも公開できる。ただし、インストールの方法が公開されている (公開レジストリの npm パッケージや Docker イメージなど)、またはサーバー自体が公開されている (私的なネットワークに限定されないリモートサーバー) ことが条件。非公開のサーバー (社内のネットワークや、私的なパッケージレジストリにあるもの) には対応しない。そうしたサーバーは、自前の私的なレジストリで管理することが推奨される
• アグリゲーター (下流の集約者): Registry の主な利用者は、MCP サーバーのマーケットプレイスのような下流の集約者を想定している。Registry のメタデータは、意図的に意見を持たない形で、アグリゲーターが、キュレーションや、コミュニティの評価などの付加価値を足す。アグリゲーターは、Registry の API から、定期的に (たとえば 1 時間に 1 回程度) メタデータを取得することが想定されている
• 他のレジストリ (サブレジストリ): 公式 Registry は、公開の REST API に加え、他のレジストリが実装できる OpenAPI の仕様を定義している。アグリゲーターも、私的なレジストリも、これに準拠すれば、既存のホストアプリケーションの対応を利用できる。ただし、公式 Registry のコードベースは、自前でホストする用途を想定しておらず、そのサポートも提供されない
• MCP ホストアプリケーション: 公式 Registry を直接使うことは想定されていない。下流のマーケットプレイスなど、OpenAPI に準拠したレジストリの REST API を使う

信頼とセキュリティの面では、Registry は名前空間の認証に責任を持ちます。サーバー名は逆ドメイン形式 (io.github.username/server、com.example/server) で、検証された GitHub のアカウントやドメインに結びつくため、その名前空間では、正当な所有者だけが公開できます。一方、サーバーのコードのセキュリティスキャンは、Registry の責任ではなく、パッケージレジストリ (npm、PyPI、Docker Hub) と、下流のアグリゲーターに任せられています。Registry に載っていることは、安全性や品質の保証ではありません。

公開のクイックスタート

公式のクイックスタートに沿って、TypeScript 製の npm パッケージを公開する流れを示します。手順は、ほかのパッケージの種類でも、Registry への公開の部分は同じです。事前に、npm のアカウントと GitHub のアカウントが必要です (この例は GitHub による認証を使います)。

手順 1: パッケージに検証用の情報を足す。 Registry は、サーバーのパッケージがメタデータと一致するかを検証します。npm では、package.json に mcpName を足します。この値が Registry での名前になり、GitHub による認証を使うなら、io.github.<ユーザー名>/ で始まらなければなりません。

{
  "name": "@my-username/mcp-weather-server",
  "version": "1.0.1",
  "mcpName": "io.github.my-username/weather"
}

手順 2: パッケージを公開する。 Registry はメタデータだけを持つため、先に npm へ公開します (npm publish --access public)。

手順 3: mcp-publisher を入れる。 公式の CLI です。macOS と Linux ではビルド済みのバイナリか Homebrew (brew install mcp-publisher)、Windows ではビルド済みのバイナリを使います。mcp-publisher --help で確認します。

手順 4: server.json を作る。 mcp-publisher init が、プロジェクトの情報から雛形を作ります。name は、package.json の mcpName と一致していなければなりません。

手順 5: 認証する。 mcp-publisher login github で、デバイスの認可の流れ (表示された URL とコードで、GitHub 側で承認する) が始まります。

手順 6: 公開する。 mcp-publisher publish を実行します。公開できたかどうかは、Registry の API で検索して確認できます。

mcp-publisher init
mcp-publisher login github
mcp-publisher publish

curl "https://registry.modelcontextprotocol.io/v0.1/servers?search=io.github.my-username/weather"

エラーの典型は、次のとおりです。

エラー	対処
"Registry validation failed for package"	パッケージに検証用の情報 (npm なら package.json の mcpName) があるか確認する
"Invalid or expired Registry JWT token"	mcp-publisher login github で再認証する
"You do not have permission to publish this server"	認証の方法と、サーバー名の名前空間が合っていない。GitHub 認証なら、名前が io.github.<自分のユーザー名>/ で始まる必要がある

サポートされるパッケージ種別

パッケージの種類ごとに、server.json の registryType と、所有の検証の方法が決まっています。いずれも、server.json のサーバー名と、パッケージ側の記載が一致していなければなりません。

種別	registryType	対応するレジストリ	所有の検証
npm	npm	npm の公開レジストリのみ	package.json の mcpName
PyPI	pypi	公式の PyPI のみ	README に mcp-name: <サーバー名> の文字列 (コメントでもよい)
NuGet	nuget	公式の NuGet のみ	README に mcp-name: <サーバー名> の文字列 (コメントでもよい)
Cargo (Rust)	cargo	crates.io のみ	README に mcp-name: <サーバー名> の文字列。crates.io は HTML コメントを除去するため、見える文字で書く
Docker / OCI	oci	Docker Hub、ghcr.io、Google Artifact Registry、Azure Container Registry、Microsoft Container Registry	イメージの io.modelcontextprotocol.server.name のラベル (アノテーション)
MCPB	mcpb	GitHub か GitLab のリリースでホストされた成果物	URL に "mcp" を含む。fileSha256 が必須

OCI の identifier は、registry/namespace/repository:tag の形式で、タグの代わりにダイジェストも指定できます。MCPB の fileSha256 は、成果物の SHA-256 で、openssl dgst -sha256 <ファイル> で計算できます。Registry はこのハッシュを検証しませんが、MCP クライアントは、インストールの前にハッシュを検証します。

Cargo には、実行時のモデルの違いもあります。cargo install で、バイナリが PATH 上に置かれ、クライアントが名前で直接起動します。npx や uvx のような、起動のたびに使うランナーはありません。Rust の作者には、ソースで配るなら Cargo、利用者に Rust のツールチェーンを要求したくないなら、ビルド済みのバイナリを配る MCPB という、2 つの選択肢があります。

リモートサーバーの公開

リモートの MCP サーバーは、server.json の remotes で公開します。リモートのサーバーは、指定した URL で、公開されてアクセスできなければなりません。

{
  "$schema": "https://static.modelcontextprotocol.io/schemas/2025-12-11/server.schema.json",
  "name": "com.example/acme-analytics",
  "title": "ACME Analytics",
  "description": "Real-time business intelligence and reporting platform",
  "version": "2.0.0",
  "remotes": [
    {
      "type": "streamable-http",
      "url": "https://analytics.example.com/mcp"
    }
  ]
}

トランスポートは、type に "streamable-http" か "sse" を指定します。SSE は非推奨なので、既存のクライアントを支えるためだけに公開します。両方を、別の URL で同時に提供することもできます。

• URL のテンプレート変数: {tenant_id} のように、波括弧で変数を定義できる。マルチテナントで、1 つの定義から複数のエンドポイントを表せる。変数には description、isRequired、default、choices、isSecret を付けられる
• HTTP ヘッダー: headers で、クライアントに送らせるヘッダー (たとえば X-API-Key) を、isRequired と isSecret 付きで指示できる
• リモートとパッケージの併記: remotes と packages は、同じ server.json に共存でき、ホストアプリケーションが好みのインストール方法を選べる

注意点として、server.json の remotes は、接続先と、送るべきヘッダーの指示であり、認可の方式そのもの (OAuth のメタデータ、スコープ) は、サーバーの WWW-Authenticate と保護リソースのメタデータで、実行時に伝えます (MCPの認可 - OAuth 2.1とメタデータ探索)。シークレットが必要なヘッダーは isSecret: true にしますが、値を server.json に書いてはいけません。

公開時の認証

公式 Registry への公開には、認証が必要です。選んだ認証の方式が、サーバー名の名前空間を決めます。

方式	サーバー名の形式	例
GitHub	io.github.<ユーザー名か組織名>/*	io.github.alice/weather-server
ドメイン (DNS または HTTP)	逆ドメイン形式 com.example.*/*	com.example/acme-analytics

GitHub 認証: mcp-publisher login github で、OAuth のデバイスフローを使う。

DNS 認証: ドメインの所有を、DNS の TXT レコードで証明する。公開鍵と秘密鍵のペア (Ed25519 か ECDSA P-384) を作り、公開鍵から作った TXT レコード (v=MCPv1; k=ed25519; p=<公開鍵>) をドメインに追加し、伝搬後に、秘密鍵で mcp-publisher login dns --domain example.com --private-key ... を実行する。鍵を自分のマシンに置きたくないときは、Google Cloud KMS や Azure Key Vault の鍵で署名する方法もある。

HTTP 認証: 同じ鍵の方式で、ドメインの /.well-known/mcp-registry-auth のファイルに、証明の文字列 (v=MCPv1; k=ed25519; p=<公開鍵>) を置く。ファイルを公開した後、mcp-publisher login http --domain ... --private-key ... を実行する。

組織のサーバーは、個人の GitHub のアカウントではなく、組織のドメインの名前空間 (DNS か HTTP 認証) か、組織の GitHub の名前空間で公開するほうが、所有者の交代や退職に強くなります。秘密鍵は、リポジトリに置かず、シークレットの管理の仕組みか KMS で保管します。

バージョニング

server.json の version は必須で、公開のたびに一意でなければならず、公開した後は変更できません (ほかのメタデータも同様)。

• 形式は、セマンティックバージョニングが推奨されるが、任意の文字列も使える。Registry は、並べ替えのためにセマンティックバージョンとして解釈を試み、必要なら「最新 (latest)」の印を付ける。解釈できない形式を後から公開すると、常に最新と印が付く
• バージョンの範囲に見える文字列 (^1.2.3、~1.2.3、>=1.2.3、1.x、1.2.* など) は、誤りを防ぐために禁止されている
• ローカルのサーバーでは、server.json のバージョンと、パッケージのバージョンをそろえる。リモートのサーバーで API のバージョンがあるなら、それにそろえる
• パッケージの実体や URL を変えずに、メタデータだけを更新して再公開したいときは、1.2.3-1 のようなセマンティックなプレリリースのバージョンを使う。ただし、プレリリースは、対応する通常のバージョンより前に並べ替えられるため、通常のバージョンの後にプレリリースを公開しても、「最新」にはならない

server.json の version と packages[].version を手でそろえると、ずれが起きます。リリースの自動化では、タグから値を作って、両方に反映します。

GitHub Actions による自動公開

リリースのタグ (v*) を契機に、パッケージの公開と Registry への公開を、1 つのワークフローで行えます。認証の方式は、GitHub OIDC (推奨)、GitHub の個人アクセストークン (PAT)、DNS から選べます。OIDC なら、専用のシークレットが要りません。

name: Publish to MCP Registry

on:
  push:
    tags: ["v*"]

jobs:
  publish:
    runs-on: ubuntu-latest
    permissions:
      id-token: write # OIDC 認証に必要
      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
      - name: Publish package to npm
        run: npm publish
        env:
          NODE_AUTH_TOKEN: ${{ secrets.NPM_TOKEN }}
      - name: Install mcp-publisher
        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
      - name: Authenticate to MCP Registry
        run: ./mcp-publisher login github-oidc
      - name: Publish server to MCP Registry
        run: ./mcp-publisher publish

PAT を使う場合は、read:org と read:user のスコープを持つトークンを MCP_GITHUB_TOKEN に入れ、mcp-publisher login github --token ... を使います。DNS の場合は、秘密鍵を MCP_PRIVATE_KEY のシークレットに入れます。公式の例には、タグから server.json の version を書き換える手順 (jq で上書き) が、任意の手順として載っています。タグを git push origin v1.0.0 で押すと、テスト、ビルド、npm への公開、Registry への公開が走ります。

注意点として、mcp-publisher を latest のバイナリで取得する手順は、サプライチェーンの観点では、バージョンとハッシュの固定を検討する余地があります。

Server Cards

Server Cards は、リモートの MCP サーバーを、接続の前に発見するためのメタデータ文書です (SEP-2127、拡張トラックで Final)。実行時の server/discover は、接続先がわかってからでないと使えません。Server Card は、その前の段階で、クライアントが、利用できるトランスポート、プロトコルのバージョン、接続の案内を知るためのものです。

• 用途: IDE の拡張機能が、ドメインを指定するだけで自動設定する、Registry やクローラーがドメインを走査してサーバーを索引する、サーバーごとに接続せずに情報を表示する
• 内容: サーバーの識別 (name、version、description、任意で title、icons、repository、websiteUrl)、リモートのエンドポイント (URL、ヘッダー、変数のテンプレート、対応するプロトコルのバージョン)、名前空間付きの _meta。ツール、リソース、プロンプトの定義や、機能 (capabilities) は載せない。これらは、利用者や設定によって変わる動的なものなので、静的な文書では正確に表せないため
• 置き場所: カードは、予約されていない任意の URI に置ける。推奨される場所は、<Streamable HTTP の URL>/server-card。ドメイン単位の発見には、/.well-known/ai-catalog.json に置く AI Catalog が、カードへのリンクか、カードの埋め込みを持つ
• server/discover との関係: 両方に重なる情報 (識別、エンドポイント、プロトコルのバージョン) は、そろえておく。食い違うときは、クライアントは、実行時の server/discover の値を優先する
• Registry の server.json との関係: Server Card は、リモートの接続だけを扱う。ローカルにインストールできるパッケージと、その実行の設定は、server.json の領域。対応する概念 (識別、ドキュメント、リモートのエンドポイント) は、互換性のある形で表される

Server Card は公開の読み取り専用の文書です。認証情報、社内ネットワークの構成、利用者やセッションに固有のデータを、載せてはいけません (MUST NOT)。HTTPS で配り、公開のエンドポイントにはレート制限をかけます。カードの内容は参考情報であり、クライアントは、実行時のメタデータで確かめるため、改ざんされても、影響は主に発見のしやすさに限られます。

仕様の本体 (スキーマ、発見の詳細、CORS やキャッシュの要件) は、SEP ではなく、拡張のリポジトリ (modelcontextprotocol/experimental-ext-server-card) で保守されており、変わり得ます。実装する前に、そのリポジトリの最新のスキーマと docs/discovery.md を確認してください。

モデレーションポリシー

公式 Registry のモデレーションは、かなり寛容です。要約は、「違法なコンテンツ、マルウェア、スパム、まったく動かないサーバーだけを削除する」です。

• 削除する: 違法なコンテンツ (わいせつ、著作権の侵害、ハッキングツール)、意図を問わないマルウェア、スパム (同じサーバーを名前を変えて何度も登録する、固定の応答と宣伝文しか返さないサーバー、説明が宣伝文だらけで実装が無関係なサーバー)、機能しないサーバー
• 削除しない: 品質が低いか不具合のあるサーバー、セキュリティの脆弱性を持つサーバー、ほかと同じことをするサーバー、成人向けのコンテンツを持つサーバー
• 削除の方法: サーバーの status を "deleted" にする。メタデータは、API からなお取得でき、アグリゲーターが、自分の索引から外す。違法なメタデータなどの極端な場合は、上書きや消去もある
• 異議申し立て: GitHub のリポジトリに、サーバー名と、削除の基準に当たらないと考える理由を添えて issue を出す

このポリシーは公式 Registry にだけ適用され、サブレジストリは、独自のポリシーを持つことがあります。また、消費する側は、モデレーションが最小限か、ほとんどないものと想定しなければなりません。公式 Registry は、能動的な審査の能力が限られ、上流のパッケージレジストリや、下流のサブレジストリに、深い審査を任せています。脆弱なサーバーも削除されないため、Registry に載っていることを、利用の根拠にしてはいけません。

組織内での承認とガバナンス

組織が MCP サーバーを使うとき、公式 Registry を、そのまま従業員の入口にするのは危険です。モデレーションが最小限で、脆弱なサーバーも、似た名前のサーバーも載るためです。また、公式 Registry は私的なサーバーに対応していません。組織の入口は、承認したサーバーだけを提供する、自前の仕組みにします。

• プライベートレジストリ: 公式 Registry の OpenAPI の仕様に準拠したレジストリを、組織で用意すれば、その仕様に対応した既存のホストアプリケーションを利用できる。公式 Registry のコードベースは、自前でのホストを想定していないため、仕様に準拠した実装を選ぶか、自作する。承認したサーバーだけの server.json を登録する
• 許可リスト: 許可したサーバー (名前、バージョン、出所) だけを、クライアントやゲートウェイで使えるようにする。バージョンは固定し、更新は審査を通す。許可リストの外のサーバーの接続は、ゲートウェイやネットワークの制御で止める。組織内の多数のサーバーを集約するゲートウェイ (MCP Server Portals など) の構成は、MCPの認可拡張とエンタープライズ導入 を参照
• 導入前の審査: 次の観点で確認する。公開者と名前空間は、検証された組織のものか。ソースを読め、保守が続いているか。要求する権限 (環境変数、ファイル、ネットワーク、OAuth のスコープ) は、目的に対して最小か。ローカルで動かす必要があるか、リモートで足りないか (ローカルMCPサーバーの安全な運用)。リモートの場合、データがどこに送られ、どう保管されるか
• ツール汚染とサプライチェーンのチェック: ツールの description に、モデルへの指示が紛れていないか (Inspector でモデルを介さずに一覧を読む)。承認後に定義を書き換える Rug pull を検出するため、ツール定義を記録し、変更があれば再承認する (AIエージェント特有の脅威 - プロンプトインジェクションとツール汚染)。パッケージは、バージョンを固定し、コンテナーならダイジェストで固定する。MCPB は fileSha256 を確認する。署名、attestation、SBOM があれば検証し、依存関係の脆弱性を走査する
• 継続的な棚卸し: 承認の時点の安全性は、永続しません。利用状況、バージョンの更新、公開者の変更、脆弱性の公表を監視して、再審査する。使われなくなったサーバーは、許可リストから外す
• 自組織のサーバーの公開: 自分たちで作ったサーバーを、外部に公開するかどうかも、ガバナンスの対象。社内の私的なサーバーは、公式 Registry に載せられない (対象外)。公開するサーバーは、組織のドメインの名前空間で登録し、秘密鍵と公開の権限を、少数の担当者に限る

審査は、悪い信頼判断の確率を下げ、隔離や最小の権限は、悪い判断の代償を決めます。どちらか一方に頼らず、組み合わせます。

2. 配布方法

方法	対象	補足
パッケージ (npm / PyPI / NuGet / Docker)	ローカルの stdio サーバー	バージョン固定と署名の確認を推奨
リモート URL	Streamable HTTP のサーバー	認可方式をメタデータで明示
公式 Registry	公開サーバーの発見性	名前空間の所有証明が必要
Server Cards	HTTP サーバーの自己記述	<URL>/server-card に置く。ドメイン単位の発見は AI Catalog (/.well-known/ai-catalog.json)
社内レジストリ	組織が承認したサーバーのみ	許可リストと審査プロセス

3. 開発者がつまずきやすいポイント

mcpName と server.json の name が一致しない

npm の package.json の mcpName と、server.json の name は、同じ文字列でなければなりません。PyPI、NuGet、Cargo は README の mcp-name:、OCI はラベルが、それに当たります。公開の前に、パッケージ側を先に公開し直す必要があるのが、手間になりやすい点です。

Cargo の README で、HTML コメントに mcp-name を書く

PyPI と NuGet では、HTML コメントに隠して書けますが、crates.io は HTML コメントを除去するため、検証が通りません。Cargo では、見える文字で書きます。

GitHub 認証なのに、別の名前空間で公開しようとする

GitHub 認証では、io.github.<自分>/ で始まる名前だけが公開できます。独自のドメインの名前を使うなら、DNS か HTTP の認証が必要です。

同じバージョンで、メタデータだけを直して再公開する

バージョンは、公開のたびに一意で、公開後は変更できません。メタデータだけの更新には、1.2.3-1 のようなプレリリースを使います。ただし、通常のバージョンの後に公開したプレリリースは、「最新」になりません。

公式 Registry に載ったから安全だと考える

Registry は、名前空間の所有を認証しますが、コードの安全性は保証しません。脆弱なサーバーも削除されません。組織では、審査と許可リストを別に持ちます。

社内のサーバーを公式 Registry に載せようとする

私的なネットワークや、私的なパッケージレジストリのサーバーには、対応していません。プライベートレジストリを用意します。

Server Card に、ツールの一覧や認証情報を書く

Server Card は、公開の読み取り専用の文書で、ツールやリソース、機能の定義を持ちません。認証情報や、利用者固有のデータを載せてはいけません。ツールの一覧は、実行時に、利用者の認可のもとで tools/list を呼んで得ます。

Server Card の場所を .well-known の固定のパスだと思う

SEP の文面では、カードの推奨の場所は <Streamable HTTP の URL>/server-card で、.well-known の固定のパスを使うのは、AI Catalog (/.well-known/ai-catalog.json) のほうです。実装の前に、拡張のリポジトリの最新の仕様を確認してください。

4. コード例

npm パッケージ (stdio) の server.json

{
  "$schema": "https://static.modelcontextprotocol.io/schemas/2025-12-11/server.schema.json",
  "name": "io.github.my-username/weather",
  "description": "An MCP server for weather information.",
  "repository": {
    "url": "https://github.com/my-username/mcp-weather-server",
    "source": "github"
  },
  "version": "1.0.1",
  "packages": [
    {
      "registryType": "npm",
      "identifier": "@my-username/mcp-weather-server",
      "version": "1.0.1",
      "transport": { "type": "stdio" }
    }
  ]
}

対応する package.json には、"mcpName": "io.github.my-username/weather" が必要です。

リモートサーバーと、テンプレート変数、ヘッダー

{
  "$schema": "https://static.modelcontextprotocol.io/schemas/2025-12-11/server.schema.json",
  "name": "com.example/acme-analytics",
  "title": "ACME Analytics",
  "description": "Real-time business intelligence and reporting platform",
  "version": "2.0.0",
  "remotes": [
    {
      "type": "streamable-http",
      "url": "https://{tenant_id}.analytics.example.com/mcp",
      "variables": {
        "tenant_id": {
          "description": "Your tenant identifier (e.g., 'us-cell1', 'emea-cell1')",
          "isRequired": true
        }
      },
      "headers": [
        {
          "name": "X-API-Key",
          "description": "API key for authentication",
          "isRequired": true,
          "isSecret": true
        }
      ]
    }
  ]
}

OCI イメージと MCPB

{
  "packages": [
    {
      "registryType": "oci",
      "identifier": "docker.io/yourusername/kubernetes-manager-mcp:1.0.0",
      "transport": { "type": "stdio" }
    },
    {
      "registryType": "mcpb",
      "identifier": "https://github.com/username/image-processor-mcp/releases/download/v1.0.0/image-processor.mcpb",
      "fileSha256": "fe333e598595000ae021bd27117db32ec69af6987f507ba7a63c90638ff633ce",
      "transport": { "type": "stdio" }
    }
  ]
}

OCI のイメージには、LABEL io.modelcontextprotocol.server.name="<サーバー名>" を付けます。

DNS 認証の TXT レコードを作る (Ed25519)

MY_DOMAIN="example.com"

# 鍵のペアを作る
openssl genpkey -algorithm Ed25519 -out key.pem

# TXT レコードを作る
PUBLIC_KEY="$(openssl pkey -in key.pem -pubout -outform DER | tail -c 32 | base64)"
echo "${MY_DOMAIN}. IN TXT \"v=MCPv1; k=ed25519; p=${PUBLIC_KEY}\""

# TXT レコードの伝搬後にログインする
PRIVATE_KEY="$(openssl pkey -in key.pem -noout -text | grep -A3 "priv:" | tail -n +2 | tr -d ' :\n')"
mcp-publisher login dns --domain "${MY_DOMAIN}" --private-key "${PRIVATE_KEY}"

key.pem と PRIVATE_KEY は、リポジトリやシェルの履歴に残さず、シークレットの管理の仕組みで保管します。

組織の許可リスト (設計の例)

許可リストの形式は、使うクライアントやゲートウェイによって異なります。管理の観点を示すための例です。

{
  "allowedServers": [
    {
      "name": "io.github.my-org/internal-tools",
      "version": "1.4.2",
      "source": "npm:@my-org/[email protected]",
      "approvedBy": "security-review-2026-10",
      "toolsDigest": "sha256:…",
      "scopes": ["tools:read"]
    }
  ]
}

toolsDigest は、承認時の tools/list の結果のハッシュで、定義が変わったことを検出して再審査につなげるためのものです。

5. まとめ

• 公式 MCP Registry は、公開サーバーのメタデータ (server.json) の中央リポジトリで、成果物はホストしない。現在はプレビュー版なので、手順とスキーマは、公開の前に最新を確認する。私的なサーバーには対応せず、ホストアプリケーションは、下流のレジストリを使う
• 公開は、検証用の情報をパッケージに足し、パッケージを公開してから、mcp-publisher で server.json を公開する。サーバー名は、名前空間の所有を示す
• パッケージの種類は、npm、PyPI、NuGet、Cargo、OCI、MCPB。種類ごとに、所有の検証の方法が違う (mcpName、README の mcp-name:、OCI のラベル)
• リモートのサーバーは、remotes で公開し、テンプレート変数とヘッダーを指示できる。認可の方式そのものは、実行時のメタデータで伝える
• 認証は、GitHub か、ドメイン (DNS、HTTP) で、名前空間が決まる。組織のサーバーは、組織のドメインか組織の GitHub の名前空間で公開する
• バージョンは、公開ごとに一意で、公開後は変更できない。セマンティックバージョニングを使い、メタデータだけの更新にはプレリリースを使う
• GitHub Actions で、タグを契機にパッケージと Registry へ公開できる。OIDC なら、専用のシークレットは要らない
• Server Cards は、リモートサーバーを接続前に発見するための公開の文書で、ツールや機能を持たない。仕様の本体は拡張のリポジトリにあり、変わり得る
• 公式 Registry のモデレーションは寛容で、脆弱なサーバーも削除しない。載っていることは、安全性の根拠にならない。組織は、プライベートレジストリ、許可リスト、導入前の審査、ツール定義の固定、継続的な棚卸しを組み合わせる

関連ドキュメント

• MCPサーバーの実装 - SDKとGo・C#
• MCPサーバーのデプロイと運用
• ローカルMCPサーバーの安全な運用
• MCPの認可拡張とエンタープライズ導入
• AIエージェント特有の脅威 - プロンプトインジェクションとツール汚染
• MCP拡張機能 - Tasks・MCP Apps・Skills

参考資料

• About the MCP Registry
• Quickstart: Publish an MCP Server
• Supported Package Types
• Publishing Remote Servers
• Authentication when publishing
• SEP-2127: MCP Server Cards
• Versioning Published MCP Servers
• Automate Publishing with GitHub Actions
• MCP Registry Moderation Policy