背景：從綁定工作階段的連線，走向每次請求自帶脈絡
MCP（Model Context Protocol）是一套開放協定，用來標準化應用程式如何把上下文與工具提供給大型語言模型，讓模型能取得外部資料並實際執行動作。根據 InfoQ 報導，由微軟與社群共同維護、以 ASP.NET Core 為基礎的官方 MCP C# SDK，在 2026 年 10 月發表 2.0 穩定版，實作 MCP 規格 2026-07-28 修訂版；隨後在 8 月到 10 月之間又陸續推出 2.1、2.2、2.3 三個小版本。SDK 團隊形容這是協定問世以來規模最大的一次規格修訂，因為它重新設計了 MCP 在 HTTP 上頭的運作方式。
過去的 Streamable HTTP 建立在工作階段之上。客戶端先送出 initialize 握手，伺服器回發 Mcp-Session-Id 標頭，後續請求都必須帶著這個識別碼，流量因此得黏著到同一台伺服器實例，或讓後端共用一套工作階段儲存。2.0 把這條路徑切斷：initialize 握手與 Mcp-Session-Id 一併移除，協定版本與能力宣告改為隨著每一次請求傳遞。如此一來，任何一台伺服器實例都能處理任何一個請求，負載平衡器不必再做黏著路由，後端也不必共用工作階段儲存。
核心內容：預設無狀態與可路由的標頭
在伺服器端，HttpServerTransportOptions.Stateless 現在預設為 true；真正需要工作階段的服務必須明確設為 false。客戶端連線時會先試探 server/discover，失敗才退回舊版握手，以相容於尚未升級的伺服器。只適用於有狀態模式的選項，以及舊有的 SSE 端點，會分別觸發 MCP9006 與 MCP9004 警告，讓維護者早一步發現手上的設定已不再被支援。
另一個重點，是讓基礎設施能在不讀取 HTTP 內文的前提下分流。tools/call 請求現在會攜帶 Mcp-Method 與 Mcp-Name 標頭，而 [McpHeader] 屬性可把某個工具參數提升為 Mcp-Param-* 標頭，於是負載平衡器與閘道器可以直接依標頭決定路由，不必為了判斷請求內容而解析內文。SDK 對此加了保險：內文仍然是權威來源，若標頭與內文不一致，伺服器會回傳 HeaderMismatch 錯誤，避免標頭成為繞過驗證的縫隙。
MRTR：把「執行中途反問」改成可重送的多回合請求
無狀態化帶來一個副作用。以往伺服器若在工具執行途中需要向使用者追問、要求補充資訊，或取得額外的取樣與根目錄清單，可以透過既有的通道主動發起請求；連線不再綁定之後，這條通道也隨之消失。2.0 以 Multi Round-Trip Requests（MRTR，多回合請求）取代：工具擲出 InputRequiredException，附上一到多個輸入請求，這些請求由 InputRequest.ForElicitation、ForSampling 或 ForRootsList 建構，並夾帶一個不透明的 requestState。客戶端收集完答案後，帶著 inputResponses 重新發出同一次呼叫。若應用程式已註冊對應的處理常式，McpClient 會自動完成這個往返，開發者不必手寫重送邏輯。
相容性上，若走的是有狀態工作階段、且客戶端仍是 2025-11-25 或更早版本，SDK 會把 MRTR 橋接回舊式由伺服器發起的請求；但若在無狀態連線下遇到舊客戶端，這個請求就只能以 McpException 的形式浮出檯面，該項互動等同不可用。
影響與限制：棄用、OAuth 收緊與仍待釐清的問題
依 SEP-2577，Roots、Sampling、Logging 等 API 在 MCP9005 之下被標記為棄用。官方強調穩定的 1.x API 仍可運作，例外是 Tasks：它被移到需選擇啟用的 ModelContextProtocol.Extensions.Tasks 套件，且與 1.3、1.4 中的實驗版本不相容；另有一個實驗性的 ModelContextProtocol.Extensions.Apps 套件對應 MCP Apps。OAuth 行為也一併收緊，包含 RFC 9207 的簽發者驗證、強制宣告支援 PKCE S256，以及在動態客戶端註冊時推斷應用程式類型。套件目標框架涵蓋 .NET 8、9、10 與 .NET Standard 2.0。
三個小版本各自補上缺口。2.1 加入可選的 subscriptions/listen 處理常式，供自訂的伺服器端通知串流使用，並在 server/discover 於 HTTP 層失敗時退回 initialize；2.2 推出 HttpServerSessionMode，讓使用 2025-11-25 與 2026-07-28 兩種修訂版的客戶端共用同一個端點，同時修掉 McpHeaderEncoder.DecodeValue 的例外；2.3 把 McpClient.ServerInfo 改為可為 null，這是原始碼層級的重大變更，因為伺服器可能省略 server/discover 中的選填身分資訊，發布說明也提醒不可把伺服器自述的身分當作安全判斷依據。
實務上還有幾個要留意的地方。新版 Streamable HTTP 回應會等到第一個協定訊息出現才送出標頭，因此長時間靜默的處理常式若不輸出進度，就可能被視為逾時，需要調整 HTTP 逾時設定或補上進度訊息。其他變更包括列出工具、提示與資源時保留註冊順序，開放 McpClientOptions.TimeProvider 以便撰寫可重現的逾時測試，將 OAuth 排除於 DiscoverProbeTimeout 之外，以及在等待 stdio 伺服器優雅結束前先關閉其輸入。至於安全性，有讀者在公告下提問：協定是否對 requestState 做防竄改或跨工作階段重複使用的保護？討論串中並未出現回覆。團隊則表示，下一個重點會放在端到端的驗證與授權。
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。