powered by TechFeed
表示モード
主要ニュース

MCP C# SDK 2.0がHTTPをステートレス化 — スティッキーセッション不要でスケールしやすくなり、ツール処理中の追加入力もサポート

10月26日、Edin Kapićが「MCP C# SDK 2.0 Makes HTTP Stateless by Default and Adds Multi Round-Trip Requests」と題した記事を公開した。MCP C# SDK 2.0の最大の変更は、HTTPをデフォルトでステートレス化したことだ。スティッキーセッションや共有セッションストアが不要になり、任意のサーバーインスタンスでリクエストを処理できる。ステートレス化で失われた「処理途中にクライアントへ入力を求める」機能は、新設のMulti Round-Trip Requests(MRTR)が代替する。スケーラビリティと対話性を両立させた設計変更で、SDKチームはこのベースとなる2026-07-28リビジョンを「プロトコル公開以来最大の仕様変更」と位置づけている。

10月26日、Edin Kapićが「MCP C# SDK 2.0 Makes HTTP Stateless by Default and Adds Multi Round-Trip Requests」と題した記事を公開した。MCP C# SDK 2.0の最大の変更は、HTTPをデフォルトでステートレス化したことだ。スティッキーセッションや共有セッションストアが不要になり、任意のサーバーインスタンスでリクエストを処理できる。ステートレス化で失われた「処理途中にクライアントへ入力を求める」機能は、新設のMulti Round-Trip Requests(MRTR)が代替する。スケーラビリティと対話性を両立させた設計変更で、SDKチームはこのベースとなる2026-07-28リビジョンを「プロトコル公開以来最大の仕様変更」と位置づけている。


MCP(Model Context Protocol)は、アプリケーションがLLMにコンテキストやツールを提供する方法を標準化するオープンプロトコルだ。2024年末にAnthropicが公開し、MicrosoftやGoogleなど主要各社が対応を進めている。C# SDKはMicrosoftと共同でメンテナンスされており、ASP.NET Core上に構築されている。

MicrosoftはこのSDKのバージョン2.0を正式リリースした。MCPの2026-07-28リビジョンを実装したもので、SDKチームはこのリビジョンを「プロトコル公開以来最大の仕様変更」と位置づけている。

HTTPのステートレス化がデフォルトに

最大の変更点は、Streamable HTTPサーバーがデフォルトでステートレスになったことだ。

従来はinitializeハンドシェイクとMcp-Session-Idヘッダーでセッションを管理していたが、2.0ではこれが廃止された。プロトコルバージョンとケイパビリティはリクエストごとに送信されるため、どのサーバーインスタンスでも任意のリクエストを処理できる。スティッキーセッションや共有セッションストアが不要になる。

設定値としてはHttpServerTransportOptions.Statelessがtrueにデフォルト変更された。セッションが必要なサーバーはfalseを明示的に指定する。クライアント側は先にserver/discoverを試み、古いサーバーへのフォールバックとしてレガシーハンドシェイクを使う。

ステートフル専用オプションとレガシーSSEエンドポイントは、それぞれMCP9006とMCP9004の警告を出すようになった。

ルーティングをHTTPヘッダーで制御できるように

tools/callリクエストにはMcp-MethodとMcp-Nameヘッダーが付与される。さらに[McpHeader]属性でツールのパラメータをMcp-Param-*ヘッダーに昇格させることができる。これにより、ロードバランサーやゲートウェイがボディを読まずにヘッダーだけでルーティングできるようになる。

ヘッダーとボディの内容が一致しない場合はサーバーがHeaderMismatchエラーを返す。ボディが正とされる設計だ。

ツール呼び出し中のインタラクション:MRTR

ステートレス化によって失われた機能がある。サーバーが処理の途中でクライアントに入力を求める仕組みだ。これを代替するのがMulti Round-Trip Requests(MRTR)だ。

従来のステートフル接続では、サーバーが接続を保持したまま双方向にメッセージを送れたため、処理途中でクライアントへの問い合わせが自然に実現できた。ステートレス化でこの常時接続が失われたため、MRTRはクライアント主導の「再発行」という形でこれを再現する。具体的なフローは次のとおりだ。

  1. ツールが処理中にInputRequiredExceptionをスローし、InputRequest.ForElicitation・ForSampling・ForRootsListのいずれかで入力リクエストを構築する
  2. サーバーはそのリクエストをレスポンスとしてクライアントへ返す
  3. クライアントはユーザーやモデルから回答を収集し、inputResponsesを含めて同一のツール呼び出しを再発行する
  4. サーバーは再発行されたリクエストを受け取り、処理を継続する

McpClientはハンドラーが登録されていれば上記フローを自動で処理する。2025-11-25以前の旧クライアントとのステートフルセッションでは、SDKが従来のサーバー起点リクエストにブリッジする。ステートレス接続で旧クライアントと通信した場合はMcpExceptionが発生する。

なお、Roots・Sampling・Logging APIはMCP9005警告とともに非推奨となった(SEP-2577に基づく)。

2.1〜2.3のマイナーアップデート

2.0リリース後、8月〜10月にかけて2.1から2.3が続けてリリースされた。各バージョンはステートレス移行に伴う互換性確保と運用上の細部を段階的に整備している。主な変更点は以下のとおりだ。

  • 2.1:subscriptions/listenハンドラーの追加、server/discover失敗時のinitializeフォールバック(新旧クライアント混在環境での接続安定性向上)
  • 2.2:HttpServerSessionModeの導入(2025-11-25と2026-07-28リビジョンのクライアントが同一エンドポイントを共有可能に。段階的な移行を支援する設定)
  • 2.3:McpClient.ServerInfoのnullable化(破壊的変更)、ステートレスHTTPレスポンスが最初のプロトコルメッセージまでヘッダー送信を待つ動作に変更(長時間ハンドラーでは進捗出力かHTTPタイムアウト延長が必要)

セキュリティとrequestStateへの疑問

アナウンスのコメント欄では、あるユーザーがMRTRのrequestStateが改ざんやセッション間での使い回しに対して保護されているかを質問している。記事執筆時点で回答は付いていない。

2.0ではOAuth周りの厳格化も行われており、RFC 9207の発行者バリデーション、PKCE S256サポートの必須化、動的クライアント登録でのアプリケーションタイプ推論が加わっている。これらの強化により、トークンの不正利用リスクは一定程度低減されているが、requestState自体の改ざん耐性については現時点で公式の詳細説明はなく、チームが次に注力するエンド・ツー・エンドの認証・認可の整備を待つ必要がある。

SDKはNuGetで入手可能で、対象フレームワークは**.NET 8、9、10および.NET Standard 2.0**だ。リリースノートは2.0、2.1、2.2、2.3でそれぞれ確認できる。

詳細はMCP C# SDK 2.0 Makes HTTP Stateless by Default and Adds Multi Round-Trip Requestsを参照していただきたい。