AWS は、最新の Model Context Protocol (MCP) 仕様が、プロトコル レベルのセッションを削除し、リクエストが利用可能なサーバー インスタンスに到達できるようにすることで、リモート MCP サーバーの実装をどのように変更するかを概説しました。この変更により、スティッキー セッションと共有セッション ストアのプロトコル要件が削除され、状態管理やその他の責任を周囲のインフラストラクチャにオフロードしながら水平スケーリングが簡素化されます。
更新された MCP 仕様では、初期化されたハンドシェイクと初期化されたハンドシェイクおよび Mcp-Session-Id ヘッダーが削除されています。したがって、リクエストは、従来のロード バランサーの背後にある任意のサーバー インスタンスに独立してルーティングできます。この仕様では、ツール呼び出しを行う前にサーバー機能を必要とするクライアント向けに、オプションのサーバー/検出操作も導入されています。

MCP が適切に設計された Agentic AI Lens に合わせてマップをどのように変更するかを示す AWS の図。出典: AWS アーキテクチャ ブログ。
AWS 導入の場合、これにより、MCP プロトコル セッションの維持に特に使用されるインフラストラクチャを排除できます。 AWS アーキテクチャ ブログの著者である Anand Komandooru、Steven DeVries、Haleh Najafzadeh は、セッション アフィン ルーティングを従来のリクエスト ルーティングに置き換え、MCP プロトコル状態専用に使用されるセッション ストレージを排除することについて説明しています。また、このプロトコルでは永続的なセッション接続が必要なくなったため、AWS Lambda がリクエスト/レスポンス モデルに適合するデプロイ オプションとして識別されます。
プロトコルとアプリケーションの状態の区別については、コミュニティの議論でも取り上げられています。 Michael Madsen は LinkedIn で仕様について執筆し、この変更を次のように要約しました。
プロトコルはステートレスです。あなたのアプリはそうである必要はありません。
MRTR は、以前は保持されたオープン ストリームを必要としたサーバー開始のリクエストを置き換え、「input_required」応答と後続のリクエストを介した複数ステップの対話を可能にします。新しい「Mcp-Method」ヘッダーと「Mcp-Name」ヘッダーにより、ゲートウェイのルーティングと高速化が可能になり、W3C Trace Context は分散トレースをサポートします。 ttlMs とcacheScope はキャッシュ制御を提供します。
AWS は、監視、追跡、セキュリティ、ツールの統合をカバーする、よく設計されたガイドの中でこれらの変更をエージェント AI にマッピングしています。フローの再開も削除されたため、クライアントは中止された操作を再試行しなければならない可能性があり、副作用を引き起こすツール呼び出しに対する冪等性の重要性が増しています。
初期の実装作業では、既存のインフラストラクチャにはまだ移行パスが必要であることがわかりました。 Apify の MCP サーバー プロジェクトは、既存のセッション サーバーと並行してステートレス サポートを実装し、両方のプロトコル バージョンをカバーするルーティングとコンプライアンスのテストを行います。
したがって、移行は以前の MCP クライアントをサポートする展開に引き続き関連します。 AWS では、ゲートウェイでプロトコルのバージョンを追跡し、古いトラフィックが削除されるまでセッション インフラストラクチャを保存することをお勧めします。 MCP プロジェクトは、非推奨の機能に対して定義された移行期間を提供する機能ライフサイクル ポリシーも確立しました。