Claude Media
mcp-publisherで公開するMCPサーバーの登録手順
MCPClaude Codeチュートリアル

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

mcp-publisher CLIでMCPサーバーをMCP Registryに公開する手順を、npm公開・CLIインストール・server.json作成の3ステップで解説します。

読了目安 約20分

mcp-publisherとは何をするCLIか

mcp-publisher は、開発したMCPサーバーをMCP Registryへ登録するための公式CLIツールです。役割は「server.json というメタデータファイルを認証つきでRegistryに送信する」ことに限られます。サーバー本体のコードやバイナリはホストしません。

この記事は、初めてサーバーを公開する人が迷いやすい「npm公開・CLIインストール・Registry登録」という3つの作業の順序と実行コマンドに絞ります。server.json の各フィールドの意味やパッケージ種別ごとの書き方はserver.jsonの書き方に譲り、GitHub認証以外の認証方式(DNS・HTTP)の選び方はMCP Registryの認証方式3種に譲ります。

なお、この記事が扱うのはローカルで実行してnpmで配布するパッケージ型のサーバーです。HTTPエンドポイントとして提供するリモート型のサーバーであれば、npmへの公開自体が不要になり、server.json の書き方も変わります。リモート型を公開したい場合はMCP Registryへのリモートサーバー公開手順を参照してください。

公開までに必要な3つの前提

公開作業に入る前に、次の3つを用意します。

  • Node.js: この手順はTypeScript製サーバーを前提にします
  • npmアカウント: MCP Registryはメタデータのみを扱うため、サーバー本体は先にnpmへ公開する必要があります
  • GitHubアカウント: MCP Registryは複数の認証方式に対応しますが、この記事では最も手軽なGitHub認証を使います

この3つはどれか1つでも欠けると、公開作業を最後まで進められません。Node.jsが無ければサーバー自体をビルドできず、npmアカウントが無ければパッケージを置く場所が無く、GitHubアカウントが無ければRegistry側の本人確認ができないためです。手元の環境にどれか不足していないかを作業に入る前に確認しておくと、手順の途中で不足に気づいて後戻りする事態を避けられます。

手元にTypeScript製のMCPサーバーがない場合は、公式の 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にサーバーパッケージを公開する

MCP Registryはメタデータだけを保持し、実体のコードは既存のパッケージレジストリに置いたままにする設計です。そのため、Registryへ登録する前にサーバー自体をnpmへ公開しておく必要があります。

まず package.json の name をスコープ付きの一意な名前に書き換えます。

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

続けて description と repository を実態に合わせて書き換えます。空の description を残したままだと、Registry検索やマーケットプレイス一覧でサーバーの内容が伝わりません。

   "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",

GitHub認証を使う場合、mcpName は必ず io.github.あなたのユーザー名/ で始まる必要があります。ここが一致していないと、後述の公開ステップで権限エラーになります。

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

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

