3行まとめ
このテーマをもう少し広げて見るなら、MCP ElicitationをAIエージェントに入れる前に：form・URL・OAuth・人間承認の分け方 と TypeScriptでGitHub read-only MCPサーバーを作る：Fine-grained PATとtool allowlistの最小構成 も合わせて確認してください。MCP仕様差分を見る時に、ElicitationやOAuthを実装判断へ落とす視点を補えます。
Protocol Revision、Authorization、Transport、Tools、Lifecycleの差分を確認します。
npm package version、import path、依存関係、runtime対応を仕様とは別に確認します。
stdio、HTTP、AIエージェント接続など、自社で使っている経路ごとに影響を分けます。
initialize、tools/list、tools/call、認可失敗、rollbackまでを更新前後で比較します。
MCPの更新を1つの作業として扱わず、影響が出る層を分けて確認するのが出発点です。
- MCP仕様やSDKを更新するときは、Protocol Revision、npmパッケージのバージョン、利用中のTransport、Tool定義を分けて確認します。全部を「MCPの更新」とまとめると、影響範囲を見誤ります。
- 2026年5月31日時点で、MCP公式仕様は
2025-11-25をlatestとして掲載していました。TypeScript周辺では、安定運用でよく参照される@modelcontextprotocol/sdkと、分割パッケージの@modelcontextprotocol/serverを同列に扱わないことが重要です。 - HTTPベースのMCPサーバーは認可、metadata discovery、scope、token audience、session、reverse proxyの確認が要ります。stdio中心のローカルMCPサーバーでも、stdout/stderr、環境変数、Tool schema、ログの扱いは更新時の事故点になります。
本文の事実確認には、公式ドキュメント、公式ヘルプ、関連する仕様・SDKドキュメントを使っています。実リポジトリでの性能ベンチマークや更新代行は、本文で明記した場合を除き実施していません。
この記事でわかること
Protocol Revisionとnpm package versionを同じものとして扱わない判断ができます。
stdioとHTTPで、壊れやすい場所とテスト方法を分けられます。
name、description、inputSchema、error、side effectを更新前後で比較できます。
検証ログ、canary、ロールバック条件を更新手順に入れられます。
MCPの入門ではなく、既存連携を壊さないための更新確認に焦点を当てます。
- MCP仕様更新とSDK更新を分けて読む理由
- 既存MCP構成を棚卸しする観点
- HTTPベースのTransportで認可まわりを確認する順番
- stdioとStreamable HTTPで更新時の事故点がどう違うか
- Tool定義、input schema、error、side effectをどうレビューするか
- TypeScript SDKの安定版とalpha系パッケージを混同しない見方
- 本番投入前に最低限残したい検証ログとロールバック条件
前提知識
capability、認可、Transport、Tool schemaの前提が変わる可能性があります。
import path、API、依存関係、runtime対応が変わる可能性があります。
Tool名、schema、権限、ログ、エラー形式の互換性を確認します。
対応Protocol Revision、Transport対応、承認UIの差分を確認します。
仕様が更新されても、SDKや利用中クライアントが同じ速度で追従するとは限りません。
MCPは、LLMアプリケーションと外部データ、外部ツールを接続するためのプロトコルです。公式仕様では、Host、Client、Serverの役割があり、ServerはTools、Resources、Promptsなどの機能を提供できます。通信はJSON-RPC 2.0を使います。
実務で更新影響を見るときに大事なのは、MCPを単一のライブラリ名として扱わないことです。少なくとも次の4つを分けます。
| 見るもの | 例 | 更新時に壊れやすい点 |
|---|---|---|
| Protocol Revision | 2025-11-25 | capability、認可、Transport、Tool schemaの前提 |
| SDK package | @modelcontextprotocol/sdk、@modelcontextprotocol/server | import path、API、依存関係、runtime対応 |
| MCP server実装 | 自作のGitHub連携、社内DB参照、Issue検索 | Tool名、schema、権限、ログ、エラー形式 |
| MCP client/host | AIエディタ、エージェント、社内アプリ | 対応Protocol Revision、Transport対応、承認UI |
「SDKを上げたらMCP対応が新しくなる」とは限りません。反対に、仕様が更新されても、使っているクライアントやSDKがその変更をすぐ吸収しているとも限りません。記事内ではこのズレを前提に、更新時に何を確認するかを整理します。
結果
Authorization、Transport、Toolsの変更は実装と運用の両方に影響します。
Protocol Revisionとnpm package versionは別物として確認します。
metadata discovery、scope、audience、token検証、401/403の扱いを見ます。
ローカル権限、環境変数、stdout/stderr、Tool schemaの破損を確認します。
本番導入では安定版、互換性確認、ロールバック条件を先に決めます。
最新版を入れることより、どの層にどんな影響が出るかを分けて判断することが重要です。
2026年5月31日の確認範囲では、MCP公式仕様ページは2025-11-25をlatestとして掲載していました。Key Changesでは、前回Revisionである2025-06-18からの変更として、Authorization、ToolやResourceなどのmetadata、incremental scope consent、Tool name guidance、Elicitation、Samplingでのtool calling、OAuth Client ID Metadata Documents、experimental tasksなどが挙げられていました。
TypeScript周辺では、npmメタデータ上で@modelcontextprotocol/sdkのlatestは1.29.0でした。一方、分割パッケージである@modelcontextprotocol/serverは2.0.0-alpha.2でした。つまり、既存のv1系実装を運用しているチームが、package名だけを見て分割パッケージへ移ると、alpha系を本番前提で扱ってしまう可能性があります。
今回の記事の判断は次の通りです。
| 判断 | 理由 |
|---|---|
| 仕様差分は必ず読む | Authorization、Transport、Toolsの変更は実装と運用に影響するため |
| SDK更新は別トラックで見る | Protocol Revisionとnpm package versionは別物のため |
| HTTP型MCPは認可を重点確認する | metadata discovery、scope、audience、token検証、401/403の扱いが絡むため |
| stdio型MCPも油断しない | ローカル権限、環境変数、stdout/stderr、Tool schemaの破損が起きるため |
| alpha系は検証環境から始める | 本番導入では安定版、ロールバック、互換性確認が必要なため |
まず自社MCP構成を棚卸しする
実行権限、環境変数、stdout/stderr、起動コマンド、read-only Toolから確認します。
endpoint、認可、scope、session、gateway、監査ログを確認します。
metadata discovery、token audience、reverse proxy、timeout、401/403を重点確認します。
Tool表示、承認UI、write系Toolの扱い、エージェント側ログを確認します。
関係ない変更を大きく見積もらないためにも、最初に自社のMCP構成を分類します。
仕様差分を読む前に、使っているMCP構成を棚卸しします。ここを飛ばすと、関係ない変更を大きく見積もったり、逆に重要な変更を見落としたりします。
stdio中心のローカルMCPサーバー
AIコーディングエージェントやローカルIDEから、MCPサーバーをサブプロセスとして起動する構成です。GitHub Issueを読む、ローカルファイルを検索する、ドキュメントを返す、といった用途で始めやすい構成です。
確認するのは、認可仕様よりも実行権限です。stdioでは、サーバーはローカルプロセスとして動きます。つまり、MCPサーバーの権限は、起動したユーザーの権限や渡した環境変数に強く依存します。
確認項目
- MCPメッセージ以外をstdoutへ出していないか
- ログをstderrへ逃がしているか
- APIキーやtokenを環境変数から読み、Tool結果やログに出していないか
- read-only Toolから始めているか
- write系Toolに人間承認を要求しているか
- SDK更新後も
tools/listとtools/callの結果が変わっていないか
HTTPベースのMCPサーバー
社内ネットワークや外部クライアントからアクセスするMCPサーバーでは、Transportと認可の確認が中心になります。公式仕様のAuthorizationはHTTP-based transportsを対象にしています。
HTTP型では、単にMCP endpointへ到達できるかだけでは不十分です。認可サーバーの発見、Protected Resource Metadata、scope、resource parameter、token audience、401/403の扱い、reverse proxyのheader保持、timeout、sessionの扱いまで確認します。
確認項目
- 認可が必要なendpointで、未認証時に期待した401が返るか
- Protected Resource Metadataをクライアントが取得できるか
- 認可サーバーのmetadata discoveryが成立するか
- 必要scopeが過剰になっていないか
- tokenが対象MCPサーバー向けに発行されているか
- 無効token、期限切れtoken、scope不足で401/403が分かれるか
- reverse proxyやgatewayが必要なheaderを落としていないか
AIエージェント接続の運用構成
MCPサーバーそのものが正しくても、エージェント側の承認UIやTool表示が変わると、実務上の安全性は変わります。とくにAIコーディングエージェントからwrite系Toolを呼ぶ場合は、クライアント側の承認、ログ、権限設定も確認します。
AIコーディングエージェントカテゴリでは、エージェント導入時の権限設計や運用観点を扱っています。MCP更新の影響は、MCPサーバーだけでなく、エージェント運用側にも出ると考えてください。
認可の変更影響を見る
- 1未認証リクエスト
期待した401が返り、metadata発見の入口が示されるかを確認します。
- 2Resource Metadata
クライアントがProtected Resource Metadataを取得できるかを確認します。
- 3Authorization Server Discovery
認可サーバーのmetadata discoveryが成立するかを確認します。
- 4token取得
必要scopeとresource parameterが意図した対象を指しているかを確認します。
- 5MCP request
Bearer tokenで送信し、query stringにaccess tokenを入れていないかを確認します。
- 6scope/audience検証
無効token、期限切れtoken、scope不足、audience不一致の挙動を確認します。
認可は成功ケースだけでなく、失敗時に安全に止まり、調査できることまで確認します。
MCPのAuthorization仕様では、HTTP-based transports向けにOAuth 2.1を基盤とする認可フローが説明されています。2025-11-25版では、Protected Resource Metadata、Authorization Server Metadata、OpenID Connect Discovery、Client ID Metadata Documents、Dynamic Client Registration、scope selection、resource parameter、token handlingなど、実装者が見るべき項目が多くあります。
ここでの要点は、「MCPサーバーが認証済みリクエストを受けられる」だけで完了にしないことです。どの認可サーバーを発見し、どのresource向けのtokenを受け取り、どのscopeでToolを許可するかまで確認します。
401とmetadata discovery
未認証アクセス時の401は、ただ拒否するためだけの応答ではありません。Protected Resource Metadataの場所をクライアントへ伝える入口になります。仕様では、WWW-Authenticate headerまたはwell-known URIによる発見が扱われています。
確認項目
- 未認証リクエストで401が返るか
- クライアントがresource metadata URLを取得できるか
- well-known URIのfallbackが成立するか
scopeparameterが必要な権限を過不足なく示しているか- scopeがない場合のfallback動作をクライアントが持っているか
token audienceとresource parameter
MCPサーバーは、受け取ったtokenが自分向けに発行されたものかを確認する必要があります。Authorization仕様では、Resource Indicators for OAuth 2.0に基づくresource parameterが説明されています。
ここを曖昧にすると、別サービス向けに発行されたtokenをMCPサーバーが受け入れる、あるいはMCP向けtokenが別のAPIへ流れる、といった設計ミスにつながります。記事として攻撃手順は扱いませんが、運用チェックではaudienceとresourceの確認を必須にします。
評価基準
- tokenが対象MCP server向けに発行されている
- MCP serverがaudienceを検証している
- query stringにaccess tokenを入れていない
- Authorization headerでBearer tokenを送っている
- 無効token、期限切れtoken、scope不足の挙動をテストしている
scopeの増分同意
Key Changesでは、WWW-Authenticateを使ったincremental scope consentが大きな変更点として挙げられています。これは、最初から広いscopeを要求するのではなく、必要になった操作に応じて追加scopeを求める設計につながります。
実務では、read-only Toolとwrite Toolを同じscopeにまとめない方が扱いやすくなります。最初はIssueやドキュメントの読み取りだけを許可し、PR作成、チケット更新、通知送信のような副作用のあるToolは別scopeと人間承認へ分けます。
Transport別に壊れやすい場所を見る
stdioでは起動コマンド、HTTPではendpoint pathやgateway配下のpathを確認します。
stdioではstdout汚染、HTTPでは認可失敗やgatewayログの残り方を確認します。
stdioでは環境変数、HTTPではmetadata discovery、scope、token検証を確認します。
HTTPでは接続再開、並行リクエスト、timeout、server restart時の挙動を確認します。
Transportごとにtools/list、tools/call、失敗時の挙動を更新前後で比較します。
片方のTransportで成功しても、もう片方のTransportが安全に動くとは限りません。
MCPのTransportは、接続方式ごとに事故点が違います。stdioとHTTPを同じテストで済ませないことが大切です。
stdioで見ること
stdioでは、クライアントがMCPサーバーをプロセスとして起動し、標準入出力でやり取りします。更新時に壊れやすいのは、起動コマンド、環境変数、stdoutの汚染、stderrログ、終了処理です。
確認項目
| 確認点 | 見る理由 |
|---|---|
| 起動コマンド | SDK更新でentrypointやbuild成果物が変わる可能性がある |
| stdout | MCPのJSON-RPC以外が混じるとクライアントが壊れる |
| stderr | ログ出力先として使えているかを見る |
| 環境変数 | tokenや設定値が渡りすぎていないかを見る |
| 終了処理 | クライアント終了時に子プロセスが残らないかを見る |
Streamable HTTPで見ること
HTTP型では、endpoint、認可、session、SSE、再接続、proxy、timeoutが絡みます。特に社内gatewayやreverse proxyを挟む場合、MCPサーバーだけの単体テストでは見えない不具合が出ます。
確認項目
| 確認点 | 見る理由 |
|---|---|
| endpoint path | gateway配下でpathが変わるとmetadata discoveryも影響を受ける |
| protocol version header | HTTP利用時のversion negotiationに関わる |
| session | 接続再開や並行リクエストで状態が壊れないかを見る |
| timeout | 長いTool実行で待ち続けないかを見る |
| proxy header | 認可やmetadata discoveryに必要な情報が落ちないかを見る |
旧サンプルコードをそのまま使わない
MCP周辺は、仕様、SDK、サンプル実装の更新速度が速い領域です。古いブログ記事や古いテンプレートのTransport実装が、現在の仕様と合っているとは限りません。
更新時は、サンプルコードの流用より先に、公式仕様とSDK repositoryのREADME、release notes、package versionを確認します。社内テンプレートを持っている場合は、テンプレート内に「最終確認日」「対象Protocol Revision」「対象SDK version」を書いておくと、古い前提に気づきやすくなります。
Lifecycleとcapability negotiationを見る
- initialize request
クライアントが送るProtocol Versionとclient capabilitiesを確認します。
- initialize result
サーバーが返すProtocol Version、serverInfo、capabilitiesを更新前後で比較します。
- initialized notification
初期化完了後に、合意した範囲の機能だけを使っているかを確認します。
- 通常処理
tools/list、Resources、Prompts、Sampling、Elicitationなどの見え方を確認します。
- 終了処理
shutdown、transport close、timeout、cancellationで状態が残らないかを確認します。
接続できるだけでなく、必要なcapabilityが合意されていることを確認します。
MCPのLifecycleでは、接続の最初にinitializeを行い、protocol version、client capabilities、server capabilities、implementation informationを交換します。ここが通るだけでは十分ではありません。更新後も、必要なcapabilityが交渉され、クライアントとサーバーの双方が合意した範囲だけを使っているかを確認します。
version negotiation
クライアントは対応するProtocol Versionをinitialize requestで送ります。サーバーが同じversionを返せない場合は、対応可能なversionを返すことになります。クライアントがそのversionに対応していなければ、切断する判断になります。
確認項目
- クライアントが送るProtocol Versionをログで確認できるか
- サーバーが返すProtocol Versionを更新前後で比較したか
- version不一致時に曖昧に続行していないか
- HTTP利用時に後続リクエストのversion headerを確認したか
capability negotiation
Tools、Resources、Prompts、Logging、Completions、Roots、Sampling、Elicitation、Tasksなどは、capabilityとして扱われます。更新でcapabilityの出し方や解釈が変わると、Tool一覧が見えない、サーバー側からの要求をクライアントが扱えない、といった不具合が出ます。
評価基準
- 更新前後で
tools/listの件数と主要Tool名が一致する - 必須のResourcesやPromptsが見えている
- SamplingやElicitationを使う場合、人間承認の扱いを確認している
- experimental capabilityを本番機能として扱っていない
- timeoutとcancellationの挙動を確認している
Tools定義をレビューする
短く、安定し、用途を表し、扱いにくい記号を含まないかを確認します。
モデルがToolを選ぶ手がかりとして、実際の挙動とずれていないかを確認します。
有効なJSON Schema objectで、requiredやenumの差分を更新前後で比較します。
安全境界として信頼せず、実装、scope、承認UIと合わせて確認します。
入力不正、認可不足、timeout、内部stack traceの扱いを確認します。
write系Toolでは対象、変更内容、人間承認、監査ログが残るかを確認します。
Toolが動くことと、承認なしで呼んでよいことは別の判断です。
MCPのToolsは、モデルが外部システムとやり取りする入口です。公式仕様でも、Toolはモデルが発見し呼び出せるものとして説明され、セキュリティ上は人間がTool invocationを拒否できることが重要視されています。
更新時に見るべきなのは、Toolが動くかどうかだけではありません。モデルやユーザーに見えるToolの説明、schema、出力、エラー、side effect、承認の境界が保たれているかを確認します。
Tool nameとschema
2025-11-25のKey Changesでは、Tool names guidanceが追加されたことが挙げられています。Toolsページでは、Tool nameの長さ、case-sensitive、使う文字種、空白や特殊文字を避けることなどが説明されています。
確認項目
- Tool nameが短く、安定し、用途を表しているか
- 空白や扱いにくい記号を含んでいないか
inputSchemaが有効なJSON Schema objectになっているか- パラメータなしToolでも空objectを明示しているか
- JSON Schema dialectの前提を更新後に確認したか
Tool descriptionとannotation
Tool descriptionはモデルがToolを選ぶ手がかりになります。ただし、Tool descriptionやannotationを安全境界そのものとして扱ってはいけません。公式仕様でも、trusted serverから得たものではない限り、Tool annotationsはuntrustedとして扱うべきだと説明されています。
注意点
Tool descriptionに「安全です」「read-onlyです」と書いてあっても、実装がwrite操作を持っていれば危険です。実際の権限、scope、server-side validation、承認UI、監査ログを別に確認します。
Tool resultとerror
Tool実行の失敗は、Protocol Errorとして扱うべきものと、Tool Execution Errorとしてモデルに返した方がよいものがあります。Key Changesでは、input validation errorsをTool Execution Errorsとして返すべきだという整理も挙げられていました。
評価基準
- 入力不正でサーバー全体が落ちない
- モデルが修正可能なエラーはTool resultとして分かる
- 認可不足やscope不足はHTTPの401/403や認可エラーとして扱う
- 秘密情報や内部stack traceをTool resultへ出さない
- write系Toolの結果に、実行対象、変更内容、人間承認の有無が残る
TypeScript SDK更新時の見方
latest `1.29.0`として確認。既存v1系実装の更新対象として安定度と差分を見ます。
`2.0.0-alpha.2`として確認。本番投入の既定値ではなく検証環境から扱います。
package名変更やAPI差分が既存コード、wrapper、examplesに影響しないかを確認します。
TypeScript build、Node version、ESM/CJS、Docker image、CI cacheを確認します。
lockfileとdeployを元に戻せる状態で本番判断へ進みます。
npmのpackage名やlatest表示だけで、本番投入の安全性は判断しません。
TypeScript SDKの更新では、まずpackage名と安定度を確認します。2026年5月31日のnpm確認では、@modelcontextprotocol/sdkは1.29.0、@modelcontextprotocol/serverは2.0.0-alpha.2でした。
これは、v1系で作ったMCPサーバーをすぐ分割パッケージへ移すべき、という意味ではありません。alpha系は検証対象として見るべきで、本番基盤へ入れるなら、移行計画、互換性テスト、ロールバック条件が必要です。
確認コマンド
npm view @modelcontextprotocol/sdk version time.modified --json
npm view @modelcontextprotocol/server version time.modified --json今回の確認結果は次の通りです。
{
"version": "1.29.0",
"time.modified": "2026-03-30T16:50:43.186Z"
}{
"version": "2.0.0-alpha.2",
"time.modified": "2026-04-01T16:56:46.992Z"
}SDK更新の最低限テスト
SDK更新を本番へ入れる前に、最低限この程度は確認します。
| テスト | 合格条件 |
|---|---|
| install | lockfile差分が意図したpackageに収まっている |
| build | TypeScript buildが通る |
| server起動 | stdioまたはHTTPでMCPサーバーが起動する |
| initialize | versionとcapability negotiationが通る |
| tools/list | 主要Toolが更新前と同じ名前で見える |
| tools/call | read-only Toolが成功し、write Toolは承認なしで進まない |
| error | 入力不正、認可不足、timeoutが期待通りに返る |
| rollback | lockfileとdeployを元に戻せる |
alpha系を試す条件
alpha系を試すこと自体は悪くありません。むしろ、次のmajor変更に備えるには早めの検証が役に立ちます。ただし、本番のMCPサーバーでいきなり使うのではなく、検証環境を分けます。
確認項目
- 本番tokenや社内データに接続しない
- read-only Toolだけで始める
- SDK APIの差分を移行メモに残す
- 既存クライアントとの互換性を別に確認する
- alphaで見つけた問題を本番障害として扱わない
更新時の実務手順
- 1現状を記録する
Protocol Revision、SDK version、lockfile、Transport、Tool list、認可設定を残します。
- 2仕様差分を読む
latest、Key Changes、Authorization、Lifecycle、Transports、Toolsを確認します。
- 3SDKと依存関係を上げる
MCP SDK以外の依存関係が広く動いていないかを確認します。
- 4スモークテストを通す
build、起動、initialize、tools/list、tools/call、失敗時の挙動を確認します。
- 5canaryで見る
限定クライアントや検証リポジトリで、Transport別の差分を確認します。
- 6rollbackを判定する
Tool欠落、認可失敗、timeout、ログ漏えいがあれば戻せる状態にします。
更新後に失敗してから思い出すのではなく、比較できる現在値を先に残します。
MCPの更新確認は、気づいた人がその場でpackageを上げる作業ではなく、短い運用手順として持つ方が安全です。
1. 現状を記録する
まず、更新前の状態を残します。
node -v
npm -v
npm ls @modelcontextprotocol/sdk
npm view @modelcontextprotocol/sdk version time.modified --jsonHTTP型なら、MCP endpoint、Protocol Revision、認可方式、scope、gateway、deploy先も記録します。stdio型なら、起動コマンド、環境変数、ログ出力先、接続するクライアントを書きます。
2. 仕様差分を読む
公式仕様のlatest、Key Changes、該当ページを読みます。MCPでは、Authorization、Lifecycle、Transports、Tools、Resources、Prompts、Sampling、Elicitationなど、関係するページが分かれています。
確認項目
- 自社構成に関係する変更か
- 実装変更が必要か
- 運用手順だけ変えればよいか
- クライアント側対応が必要か
- experimental要素を含むか
3. SDKと依存関係を上げる
package managerで依存関係を更新します。ここでは、MCP SDK以外の依存関係が大量に動いていないかを見ます。lockfile差分が広い場合は、MCP更新とその他の依存関係更新を分けた方がレビューしやすくなります。
4. スモークテストを通す
read-only Toolを中心に、最小テストを通します。
npm run build
npm testこの2つだけで十分とは限りません。MCPサーバー固有の起動テスト、Tool list、Tool call、認可失敗時の確認、timeout確認も加えます。
5. canaryとロールバック条件を決める
HTTP型のMCPサーバーでは、いきなり全利用者に出すのではなく、canaryや限定クライアントで確認します。stdio型でも、チーム全員の設定を一斉に変える前に、1つの検証リポジトリで通します。
ロールバック条件
- Tool listが更新前より欠ける
- 認可失敗が増える
- scope不足が誤ってwrite Toolを止める、または通してしまう
- timeoutや再接続で処理が残る
- クライアント側でTool表示や承認UIが崩れる
- ログにtokenや秘密情報が出る
失敗点とハマりどころ
仕様、SDK、クライアント対応状況を分けて確認します。
ローカル権限、環境変数、ファイルアクセス、コマンド実行の影響を確認します。
説明文ではなく、実装、scope、承認UI、監査ログで安全性を担保します。
package名、dist-tag、release note、移行状況を確認します。
未認証、期限切れtoken、scope不足、audience不一致、metadata取得失敗も確認します。
成功パスだけの確認では、実運用で起きる失敗の多くを見落とします。
Protocol RevisionとSDK versionを混同する
「MCP 2025-11-25対応」と「@modelcontextprotocol/sdk@1.29.0を使っている」は同じ意味ではありません。仕様が何を定義しているか、SDKがどこまで実装しているか、クライアントが何に対応しているかを分けて確認します。
stdioだから安全だと思い込む
stdioは外部公開しないため始めやすい一方、ローカル権限で動きます。リポジトリ全体を読める、環境変数を読める、ローカルコマンドを実行できるToolを作れる、という点では十分に危険です。
Tool descriptionを権限設計の代わりにする
Tool descriptionはモデルにとって重要ですが、安全装置ではありません。実装、認可、scope、承認UI、監査ログが必要です。特にwrite系Toolは、read-only Toolと同じ扱いにしないでください。
alpha packageをlatestとして本番投入する
npmのlatest表示だけを見ると、alpha系でも目立つことがあります。package名、dist-tag、release note、README、移行状況を確認し、安定版と検証版を分けます。
認可の成功例だけ確認する
OAuthやOIDC連携は、成功ケースだけだと実務事故を見逃します。未認証、期限切れtoken、scope不足、audience不一致、metadata取得失敗、gateway header欠落を確認します。
実務で使うなら
Protocol Revision、SDK package、lockfile commitを記録します。
Transport、gateway有無、OAuth/OIDC、scope設計を記録します。
read-only、write、外部API、課金影響のあるToolを分けます。
Tool呼び出し前の承認、人間レビュー、Tool call、認可失敗、timeoutを記録します。
package pinning、deploy rollback、設定戻しの手順を残します。
AIエージェントから使うMCPサーバーは、read-only開始を標準にすると事故点を減らせます。
小規模チームでMCPを運用するなら、最初から大きな更新管理基盤を作る必要はありません。まず、次の1枚チェックリストをリポジトリに置くのが現実的です。
| 項目 | 記録する内容 |
|---|---|
| Protocol Revision | 例: 2025-11-25 |
| SDK package | package名、version、lockfile commit |
| Transport | stdio、HTTP、gateway有無 |
| 認可 | なし、環境変数、OAuth/OIDC、scope設計 |
| Tool一覧 | read-only、write、外部API、課金影響 |
| 承認 | Tool呼び出し前、人間レビュー、CI gate |
| ログ | Tool call、認可失敗、timeout、未検証項目 |
| rollback | package pinning、deploy rollback、設定戻し |
AIエージェントから使うMCPサーバーでは、read-only開始を標準にしてください。Issue検索、ドキュメント参照、設定一覧の読み取りから始め、PR作成、Issue更新、通知送信、本番系API呼び出しは別scopeと承認に分けます。
ツール選定やエージェント運用まで含めて比較したい場合は、比較表を合わせて見ると、MCP単体ではなくAI開発ワークフロー全体の判断に戻せます。
セキュリティ・コスト注意
Tool result、ログ、query stringへtokenや秘密情報を出さないようにします。
HTTP型ではaudienceとresourceを検証し、read-onlyとwriteをscopeで分けます。
Sampling、Elicitation、write系Toolでは承認と監査ログを前提にします。
リトライ、長いResource、検索API多用で費用が増えないかを確認します。
自律的なTool利用では、失敗時の再試行上限とtimeoutを決めます。
セキュリティとコストは、機能確認とは別の合格条件として扱います。
MCPサーバーは、LLMやAIエージェントから外部システムへ到達する入口になります。便利さの分だけ、権限、ログ、token、課金の事故点が増えます。
セキュリティ
- 秘密情報をTool resultへ出さない
- tokenをquery stringへ入れない
- HTTP型ではaudienceとresourceを検証する
- read-only Toolとwrite Toolをscopeで分ける
- Tool annotationsを安全境界として信頼しない
- SamplingやElicitationは人間承認を前提にする
- 監査ログに、誰が、どのToolを、どのscopeで、いつ呼んだかを残す
コスト
MCP自体に料金がなくても、接続先API、LLM API、ホスティング、ログ保存、IdP、監査基盤には費用が出ます。Toolがリトライを繰り返す、長いResourceを毎回渡す、検索APIを大量に呼ぶ、といった形で費用が増えることもあります。
更新時は、機能だけでなく呼び出し回数とpayload量も見ます。特にAIエージェントが自律的にToolを使う構成では、失敗時の再試行上限とtimeoutを決めておくべきです。
導入しない方がよいケース
どのMCPクライアントが使っているか把握できていない状態です。
read-only Toolとwrite Toolの区別がなく、人間承認もありません。
401/403、scope不足、metadata取得失敗をログで確認できません。
ロールバック手順、package pinning、設定戻しが決まっていません。
検証版と本番更新を同じ扱いにしています。
先に棚卸し、権限整理、ログ整備を行ってから更新判断へ進みます。
次の条件では、MCP更新を本番へ入れる前に止めた方がよいです。
- どのMCPクライアントが使っているか把握できていない
- read-only Toolとwrite Toolの区別がない
- 認可失敗時のログを見られない
- ロールバック手順がない
- SDKのalpha/stableを区別していない
- Tool resultに秘密情報が混じる可能性を確認していない
- 人間承認なしで外部APIや本番系操作を実行できる
この状態で更新すると、仕様差分そのものより、運用の見えなさが障害になります。先に棚卸し、権限整理、ログ整備を行ってください。
FAQ
十分ではありません。SDK、クライアント、サーバー実装、認可基盤も別に確認します。
HTTP向け仕様をそのまま適用しませんが、環境変数、権限、ログ、Tool副作用を確認します。
alpha系は安定版と同じ扱いにせず、検証環境でAPI差分と戻し方を確認します。
足りません。server-side validation、scope、承認UI、監査ログが必要です。
version、lockfile、build、起動、Tool list比較は自動化しやすく、権限判断は人間レビューが必要です。
自動化できる確認と、人間が判断すべき確認を分けると運用しやすくなります。
MCP仕様のlatestだけ見れば十分ですか？
十分ではありません。仕様、SDK、クライアント、サーバー実装、認可基盤の更新速度は揃いません。公式仕様で方向性を確認し、SDK releaseとnpm package、利用中クライアントの対応状況を別に見ます。
stdioだけならAuthorization仕様は関係ありませんか？
HTTP-based transport向けのAuthorization仕様をそのままstdioへ適用する必要はありません。ただし、stdioでは環境変数やローカル権限が重要になります。認可仕様を読まない代わりに、プロセス権限、秘密情報、ログ、Toolの副作用を確認してください。
@modelcontextprotocol/serverを使うべきですか？
2026年5月31日の確認では、npm上の@modelcontextprotocol/serverは2.0.0-alpha.2でした。本番導入では、alpha系を安定版と同じ扱いにしない方が安全です。検証環境でAPI差分を確認し、既存の@modelcontextprotocol/sdk v1系実装から移る理由と戻し方を決めてから判断します。
Toolの安全性はdescriptionに書けば足りますか？
足りません。descriptionはモデルのTool選択を助けますが、権限を強制しません。server-side validation、scope、承認UI、監査ログ、失敗時の停止条件を別に用意します。
更新確認を自動化できますか？
一部はできます。npm package version、lockfile差分、build、unit test、MCP server起動、Tool listのsnapshot比較は自動化しやすいです。一方、scope設計、人間承認UI、Tool descriptionの妥当性、社内運用影響は人間レビューが必要です。
次に読むなら
次に読むなら
参照した主な情報源
- https://modelcontextprotocol.io/specification/2025-11-25
- https://modelcontextprotocol.io/specification/2025-11-25/changelog
- https://modelcontextprotocol.io/specification/2025-11-25/basic/authorization
- https://modelcontextprotocol.io/specification/2025-11-25/basic/lifecycle
- https://modelcontextprotocol.io/specification/2025-11-25/basic/transports
- https://modelcontextprotocol.io/specification/2025-11-25/server/tools
- https://github.com/modelcontextprotocol/typescript-sdk
- https://github.com/modelcontextprotocol/typescript-sdk/releases
更新履歴
- 2026年5月31日
MCP仕様`2025-11-25`、TypeScript SDK GitHub、npmメタデータを確認し、ドラフトを作成しました。
MCP仕様とSDKは更新されるため、確認日を判断材料として扱います。
| 日付 | 内容 |
|---|---|
| 2026年5月31日 | MCP仕様2025-11-25、TypeScript SDK GitHub、npmメタデータを確認し、ドラフトを作成しました。 |