Model Context Protocol（MCP）は、2026-07-28版で、その中核、インタラクションモデル、関連SDKパッケージの全面的な書き直しを経て、完全にステートレスなプロトコルになりました。Cloudflareによると、この変更により、プロトコルのセッションを維持する専用インフラストラクチャなしで、通常のWorker内でMCPサーバーを実行できるようになり、運用上の複雑さと追加コンポーネントによるコストを削減できます。
新しい仕様は先週、TypeScript、Python、Go、C#向けSDKパッケージの更新版とともに公開されました。Cloudflareによると、サーバーはリクエストを受け取り、ツール、プロンプト、リソースを実行し、その結果を返せるようになりました。リクエスト間でプロトコルセッションを保存する必要はありません。
必須セッションの廃止
以前のバージョンでは、initializeとinitializedの交換によってセッションを作成し、Mcp-Session-Idヘッダーで識別子を割り当てることができました。その後の各リクエストは、このセッションに関連付けられた状態にアクセスする必要があり、自動スケーリングに依存する環境に課題をもたらしたほか、デプロイ時にアクティブなセッションをドレインまたは移行する必要がありました。アクティブなサーバーのインスタンスを失うと、クライアントの再接続やセッションの停止につながる可能性もありました。
新バージョンでは、必須のハンドシェイク、Mcp-Session-Idヘッダー、リクエストの基本経路におけるセッションが削除されました。各リクエストには、必要なプロトコルバージョン、クライアントの識別情報、クライアントの機能が含まれます。別のリクエストを実行する前にサーバーを確認するためのserver/discover呼び出しも任意になりました。
これは、ステートフルなアプリケーションが不要になったという意味ではありません。Cloudflareは、アプリケーション自体が協調的な状態を必要とする場合、Durable Objectsが引き続き適していると説明しています。ただし、MCPで通信するためにDurable Objectsは必要なくなり、リクエストに関連する処理が必要なサーバーはWorkers上でスケールできます。
オープンなストリーミングに代わる複数ラウンドのインタラクション
このリリースでは、リクエストを完了する前にサーバーが追加情報を必要とする状況を指すelicitationの仕組みが再設計されました。たとえば、本番環境へのリリースの承認や、返金の確認などです。従来、サーバーが開始するリクエストはオープンなストリーミングに依存していました。
Multi Round-Trip Requestsの仕組みにより、サーバーは必要なデータを示すinput_requiredという名前の結果を返せます。クライアントは回答を収集し、そのデータを使って操作を再試行します。どちらの側も、2つのリクエスト間でトランスポートセッションを保持する必要はありません。Cloudflareは、この変更について、従来の方式との互換性を破るものの、運用面ではより単純だと説明しています。
MCPリクエストをHTTPインフラストラクチャから理解可能に
新仕様では、Streamable HTTPリクエストにMcp-MethodとMcp-Nameの2つのヘッダーを必須としています。これにより、ゲートウェイ、レートリミッター、Webアプリケーションファイアウォールは、JSON-RPCの内容全体を解析せずに、リクエストがツールを呼び出しているのか、リソースを読み取っているのかを把握できます。
また、この仕様ではtools/list、prompts/list、resources/list、resources/readの結果にttlMsとcacheScopeのヒントが追加され、ツールインデックスの決定的な並び順も導入されました。これにより、再接続時にそれらを再利用し、プロンプトキャッシュの安定性を維持できます。
認可と機能ライフサイクルの変更
新仕様では、クライアントとサーバーの間に既存の関係がある場合、事前登録済みのクライアントを優先します。そのうえで、動的登録にはクライアントメタデータドキュメントCIMDを使用し、Dynamic Client Registration（DCR）はフォールバックの選択肢になります。新しいアプリケーションではDCRは非推奨となり、2027年夏以降に削除される予定です。
この仕様は、発行者の識別にRFC 9207の仕組みも採用しています。また、認可およびトークンリクエストでは、RFC 8707に従い、サーバーのベースURLをリソースとして使用することを要求します。Cloudflareによると、Workers OAuth Providerは、Workers上のMCPサーバーに対してこれらの要件を実装しています。
仕様には正式なライフサイクルが設けられ、機能をアクティブ、非推奨、削除済みに分類します。非推奨の機能は、削除される前に少なくとも12か月間利用可能でなければなりません。このリリースで非推奨と発表された機能には、Roots、Sampling、Logging、DCR、旧HTTP+SSE方式が含まれます。一方、MCP AppsとEnterprise-Managed Authorizationは拡張機能となり、Tasksは長時間かつ信頼性の高い処理への道筋を提供するため、拡張機能の枠組みに移行されました。
移行パスと提供状況
createMcpHandlerインターフェースは実験的な状態を終え、公式のMCP TypeScript SDKパッケージに移行します。Cloudflareは引き続き、Agents SDK内でWorkers向けのインターフェースを提供します。また同社は、Bun、Deno、Cloudflare Workersとの互換性を向上させるため、TypeScript SDKをNode.jsからWeb Standardsへ移行する作業を支援しました。
クライアントは、以前の仕様との互換性を維持しながら移行できます。/mcpエンドポイントは、新しいプロトコルと、2025年版を使用するStreamable HTTPクライアントからのステートレスリクエストを受け付けるため、多くのクライアントは設定を変更せずに再接続できます。一方、古いセッション、サーバーからクライアントへのリクエスト、独立したストリームに依存するサーバーには、より慎重な移行パスが必要です。たとえば、アクティブなセッションがドレインされるまで、ステートレスな経路を旧経路と並行して稼働させる方法があります。
Cloudflareによると、新仕様は同社のプラットフォーム上でクライアントとサーバーに利用可能であり、ステートレスなMCPサーバーをWorker上で実行し、Workers OAuth Providerで保護できます。同社によれば、Cloudflare API向けのCode Mode MCP Serverサービスはこの方式を採用し、毎秒数千件のリクエストと数十億回のツール呼び出しに到達しました。