MCP 2026 RC 讓伺服器轉向無狀態 HTTP
4 項 MCP 2026 RC 變更，重點是移除 session、改用標頭路由與新快取控制，伺服器設計要提早調整。
這份清單整理 4 項 MCP 2026 RC 變更，讓你判斷伺服器要先改路由、快取，還是淘汰舊功能。
2026-07-28 的 [Model Context Protocol](https://modelcontextprotocol.io/) release candidate，直接改寫了伺服器的接法。看完這 4 項，你可以決定要不要把服務搬到一般 HTTP 負載平衡器後面、何時移除 session 假設，以及哪些功能要先排進重構。
| 項目 | 規格 A | 規格 B | 規格 C |
|---|---|---|---|
| Session 移除 | Mcp-Session-Id 刪除 | initialize 取消 | 任一請求可打到任一實例 |
| 標頭路由 | Mcp-Method | Mcp-Name | 可先於 body 解析前分流 |
| 功能退場 | Roots | Sampling | Logging |
| 新控制項 | ttlMs | cacheScope | Tasks、MCP Apps |
1. 無狀態化是這次最核心的改動
訂閱 AI 趨勢週報
每週精選模型發布、工具應用與深度分析，直送信箱。不定期，不騷擾。
不會寄垃圾信，隨時可取消。
這版 RC 把協定層的 session 拿掉了，Mcp-Session-Id 不再存在，initialize 與 initialized 也一起移除。版本與能力資訊改由每次請求的 _meta 帶入，前置能力查詢則交給 server/discover。
對營運來說，這代表 MCP 可以更自然地放在一般 round-robin load balancer 後面，不必依賴 sticky routing 或共享 session store。對開發者來說，協定狀態不該再拿來放應用狀態，像購物車、瀏覽器狀態或部署句柄，都應該用明確 ID 傳進工具。
- 協定層不再需要 session affinity
- 連線前少一次 initialize 往返
- 應用狀態回到應用層處理
2. 路由改看標頭，不必先讀 body
所有 Streamable HTTP 請求都必須帶 Mcp-Method 和 Mcp-Name。這讓 gateway、load balancer、rate limiter 可以在不緩衝 JSON-RPC body 的情況下先做分流，也讓伺服器能檢查標頭與內容是否一致。
這對基礎設施團隊很直接，因為標頭層 L7 routing 比 body inspection 便宜，也更符合既有 HTTP 工具鏈。像 [Cloudflare](https://www.cloudflare.com/) Workers、API gateway、標準 proxy 都能直接吃這套設計。協定不是變難，而是更像原生 HTTP。
Example headers:
Mcp-Method: tools/call
Mcp-Name: search_docs3. Roots、Sampling、Logging 都進入退場路線
SEP-2577 把 Roots、Sampling、Logging 標記為 deprecated，並套用新的生命週期政策。Active、Deprecated、Removed 三階段之間至少隔 12 個月，所以短期內還能用，但遷移工作已經該開始排。
Roots 會往明確工具參數、resource URI 或伺服器設定移動；Logging 則會轉向 stdio 的 stderr，或用 [OpenTelemetry](https://opentelemetry.io/) 做結構化觀測。Sampling 最難替換，因為它讓伺服器工具借用客戶端 LLM 做 completions，規格方向是改成直接呼叫模型供應商。
- Roots：改成顯式輸入或設定
- Logging：改走 stderr 或 OpenTelemetry
- Sampling：重構成直接呼叫 LLM API
4. 快取、任務與 App 互動都更清楚了
RC 新增了標準化的 client-side cache 控制，針對 tools/list、resources/list、resources/read 回應加入 ttlMs 和 cacheScope。這讓 client 知道資料多久內算新鮮，也知道快取能不能跨使用者共用。
另外兩個擴充補上常見缺口。Tasks extension 讓長任務回傳 task handle，再用 tasks/get 追蹤；MCP Apps 則讓工具在 sandboxed iframe 裡回傳互動式 HTML，適合 [Claude](https://claude.ai/)、[ChatGPT](https://chatgpt.com/)、[VS Code](https://code.visualstudio.com/) 和 [Goose](https://block.github.io/goose/) 這類 client。
Cache fields:
ttlMs: 60000
cacheScope: user5. 遷移先做這 4 件事
規格說你有 10 週可以調整到最終版，所以實作順序其實很清楚。先移除任何依賴 Mcp-Session-Id 的路由邏輯，再把新標頭補到所有 Streamable HTTP 請求，接著拿普通 round-robin load balancer 測一次。
如果你的 server 目前用了 Sampling 或 Roots，現在就該開 refactor，而不是等到 final spec 才處理。同時替 list 類回應加上 ttlMs，讓 client 能正確快取。RC 的目的，就是在規格鎖定前先把真實工作負載跑過一輪。
- 刪掉 session-based routing 假設
- 補上
Mcp-Method與Mcp-Name - 在標準 load balancer 後驗證
- 提前規劃 Sampling 與 Roots 替代方案
怎麼挑
如果你管的是 MCP 基礎設施，先處理 session 與標頭，因為它們直接影響路由與可用性。若你是在 MCP 上做工具，優先看 Sampling、Roots、Logging 的退場路線。若你做的是 client，則先處理快取與任務流程，這兩項最能立刻改善效能與體驗。
簡單說，營運團隊先改傳輸假設，平台團隊先補觀測與快取，產品團隊則要盯住 MCP Apps 這種更像應用的互動模型。