vercel-deployment-mcp

vercel-deployment-mcp

stdio 経由で Vercel のプロジェクトとデプロイを監視するための、リファレンス Model Context Protocol サーバーです。

これはデプロイワークフローのパターンに焦点を当てた、コミュニティによるリファレンス実装です。Vercel 独自の MCP の代替ではありません。小規模で読みやすいコードベースを通して、デプロイに特化した MCP サーバーが設定を適切に処理し、短期間しか稼働しないインフラストラクチャ上で予測可能に動作する方法を示すことを目的としています。

ツール

ツール	説明
list_projects	設定されたアカウント／チームから参照できるプロジェクトを一覧表示します（検索、件数制限）
get_project	ID または名前でプロジェクトを 1 件取得します
list_deployments	最近のデプロイを一覧表示します（プロジェクト、状態、件数で絞り込み）
get_deployment	現在の状態を含め、ID または URL でデプロイを 1 件取得します

list_projects と list_deployments は、それぞれ最大 limit 件（デフォルトは 20 件、最大 100 件）の結果を 1 ページ分だけ返します。カーソルによるページネーションには対応していません。より具体的な結果を表示するには、search、projectId、または state でリクエストを絞り込んでください。

インストール

npm からインストールする場合：

npm install @addiplus/vercel-deployment-mcp

インストールせずに直接実行する場合：

npx @addiplus/vercel-deployment-mcp

ソースからインストールする場合：

git clone https://github.com/addiplus/vercel-deployment-mcp.git
cd vercel-deployment-mcp
npm install
npm run build
npm test

テストスイートの実行には、サーバーの実行に必要なものより新しい Node が必要です。vitest 4.1.10 が宣言する engines.node は ^20.0.0 || ^22.0.0 || >=24.0.0 であり、この lockfile が固定する vite 8.1.3 により、これは ^20.19.0 || >=22.12.0 に絞られます。テストスイートは、両方の条件が重なる ^20.19.0 || ^22.12.0 || >=24.0.0 で実行できます。つまり、20 系では 20.19.0 以降、22 系では 22.12.0 以降、そして 24 以降です。vitest が 23 をサポート対象としていないため、23 系はこの範囲に含まれません。CI では 22 と 24 を使用します。公開パッケージ自体は、engines に記載のとおり、引き続き Node >=18 で実行できます。

設定

変数	必須	目的
VERCEL_TOKEN	はい	Vercel アクセストークン（アカウント設定で作成）
VERCEL_TEAM_ID	いいえ	リクエストをチームに限定します
VERCEL_MCP_MIN_INTERVAL_MS	いいえ	Vercel API リクエストの開始から次のリクエストの開始までに空ける最小ミリ秒数（デフォルトは 250）
VERCEL_MCP_MAX_CONCURRENT	いいえ	同時に実行中にできる Vercel API リクエストの最大数（デフォルトは 4）

HTTP 429 が返され、数値の Retry-After ヘッダーが 10 秒以下の場合、サーバーはその時間だけ待ってリクエストを 1 回再試行します。それ以外の 429 は、最初の試行でエラーとして返されます。

制限

制限	値
search の最大長	4096 文字
projectId、state、idOrName、idOrUrl の最大長	512 文字
受け付けるプロトコルフレームの最大サイズ	10485760 バイト
VERCEL_MCP_MIN_INTERVAL_MS の最大値	60000

フレームの制限で数えるのはメッセージであり、メッセージを区切る改行は含みません。そのため、ちょうど 10485760 バイトのメッセージは受け付けられます。改行より前のすべてがメッセージであり、その直前にある復帰も含まれます。

