MCP 2026-07-28：ステートレスなコアと互換性の境界

概要

2026年10月25日時点の情報である。2026年7月28日に発表されたMCPリビジョン2026-07-28は、プロトコルのライフサイクルを変更する。アップグレード前に、バージョン別の変更履歴、互換性規則、拡張仕様、非推奨機能の登録情報を再確認すること。リリース告知は概要であり、通信仕様のすべてを定めるものではない。

この改訂では、initialize、notifications/initialized、およびMcp-Session-Idを含むプロトコルレベルのHTTPセッションが削除される。各リクエストは、バージョンとクライアントの機能を_metaで宣言する。サーバーはserver/discoverを実装しなければならない。クライアントは事前のディスカバリーのためにこれを呼び出しても、別のリクエストを直接送ってもよい。「ディスカバリーは任意」とはクライアント側の選択を指し、サーバー側の実装免除ではない。これらの区別はバージョニング仕様に基づく。

重要な理由

接続の確立によって、後続の操作にコンテキストが引き継がれることはなくなる。導入環境では、トランスポートの状態と、長時間実行するジョブなどのアプリケーションの状態を区別しなければならない。以前のハンドシェイクを使う既存クライアントには、互換性を確保する経路が必要である。バージョン文字列だけを変更しても、メッセージは変換されない。

リリース告知は、運用上の狙いとして、セッションアフィニティなしでリクエストを異なるサーバーインスタンスに送れることを挙げている。この利点があっても、アプリケーション自身の永続的な状態を保存する責任はなくならない。

適用方法

• ライフサイクルに関する前提を洗い出す。 暗黙の接続コンテキストを、リクエストのメタデータに置き換える。呼び出しをまたぐ状態については、明示的なアプリケーションのハンドルをツール引数として公開する。以前のクライアントに対応する場合は、別の旧方式の経路を維持する。
• 中間結果を処理する。 Multi Round-Trip Requestsが、サーバー側が独立して開始するリクエストに取って代わる。input_requiredの結果は入力を要求し、クライアントはinputResponsesを付けて元の操作を繰り返す。通常の結果はresultType: "complete"を使う。このフィールドがない以前のバージョンの応答は、完了した結果として扱う。
• HTTP連携を更新する。 メソッドを示すヘッダーと、該当する場合は名前を示すヘッダーを実装し、利用を選択した変更通知にはsubscriptions/listenを使用する。リクエストの進捗は、そのリクエストの応答ストリーム上に維持される。SSEの再開と再配信は削除されるため、復旧には新しいIDを持つ新しいリクエストが必要となる。その際、副作用の重複を防ぐ保護策をアプリケーションレベルで設ける。
• キャッシュのメタデータを実装する。 変更履歴は、指定された一覧とリソースの結果にttlMsとcacheScopeを必須としている。鮮度と共有の許可は別々に判断する。どちらも、すべての応答を公開キャッシュに保存できることを意味しない。
• 拡張機能を明示的に宣言する。 拡張機能はケイパビリティマップで対応状況を示し、デフォルトでは無効で、開発者による明示的な有効化が必要である。Tasksは実験的なコア機能から公式の拡張機能へ移る。コアのバージョンから推測せず、双方の対応状況を確認する。
• 機能のライフサイクルを追跡する。 Active、Deprecated、Removedはそれぞれ異なる状態である。通常の非推奨期間の下限は12か月だが、ポリシーでは、承認済みのセキュリティ上の例外として最低90日を認めている。削除を予定する前に、その機能の記録を確認する。

落とし穴

ステートレスであることを、ストリーミング応答やアプリケーションの永続的な記録を禁止するものと解釈してはならない。仕様に準拠したすべてのSDKに、すべての拡張機能が同梱されると考えてはならない。拡張機能への対応は任意であり、個別に進化する。また、この改訂で旧ハンドシェイクが削除されたからといって、古いクライアントがまだ依存している互換動作を削除してよいわけではない。