MCP Registryのパッケージ種別 — npm・PyPI・Docker対応の要件

MCP Registryは、公開されているMCPサーバーの所在情報を集約する公式リポジトリです。対応するパッケージ形式はnpm・PyPI・NuGet・Cargo(Rust)・Docker/OCI・MCPBの6種類で、種類ごとにserver.jsonの書き方と所有権の証明方法が変わります。どの形式を選ぶかで公開後の運用も変わるため、着手前に対応表を押さえておく必要があります。

MCP Registryが担うのは配布ではなくメタデータ

MCP Registryは、npmやPyPIのようにコードそのものをホストしません。管理するのはメタデータだけです。Anthropic・GitHub・PulseMCP・Microsoftなど主要コントリビューターが支える、サーバーの所在情報を集めた台帳という位置付けです。

実体のコードは既存のパッケージレジストリに置いたまま、MCP Registryは「どのレジストリの、どのパッケージが、どのMCPサーバーに対応するか」という対応関係だけをserver.jsonという標準フォーマットで保持します。たとえばweather-mcpというnpmパッケージがあれば、MCP Registry側では「weather v1.2.0というサーバーはnpm:weather-mcpに対応する」という記録を持つだけです。コードの配布責任は元のレジストリ側に残ります。

なお、MCP Registryは現時点でpreview段階にあり、公式ドキュメントは「一般提供(GA)前に破壊的変更やデータリセットが起こりうる」と明記しています。登録したserver.jsonの内容やメタデータが予告なくリセットされる可能性があるため、本番運用の前提にする際はこの点を踏まえておく必要があります。

この構造のため、MCP Registryに公開する前に、実体のパッケージを既存レジストリ(npm・PyPI・crates.io等)へ先に公開しておく必要があります。パッケージを持たず、URLだけで動くリモートサーバーの公開手順はリモートMCPサーバーをMCP Registryに公開する方法で扱っています。

6つのパッケージ種別と対応レジストリの早見表

MCP Registryが対応するパッケージ種別は次の6つです。registryTypeの値ごとに、対応する実際のレジストリが決まっています。

どの種別も、対応先は公式レジストリ1つに絞られています。npmならnpmjs.org以外のプライベートレジストリは対象外です。対応レジストリはコミュニティの需要次第で増える可能性がありますが、追加を望む場合は公式リポジトリでissueを起票する経路が案内されているだけで、この6種類より広げる計画が公式に示されているわけではありません。

1つのサーバーに複数のregistryTypeを併記できます。packages配列に複数のエントリーを並べれば、同じバージョンのサーバーをnpmとNuGetの両方で同時に公開できます。CLIツールをまず自分の得意なエコシステムで配布し、あとから別のエコシステム向けパッケージを追加する運用も可能です。

npm・PyPI・NuGetの所有権証明は書き方が違う

3つとも「識別子をパッケージに埋め込む」方式ですが、埋め込み先と書式が異なります。

npmだけはpackage.jsonに専用フィールドを持ちます。

{
  "name": "@username/email-integration-mcp",
  "version": "1.0.0",
  "mcpName": "io.github.username/email-integration-mcp"
}

PyPIとNuGetにはpackage.jsonに相当する専用フィールドがありません。そのため、READMEにmcp-name: $SERVER_NAMEという文字列を埋め込みます。コメントの中に隠しても検証は通ります。

<!-- mcp-name: io.github.username/database-query-mcp -->

この$SERVER_NAMEの部分は、server.jsonのnameフィールドと完全一致していなければ検証に失敗します。PyPIの場合、公開ページ上ではコメントは見えませんが、検証システムは元のMarkdownソースを読むため隠しコメントでも通ります。

Cargo対応で見落としやすい落とし穴

Cargoも同じmcp-name:方式を使いますが、挙動が1つだけ違います。crates.ioはMarkdown→HTML変換の過程でHTMLコメントを削除します。PyPIやNuGetで通用する<!-- mcp-name: ... -->という隠しコメントは、Cargoでは検証対象のHTMLに現れず、そのまま失敗します。

Cargo向けには、コメントではなく可視のMarkdownテキストとしてmcp-name:を書く必要があります。公式が推奨するのは、Linksセクションの箇条書きに含める書き方です。

- MCP Registry name: `mcp-name: io.github.username/widget-mcp`

Cargoにはもう1つ特有の事情があります。cargo installはコンパイル済みバイナリを~/.cargo/binに配置する一度きりのインストール方式で、npmのnpxやPyPIのuvxのような、実行のたびにレジストリへ取りに行く起動方式に相当するものがありません。インストールは1回、実行はバイナリ名指定という別モデルです。そのためCargo向けのserver.jsonサンプルにはruntimeHintを書きません。Rustのツールチェーンを前提にしたくない場合は、Cargoではなく次に扱うMCPB形式でバイナリ配布する選択肢もあります。