これらの制限を超えた場合の動作は、それぞれ異なります。引数が長すぎると入力検証に失敗し、呼び出しは JSON-RPC の -32602 invalid-params 結果を返します。Vercel API へのリクエストは行われず、その件について stderr への出力もありません。フレームが上限を超えると破棄され、その旨を示す行が stderr に出力されますが、接続の処理は続行されます。間隔が上限を超えても拒否されず、上限まで短縮されます。サーバーは短縮後の値で動作し、Vercel API への最初のリクエスト時に、その旨を示す行が stderr に出力されます。同じ stderr の報告が連続して繰り返される場合、出力は最大 2 回です。2 回目の出力では、以降の同一の報告が抑制されることが通知されます。

initialize と ping はいつでも応答されます。tools/list と tools/call が応答されるのは、クライアントが初期化ハンドシェイクを完了した後だけです。ハンドシェイクには、サーバーが応答できる initialize リクエストと、それに続く notifications/initialized が必要です。両方が必須のため、通知だけでは完了せず、サーバーが拒否した initialize も完了にはなりません。クライアントが両方と最初の呼び出しを一度の書き込みで送信した場合も、初期化応答を待たなかったことを理由に拒否されず、処理されます。ハンドシェイクの前にこれら 2 つのメソッドを呼び出すと、JSON-RPC エラー -32600 で拒否され、Vercel API へのリクエストは行われません。

クライアント設定の例（Claude Desktop / Claude Code）：

{
  "mcpServers": {
    "vercel-deployment": {
      "command": "npx",
      "args": ["-y", "@addiplus/vercel-deployment-mcp"],
      "env": { "VERCEL_TOKEN": "…" }
    }
  }
}

ソースコードをチェックアウトして実行する場合は、代わりに "command": "node" と "args": ["/path/to/vercel-deployment-mcp/dist/index.js"] を使用してください。

設計原則

2026-07-10 に初版を作成し、それ以降はコードに合わせて更新しています。クレーム 1 は、エラーテキストが一度サニタイズされ、クライアントから見えるようになった時点で、改めて記述しました。以下の各クレームはコードに実装されており、テスト可能なものはテストスイート（test/）で検証されています。設計上の特性には、それを実装するコードを記載しています。

1. 設定値がエラーに表示されることはありません。 アクセストークンは環境変数からのみ読み取られます。エラーテキストは整形され、サイズが制限されたうえで、クライアントから見えるテキストになる時点で一度、秘匿情報の除去処理を通ります。そのため、上流 API のメッセージからトークンやチーム ID が漏れることはありません（src/vercel.ts）。このサイズ制限の後に付加される固定のヒントは、このサーバーが書き込むテキストであり、置換対象となる値は含まれません。成功時の結果は上流の本文から固定の形式で投影され、秘匿情報の除去処理は行われません。そのため、Vercel API 自身がデプロイメント URL 内で返すチーム識別子は、そこに引き続き表示されます。
2. stdout はプロトコル専用です。 診断情報はすべて stderr に出力されます（src/index.ts）。そのため、ログ行がツールの応答に漏れることはありません。
3. 最小限のフットプリント。 ツールはプロジェクトとデプロイメントを読み取り専用で確認します。サーバーは、それらの読み取りに必要な範囲を超えるリクエストを行いません。
4. ステートレスな設計。 各ツール呼び出しで環境変数から設定を再読み込みするため（test/tools.test.ts で検証済み）、長時間稼働するホストでも短命のワーカーでも動作は同じです。モジュールレベルの状態は、リクエストを調整するスロットル（src/vercel.ts）の 1 つだけです。これは Vercel API 呼び出しの間隔を空け、同時実行数を制限します。間隔と同時実行数の設定は初回使用時に一度だけ読み込まれ、認証情報やレスポンスデータは保持しません。

ロードマップ

• 明示的な帯域外承認ステップを伴うデプロイアクション（ステートレスなトランスポートにおける複数ラウンドのツール結果をめぐり、MCP 仕様の課題 #2919/#2920 で議論されているパターンを検討しています）。
• server.json で stdio パッケージのインストールマニフェストを記述する方法と、クライアントがそれをローカル構成ファイルに変換する方法の標準化（仕様の課題 #2963、レジストリの課題 #749）。

ライセンス

MIT