Model Context Protocol (MCP) はセッション状態を廃止し、代わりにレシート形式のリクエストと新しい server/discover コマンドを採用しました。これにより、開発者は AWS Lambda のようなサーバーレスプラットフォーム上で MCP を実行できるようになり、長らく信頼性を損なってきた「シングルウェイター（一人のウェイター）」のボトルネックを回避できます。
旧モデルが重要だった理由
元々、MCP は特定のサーバーへの永続的な接続を必要としていました。サーバーはユーザーの「テーブル番号」——コンテキスト、ルール、保留中のアクションを保存する隠れたセッション——を保持していました。そのサーバーがクラッシュすると、セッションは消失し、クライアントは最初からやり直さなければなりませんでした。
アップデートによる変更点
- セッションの廃止 – 各リクエストには、どのレジ係でも読めるレストランのレシートのように、サーバーが必要とするすべての情報が含まれています。「initialize」ハンドシェイクはなくなりました。
- レシートモデル – すべてのリクエストの冒頭にある小さなメタブロックに、バージョン情報と必要なパラメータが含まれます。サーバーはリクエストを単独で処理し、
resultType、ttlMs（ミリ秒単位の生存期間）、cacheScopeを含む結果を返します。これらのフィールドにより、クライアントは回答を安全にキャッシュし、いつ期限が切れるかを知ることができます。 - Server/discover – 新しいコマンドにより、クライアントはサーバーに対して現在の機能（capabilities）を問い合わせることができます。レスポンスは即時であり、事前のやり取りに依存しません。
- Subscriptions/listen – ブザーのように機能します。クライアントは更新をサブスクライブし、何かが変更されたときにのみ通知を受けるため、ポーリングによるトラフィックを削減できます。
- Input_required フロー – サーバーが追加情報を必要とする場合、クライアントに直接問い合わせるのではなく、
input_requiredレスポンスを返します。その後、クライアントは追跡リクエストで不足しているデータを提供します。
サーバーが状態を保持しなくなったため、あらゆるステートレスなコンピューティング環境で MCP エンドポイントをホストできます。オンデマンドで起動し、一時停止し、あるいはゾーン間で移行する関数でも、会話を中断することなくトラフィックを処理できます。
勝者と懸念事項
AI フロントエンドを構築する開発者 – よりシンプルで信頼性の高いバックエンドを手にできます。
インフラストラクチャチーム – 安価でオートスケーリング可能なサービス上で MCP をプロビジョニングできます。
MCP サーバーのメンテナー – ttlMs や cacheScope を出力し、server/discover の規約を遵守するようにハンドラーを書き直す必要があります。永続的なセッションに依存していたコードはリファクタリングが必要です。
厳格なコンプライアンスを求める企業 – より明確なデータライフサイクル制御の恩恵を受けられます。
隠れた詳細：バージョン交渉
すべてのレシートには、クライアントが期待するプロトコルバージョンを通知する小さなメタブロックが含まれています。
まだ不透明な点
次に注目すべき点
まとめ
セッション状態を削ぎ落とし、すべてのやり取りを自己完結型のレシートに変えることで、MCP はサーバーレスのエコシステムに自然に適合するようになりました。この転換により、MCP はより安定し、スケーラブルになり、サーバーをどこでも実行し、通常の Web サービスと同様にスケールさせることが可能になります。