MCP 2026-07-28 Specification: transport going stateless

目次 変更点 ハンドシェイクまたはセッションなし マルチラウンドトリップリクエスト (MRTR) ヘッダーベースのルーティング リスト結果はキャッシュ可能 認証 タスク 非推奨事項 SDK エコシステムサポート はじめに 感謝 前回の11月リリース以降、MCPは驚異的なペースで成長を続けています。当社のティア1 SDK全体で、月間約5億ダウンロードを記録しており、TypeScriptとPythonのSDKはどちらも累計ダウンロード数10億件のしきい値を超えました。わずか数ヶ月で、このプロトコルはエージェント型ワークフローのデータおよびインタラクティビティ基盤として成長を続けました。 本日、MCP仕様の次期バージョンである2026-07-28を、クライアントとサーバーをすぐに構築できるSDKとともに正式にリリースします。 このリリースのハイライトは、ステートレスなプロトコルコアです。MCPは双方向ステートフルプロトコルから、リクエスト/レスポンス型のステートレスプロトコルへと変革します。これは、MCPサーバーの信頼性とスケーラビリティを向上させたい開発者から最も要望の多かった機能の1つでした。ステートレスプロトコルコアの短いデモをご覧ください。 もちろん、このバージョンで導入される機能はこれだけではありません。 すべてのリクエストは自己記述的であり、クライアントが事前に機能を知りたい場合はオプションのディスカバリーコールが可能なので、プレーンなラウンドロビンのロードバランサーの後ろにあるどのインスタンスにも任意のリクエストを着地させることができます。 メソッド名とツール名はMcp-MethodおよびMcp-Name HTTPヘッダーで送信されるため、ゲートウェイはヘッダーで直接ルーティングおよび認証できます。 サンプリングやエライシテーションなどのサーバーからクライアントへのリクエストは、常に開いた双方向ストリームの必要性を排除するマルチラウンドトリップリクエスト (MRTR) を使用するように再設計されています。 リストのレスポンスにはキャッシュヒントと決定論的な順序が含まれるため、クライアントはツールカタログをキャッシュし、再接続時でもアップストリームのプロンプトキャッシュを安定させることができます。 タスクがMCPアプリやエンタープライズ管理認証 (EMA) などの他の拡張機能に加わる、正式な拡張機能フレームワークに固定します。 RFC 9207発行者検証や、ダイナミッククライアント登録 (DCR) からクライアントメタデータドキュメント (CIMD) への正式な移行を含む、一連の認証強化変更。 12ヶ月以上の最小ウィンドウを持つ正式な非推奨ポリシーにより、対応ではなくアップグレードを計画できます。 TypeScript、Python、Go、C# SDKはこれに合わせて更新され、破壊的な変更に関する詳細な移行ノートが提供されています。新しい仕様ですぐに開始できます。 変更点 ハンドシェイクまたはセッションなし 新しい仕様バージョンでは、initialize/initialized交換とMcp-Session-Idヘッダーを正式に廃止しました (SEP-2575、SEP-2567を参照)。各リクエストは、プロトコルバージョン、クライアントID、およびクライアントの機能を_metaに含めて、個別に送信されます。クライアントが何もする前にサーバーの機能を知りたい場合は、新しいserver/discoverリモートプロシージャコール (RPC) がありますが、必須ではありません。どのサーバーインスタンスにも、共有ストレージを必要とせずに、プレーンなラウンドロビンのロードバランサーの後ろから任意のリクエストを着地させることができます。 POST /mcp HTTP/1.1 Mcp-Protocol-Version: 2026-07-28 Mcp-Method: tools/call Mcp-Name: search {"jsonrpc":"2.0","id":1,"method":"tools/call", "params":{"name":"search","arguments":{"q":"otters"}, "_meta":{"io.modelcontextprotocol/clientInfo":{"name":"my-app","version":"1.0"}}}} プロトコルレベルのセッションをドロップしても、アプリケーションがステートレスである必要はありません。サーバーが呼び出し間で状態を保持する必要がある場合は、ツールから明示的なハンドルを生成し、モデルに引数として返させます。これは、トランスポートに隠されたセッション状態よりも優れていることがわかりました。モデルはハンドルを見て、ツール間でスレッド化できます。 マルチラウンドトリップリクエスト (MRTR) MRTRは、以前は開いたままのストリームを必要としたserver-initiated elicitation/create、sampling/createMessage、およびroots/listリクエストを置き換えます。 ツールが呼び出しの途中でユーザーからの確認や不足しているパラメータなどを必要とする場合があります。MRTR (SEP-2322) は、ステートレスプロトコル上でこのシナリオを可能にします。サーバーはresultType: "input_required" と、回答が必要なリクエストを返します。クライアントは、inputResponsesに含まれる回答を付けて元の呼び出しを再試行します。 ヘッダーベースのルーティング ストリーム可能なHTTPリクエストには、Mcp-MethodとMcp-Name (SEP-2243) を含める必要があります。ゲートウェイ、レートリミッター、またはWAFは、JSONボディを解析する代わりに、これらのヘッダーでルーティングおよびメータリングできます。 リスト結果はキャッシュ可能 tools/list、prompts/list、resources/list、およびresources/readからのレスポンスには、ttlMsとcacheScope (SEP-2549) が含まれるようになりました。これにより、クライアントはレスポンスの最適なキャッシュ戦略を決定し、不要な再取得を減らすことができます。 認証 過去1年間の実装者との議論から、認証は実装者が統合に最も時間を費やす分野です。この仕様改訂で、MCPの認証とセキュリティ体制をさらに進化させました。 認証サーバーはRFC 9207に従ってissパラメータを返す必要があり、クライアントはコードを償還する前にそれを検証する必要があります (SEP-2468)。これにより、認証サーバーの混同の穴が閉じられます。 クライアントはダイナミッククライアント登録 (DCR) 中にapplication_typeを設定するため、認証サーバーはデスクトップおよびCLIアプリのlocalhostリダイレクトを拒否しなくなります (SEP-837)。CLIクライアントのOAuthフローでredirect_uriエラーが発生した理由を疑問に思ったことがあるなら、これが原因である可能性が高いです。そして、クライアントIDメタデータドキュメント (CIMD) を標準として採用していますが、これはプロトコルをOAuth仕様の要件に準拠させるための強化策です。 クライアント認証情報は、発行した発行者にバインドされます。認証サーバー間での再利用はありません (SEP-2352)。 ダイナミッククライアント登録自体は、CIMDを優先して正式に非推奨になりました。DCRは後方互換性のために引き続き機能しますが、将来のMCP仕様バージョンで削除されます。 タスク タスクは実験的なコアからio.modelcontextprotocol/tasks拡張機能に移行し、ポーリングベースのtasks/getと新しいtasks/update (SEP-2663) が提供されます。変更通知は、古いHTTP GETエンドポイントから、クライアントが通知タイプごとにオプトインする単一のsubscriptions/listenストリームに移行します。 非推奨事項 Roots、Sampling、Loggingは非推奨です (SEP-2577)。これらは引き続き機能し、少なくとも12ヶ月間は機能します。新しい実装ではこれらを採用すべきではありません。レガシーHTTP+SSEトランスポートも正式に非推奨と見なされ、1年間のオフランプがあります。 SDK すべての4つのティア1 SDKは、本日現在2026-07-28に対応しています。 TypeScript Python Go C# ティア1セットを超えて、Rust SDKはベータ版で新しい仕様をサポートしています。 SDKは、新しい仕様バージョンでサーバーとクライアントの両方を構築できるAPIを実装しています。SDKベータ版のブログ投稿で述べたように、特にセッション識別子に依存していた開発者にとっては、移行コストがいくつかありますが、早期のテストフィードバックを組み込んだため、このプロセスははるかに容易になりました。 エコシステムサポート 大規模なリリースと同様に、MCPで行っている作業は、エコシステム全体からの貢献なしには不可能でした。また、一般提供される前に仕様をテストおよび検証するのを支援してくれた多くの貢献者やパートナーに特に感謝しています。 この新しいリリースは、1年以上前にリモートMCPが最初にローンチされて以来、MCPにとって最も重要なものです。これは、スケーラブルなMCPサーバーを提供する上での飛躍であり、過去18ヶ月間に学んだすべての教訓を活かして、MCPの将来のための堅牢な基盤を提供します。新たに追加された拡張機能は、より広範なオープンソースプロジェクトの継続的なイノベーションを示しています。MCPの新しい機能で人々が何をするのかを見るのが楽しみです。 David Soria Parra Member of Technical Staff, Co-Inventor of MCP このリリースは、MCPが現実のプロダクショングレードのインフラストラクチャになりつつあることを示す最も明確な信号です。最大の変更は破壊的なものですが、コミュニティはギャップを埋めるのではなく、困難な作業を選択しました。これは、私たちがエンタープライズ全体で目にしていることと一致しています。MCPはすでに、これらのチームのデフォルトになっています。