Docker/OCIとMCPBの検証方法

Docker/OCIイメージは、対応レジストリの選択肢が5つに広がります。Docker Hub・GitHub Container Registry・Google Artifact Registry・Azure Container Registry・Microsoft Container Registryです。所有権の証明はDockerfileへのラベル1行で完結します。

LABEL io.modelcontextprotocol.server.name="io.github.username/kubernetes-manager-mcp"

identifierの書式はレジストリ/名前空間/リポジトリ:タグで、タグの代わりにダイジェストを指定することもできます。

MCPBは他の5形式と性格が異なり、パッケージレジストリではなくGitHub・GitLabのリリースアセットとして配布します。エンドユーザー側にnpmやRustのようなランタイムを要求しないため、Claude DesktopのMCP設定のようにワンクリック導入を想定する用途に向きます。検証は「URLに"mcp"の文字列を含む」ことと「fileSha256でSHA-256ハッシュを明記する」ことの2点です。ハッシュそのものはMCP Registryが検証するわけではなく、インストール時にMCPクライアント側がファイルの整合性を確認する仕組みです。

openssl dgst -sha256 image-processor.mcpb

MCPBの仕組みと拡張子の由来はDesktop Extensionsの解説記事で扱っています。

タグとダイジェスト、どちらで固定するか

OCIイメージのidentifierはレジストリ/名前空間/リポジトリ:タグという書式ですが、タグ部分はダイジェスト(sha256ハッシュ)に置き換えられます。1.0.0のような可変タグは、公開後に元のレジストリ側でイメージを差し替えられてしまう余地が残ります。再現性を優先するなら、タグではなくダイジェストで固定する運用が安全です。ただしダイジェスト指定は人間が読んで版数を判断できないため、リリースノートやREADME側でタグとダイジェストの対応を別途記録しておく必要があります。

npmとPyPIのidentifierにも書式の違いがあります。npmはスコープ付きパッケージ名(@username/package-name)をそのまま使えますが、PyPIにはスコープの概念がなく、パッケージ名がグローバルな単一名前空間を共有します。命名の衝突を避けたい場合、PyPI向けのパッケージ名だけ事前に確保しておく判断が必要になります。

Anthropic Connectors Directoryとの違い

パッケージ種別を調べる過程で混同しやすいのが、Anthropicが運営するConnectors Directoryとの違いです。MCP Registryはプロトコルレベルの公式台帳で、対応レジストリの検証を通ればどのMCPクライアントからも参照できます。一方Connectors Directoryは、claude.aiやClaude Desktopの連携一覧に掲載するための審査付きディレクトリで、掲載基準はAnthropic独自です。

同じサーバーを両方に登録することは妨げられていません。むしろMCP Registryへの登録はエコシステム全体への発見可能性を担い、Connectors Directoryへの掲載はClaude製品内での露出を担うという役割分担になります。

なぜ1つの標準形式に絞らないのか

MCP Registryが6種類ものパッケージ形式を並行対応させているのは、既存エコシステムへの参入障壁を下げるためです。Rust開発者はcrates.ioへのcargo installという使い慣れた配布経路をそのまま維持でき、ツールチェーンを持たない利用者向けにはMCPBのバイナリ配布を別途用意できます。npm・PyPI・NuGetの3つも、各言語コミュニティが既に信頼している配布経路を流用する設計です。

一本化を急がず、開発者が慣れた配布経路をそのまま使えるようにする判断です。セキュリティスキャンについても、MCP Registry自身は実施せず、npmやPyPI・Docker Hubといった元のレジストリの検査機能に委ねています。名前空間の認証とメタデータのホスティングに専念し、コード自体の安全性チェックはエコシステムの分業に任せる設計だと言えます。

サーバー名がio.github.username/*のような逆引きDNS形式になっているのも、この分業を支える仕組みです。パッケージ種別を問わず同じ命名規則を使うことで、GitHubアカウントやドメインの所有権確認だけで、どの配布経路を選んでもなりすましを防げます。

まとめ

MCP Registryへの公開は、まずどのパッケージレジストリに実体を置くかを決め、そのレジストリに応じた所有権証明をserver.jsonに対応させる作業です。npm・PyPI・NuGetは埋め込み文字列、Docker/OCIはイメージラベル、MCPBはハッシュ明記、Cargoだけは可視テキストという固有の注意点があります。パッケージを持たないリモートサーバーの公開手順は前段で触れた記事、公開後のバージョン管理はMCP Registryのバージョニングルールで扱っています。