npmのパッケージページ(https://www.npmjs.com/package/@my-username/mcp-weather-server のようなURL)が開けることを確認してから次に進みます。ここまではMCP Registryではなくnpmだけの話なので、通常のnpmパッケージ公開の勘所がそのまま当てはまります。

@my-username/... のようなスコープ付きパッケージ名は、npmの既定では非公開扱いになります。npm publish に --access public を付け忘れると公開自体が失敗するので、スコープ付き名前を使う場合はこのフラグを常にセットで覚えておく必要があります。ビルド(npm run build)を挟み忘れて古い dist の中身のまま公開してしまうのもよくある失敗で、コードを変更したら公開前に必ずビルドをやり直します。

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

mcp-publisher はプリビルドバイナリまたはHomebrewで導入できます。3種類の環境それぞれのコマンドは以下のとおりです。

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:

brew install mcp-publisher

Windows(PowerShell):

$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

Windows版はCPUアーキテクチャ(Arm64かどうか)を判定してから対応する .tar.gz を取得し、展開後は mcp-publisher.exe をPATHの通ったディレクトリに移動しておきます。

インストール方法が3種類用意されているのは、開発者が使っているOSやパッケージ管理の好みが異なるためです。すでにHomebrewを日常的に使っているならbrewコマンドが手っ取り早く、CI環境のように余計なパッケージマネージャーを増やしたくない場合はプリビルドバイナリを直接取得する方法が向いています。どの方法を選んでも、最終的に mcp-publisher コマンドがターミナルからそのまま呼び出せる状態になっていれば違いはありません。

インストールできたかは --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 が公開したいバージョンになっているかを確認して編集します(フィールドごとの詳細は前述の「server.jsonの書き方」を参照してください)。

編集が済んだら、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! と表示されます。

この方式はGitHubアカウントのパスワードやトークンをmcp-publisherへ直接渡さずに済むための仕組みです。ブラウザー側で既にGitHubへログイン済みであれば、コードを入力するだけで数秒のうちに認可が完了します。一度認証を済ませればセッションが有効な間は再ログインを求められないため、同じ端末から複数回publishを試す場合も毎回この手順を踏み直す必要はありません。

最後に公開コマンドを実行します。

mcp-publisher publish

Successfully published と表示されれば完了です。公開結果はREST APIで検索して確認できます。

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

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

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

初回公開でつまずくのは、ほぼ次の3パターンに集約されます。

エラーメッセージ原因と対処
Registry validation failed for package原因と対処package.json に mcpName が無い、または server.json の name と不一致
Invalid or expired Registry JWT token原因と対処認証セッションが切れている。mcp-publisher login github をやり直す
You do not have permission to publish this server原因と対処認証方式とサーバー名の名前空間が食い違っている(GitHub認証なのに name が io.github. で始まっていない)

3つ目のエラーは、mcpName を書いた段階では正しかったのに、server.json を後から手で編集して name を変えてしまったときにも起きます。npm側の mcpName とRegistry側の server.json の name は、公開の直前まで文字列として突き合わせておくのが確実です。

いずれのエラーも、mcp-publisher publish を実行してから初めて発覚するものばかりではありません。npm publish の前に package.json の mcpName を、mcp-publisher publish の前に server.json の name をそれぞれ目視で見比べておけば、大半は未然に防げます。特に公開に一度失敗して修正を重ねているうちに、片方のファイルだけ書き換えてもう片方を直し忘れるケースが起きやすいため、公開直前に両方のファイルを並べて確認する一手間が有効です。

公開後に誤字を見つけても、server.json の中身だけを直して同じバージョン番号のまま再公開することはできません。バージョン文字列は公開後に変更できない仕様のようです。そのため、軽微な修正であっても package.json と server.json の両方で version を1つ上げてから、npm publishとmcp-publisher publishをやり直す必要があります。description はRegistryの検索結果にそのまま表示されるため、空欄や仮の文字列のまま初回公開しないよう、事前に埋めておくと確実です。

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

ここまでの手順はすべて手元のターミナルから手動で実行しています。バージョンを上げるたびに同じコマンドを打つ運用は、リリースの回数が増えるほど手間になります。GitHub Actionsのワークフローに組み込んで自動化する方法はMCP RegistryへGitHub Actionsで自動公開する手順にまとめています。

また、mcp-publisher はnpm・PyPI・NuGet・Cargo・OCIイメージ・MCPBの6種類のパッケージ形式に対応しており、この記事で扱ったnpm以外の形式では所有権の確認方法が変わります。パッケージ種別ごとの server.json の書き分けは、冒頭で触れた「server.jsonの書き方」で扱っています。

新しいバージョンを重ねて公開する場合は、package.json の version を上げてから npm publish をやり直し、server.json 側の version と packages 内の version も同じ値に揃えたうえで mcp-publisher publish を再実行します。片方だけ更新すると、Registry側のメタデータと実際に配布されているパッケージのバージョンがずれるので、更新時は3か所(npm・server.json のトップレベル・packages エントリ)を必ずセットで見直します。

まとめ

mcp-publisher による公開は、①npmへのサーバー公開 ②CLI自体のインストール ③server.json の作成とGitHub認証を使った公開、という3段階の作業です。それぞれは独立した作業なので、途中で失敗しても該当ステップからやり直せます。つまずきの大半は mcpName とサーバー名の名前空間の不一致に集約されるため、GitHub認証を選ぶなら io.github.ユーザー名/ の形式を最初から徹底しておくと、公開直前のエラーで手戻りする回数を減らせます。

この記事を共有:XはてブLinkedIn

関連する記事

MCP をもっと見る →