mcp-publisherで公開するMCPサーバーの登録手順

mcp-publisherは何を送るCLIか

mcp-publisher は、開発したMCPサーバーをMCP Registryへ登録する公式CLIです。認証つきで送るのは server.json というメタデータだけで、サーバー本体のコードやバイナリはホストしません。実体は先にnpmなどのパッケージレジストリへ置き、Registryはそこを指す名札を持つ設計です。

MCP Registryには、プレビュー段階であり、GA前に破壊的変更やデータのリセットが起こりうるという注記があります。手順が変わっていないかは、公開の前に公式のクイックスタートと見比べると安心です。

ここで扱うのは、ローカルで動かしてnpmで配布するパッケージ型のサーバーです。server.json の各フィールドはserver.jsonの書き方、GitHub以外の認証はMCP Registryの認証方式3種にあります。HTTPエンドポイントで提供するリモート型ならnpm公開が要らず、書き方も変わるためMCP Registryへのリモートサーバー公開手順を参照してください。

公開はnpm・CLI導入・Registry登録の順に進む

用意するものはNode.js、npmアカウント、GitHubアカウントです。TypeScript製のサーバーを前提にしており、npmアカウントはパッケージの置き場所に、GitHubアカウントはRegistry側の本人確認に使います。

手元にTypeScript製のサーバーがなければ、公式の quickstart-resources リポジトリの weather-server-typescript をコピーして進められます。

git clone --depth 1 git@github.com:modelcontextprotocol/quickstart-resources.git
cp -r quickstart-resources/weather-server-typescript .
rm -rf quickstart-resources
cd weather-server-typescript

ステップ1: npmにサーバーパッケージを公開する

