代理工具
MCP 2026-07-28 拆除連線階段 session，工具伺服器改走無狀態 HTTP
MCP 新修訂移除初始化握手與 `Mcp-Session-Id`，讓單次請求可由任一伺服器實例處理。這是破壞性協定變更；在最終版與主要 SDK 完成同步前，部署者仍須保留版本協商及舊版回退。
Model Context Protocol（MCP）預定於 7 月 28 日定稿的新版，重寫了代理與工具伺服器之間的連線生命週期。舊版 Streamable HTTP 通常先執行 initialize，再以 Mcp-Session-Id 維持後續呼叫；新版移除兩者，要求每個請求攜帶協定版本、客戶端能力與身分資訊，並新增 server/discover 供客戶端查詢伺服器支援的版本及能力。實務上，請求不再黏著特定實例，遠端 MCP 服務可直接放在一般 round-robin 負載平衡器後方，減少共享 session store 與 sticky routing 的需求。
狀態並未完全消失，而是上移到應用層：需要跨呼叫保存購物車、瀏覽器或工作階段的工具，必須回傳明確 handle，再由模型於下一次呼叫傳回。伺服器向客戶端索取確認或額外輸入，也改成 Multi Round-Trip Requests；伺服器先回傳 input_required，客戶端取得使用者輸入後重送原請求。長任務則移至獨立 Tasks extension，透過 tasks/get、tasks/update 與 tasks/cancel 管理。
新版另要求 HTTP POST 帶有 Mcp-Method、Mcp-Name，方便閘道在不解析 JSON body 的情況下路由及限流；工具與資源清單加入 ttlMs、cacheScope，並統一 OpenTelemetry trace context。OAuth 部分增加 issuer 驗證及憑證按授權伺服器隔離等要求。
遷移風險不可低估：ping、舊式 logging 操作與多種通知被移除，Roots、Sampling、Logging 進入棄用期，斷線後也不再以 SSE event ID 恢復請求。截至本次資料擷取，官方 changelog 仍位於 draft 路徑，因此工程團隊應確認最終 schema、所用 SDK 的採用進度與降級行為，不宜只替換版本字串便直接上線。