まず package.json の name をスコープ付きの一意な名前に、version を公開したい値に書き換えます。

 {
-  "name": "mcp-quickstart-ts",
-  "version": "1.0.0",
+  "name": "@my-username/mcp-weather-server",
+  "version": "1.0.1",
   "main": "index.js",

続けて description と repository を実態に合わせます。

   "license": "ISC",
-  "description": "",
+  "repository": {
+    "type": "git",
+    "url": "https://github.com/my-username/mcp-weather-server.git"
+  },
+  "description": "An MCP server for weather information.",
   "devDependencies": {

最後に、Registryが所有権を確かめるための mcpName を足します。

 {
   "name": "@my-username/mcp-weather-server",
   "version": "1.0.1",
+  "mcpName": "io.github.my-username/weather",
   "main": "index.js",

mcpName がRegistry上のサーバー名になります。GitHub認証を使うなら、先頭は必ず io.github.あなたのユーザー名/ にします。

ビルドしてnpmへ公開します。

npm install
npm run build
npm adduser
npm publish --access public

スコープ付きのパッケージ名では、クイックスタートの手順のとおり npm publish --access public を使います。コードを直したときは、古い dist のまま公開しないよう npm run build からやり直します。公開後は、https://www.npmjs.com/package/@my-username/mcp-weather-server のようなパッケージページが開けることを確かめてから次へ進みます。

ステップ2: mcp-publisherをインストールする

macOS / Linuxはプリビルドバイナリを取得します。

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 && sudo mv mcp-publisher /usr/local/bin/

Homebrewを使っているなら次の1行で済みます。

brew install mcp-publisher

Windows(PowerShell)は、CPUがArm64かどうかを判定して対応する .tar.gz を取得し、展開した mcp-publisher.exe をPATHの通ったディレクトリへ移します。

$arch = if ([System.Runtime.InteropServices.RuntimeInformation]::ProcessArchitecture -eq "Arm64") { "arm64" } else { "amd64" }
Invoke-WebRequest -Uri "https://github.com/modelcontextprotocol/registry/releases/latest/download/mcp-publisher_windows_$arch.tar.gz" -OutFile "mcp-publisher.tar.gz"
tar xf mcp-publisher.tar.gz mcp-publisher.exe
rm mcp-publisher.tar.gz

CIのようにパッケージマネージャーを増やしたくない環境ではバイナリの直接取得が、普段からHomebrewを使う環境ではbrewが手軽です。

導入できたかは --help で確かめます。

mcp-publisher --help

公式のクイックスタートに載っている出力例では、init / login / logout / publish の4サブコマンドが並びます。

ステップ3: server.jsonを作りRegistryへ公開する

プロジェクトの直下で mcp-publisher init を実行すると、server.json のひな形が生成されます。

mcp-publisher init

生成された server.json は、name を package.json の mcpName と一致させ、version を公開したい値にそろえます。ひな形に入るサンプルの environmentVariables(YOUR_API_KEY)は、サーバーが使わないなら消します。続いてGitHubアカウントで認証します。

mcp-publisher login github

実行するとデバイスコードが表示されます。

Logging in with github...
 
To authenticate, please:
1. Go to: https://github.com/login/device
2. Enter code: ABCD-1234
3. Authorize this application
Waiting for authorization...

表示されたURL(github.com/login/device)をブラウザーで開き、ターミナルに表示されたコードを入力して認可します。認可の操作はブラウザーで行います。完了するとターミナルに Successfully authenticated! と出ます。

最後に公開します。

mcp-publisher publish

Successfully published と、公開したサーバー名・バージョンが表示されれば完了です。REST APIで検索して、登録を確かめられます。

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

検索結果のJSONに自分のサーバー名が含まれていれば、登録は成功しています。

公開前に名前とバージョンの食い違いを検出する

初回公開の失敗は、mcpName と server.json の name の不一致に集まります。公開に何度か失敗して修正を重ねると、片方のファイルだけ直してもう片方を忘れがちです。jq が入っていれば、公開の直前に次のスクリプトで3つのファイルの値を並べられます。

#!/bin/bash
mcp=$(jq -r .mcpName package.json)
name=$(jq -r .name server.json)
echo "mcpName      : $mcp"
echo "server.name  : $name"
[ "$mcp" = "$name" ] && echo "OK  名前が一致" || echo "NG  名前が不一致"
echo "package.json version        : $(jq -r .version package.json)"
echo "server.json version         : $(jq -r .version server.json)"
echo "server.json packages version: $(jq -r '.packages[0].version' server.json)"

package.json を1.0.1に上げ、server.json のトップレベルだけ1.0.1にして、packages 内の version を1.0.0のまま残した状態で実行すると、次のように出ます。

mcpName      : io.github.my-username/weather
server.name  : io.github.my-username/weather
OK  名前が一致
package.json version        : 1.0.1
server.json version         : 1.0.1
server.json packages version: 1.0.0

名前は一致していても、packages 内の version だけが古いままです。publish の前にこの出力を見れば、バージョンの3か所のずれをその場で拾えます。

認証方式でサーバー名の前置きが決まる

ステップ3で io.github. を使ったのは、GitHub認証を選んだからです。Registryでは、認証方式がサーバー名の名前空間を決めます。

ドメイン認証の証明は、公開鍵を載せた1行の文字列です。DNS方式ではTXTレコードに、HTTP方式では /.well-known/mcp-registry-auth のファイルに、同じ形式で書きます。

v=MCPv1; k=ed25519; p=<公開鍵のbase64>

鍵の種類はEd25519かECDSA P-384で、鍵の保管にGoogle KMSやAzure Key Vaultも使えます。TXTレコードは反映まで数分かかることがあり、反映後に mcp-publisher login dns --domain <ドメイン> --private-key <秘密鍵> で認証します。

エラー表の3行目、You do not have permission to publish this server は、この対応が崩れたときに出ます。クイックスタートの表には、GitHub認証ではサーバー名が io.github.ユーザー名/ で始まる必要があると書かれています。GitHub認証のまま別の前置きの名前を公開しようとすると、この条件に合いません。

バージョンを上げて出し直す

公開済みの server.json は、同じバージョン番号のまま内容だけを直して再公開できません。公式のバージョン管理のページには、公開ごとにバージョン文字列が一意であること、公開後はバージョン文字列(とほかのメタデータ)を変更できないことが書かれています。誤字を直すだけでも、package.json と server.json の version を上げ、npm publish と mcp-publisher publish をやり直します。

更新時に見直すのは3か所です。

ローカル実行型のサーバーでは、サーバー側のバージョンをパッケージのバージョンに合わせると混乱を避けられます。

バージョン文字列の形式には、セマンティックバージョニングが推奨されています。次のような点があります。

• ^1.2.3・~1.2.3・>=1.2.3・1.x のような範囲指定は、誤りを防ぐためRegistryが拒否します。
• 2025.06.18 のようなゼロ詰めの日付は通りますが、公式の表では注意つきです。2025-06-18 も非セマンティックなバージョンとして許可されています。
• セマンティックバージョンとして解釈できない文字列を公開すると、並び順にかかわらず「latest」と扱われます。セマンティックな版が並ぶ中に1つ混ぜると、その版が最新になります。

description はRegistryに載るメタデータなので、空欄や仮の文字列のまま初回公開すると、直すだけで新しいバージョンが必要になります。

公開後によくあるつまずき

公式のトラブルシューティング表にあるエラーは3つです。

手動公開の次に検討すること

バージョンを上げるたびに同じコマンドを打つ運用は、リリース回数が増えるほど手間になります。GitHub Actionsへ組み込む方法はMCP RegistryへGitHub Actionsで自動公開する手順にあります。

この記事のnpm以外にも、mcp-publisher はPyPI・NuGet・Cargo・OCIイメージ・MCPBの形式を扱えます。パッケージ型ごとに、所有権を確かめる場所が変わります。

npmは公開レジストリ(registry.npmjs.org)のみが対象です。Rustのサーバーは、crates.ioで配るCargoだとエンドユーザーにRustツールチェーンが要り、MCPBならビルド済みバイナリを配れるのでツールチェーンが要りません。

PyPI・NuGetは、READMEに mcp-name の文字列があればよく、HTMLコメントの中でも構いません。Cargoはcrates.ioがREADMEのHTMLコメントを除去するため、mcp-name: を通常の本文として書きます。種別ごとの server.json の書き分けはMCP Registryが対応するパッケージ種別にあります。

まとめ

公開のつまずきは名前の不一致に集まるので、mcp-publisher publish の前に mcpName と server.json の name、バージョン3か所を並べて見る習慣が効きます。一度公開したバージョンは直せない前提で、出し直すときは version を上げます。