MCP 要拿掉 session 了：7/28 新版，server 該改什麼

一個很常見的畫面：你寫好一個 MCP server，接上內部工具，本地跑得好好的。等要放上雲、開兩三台機器分流量，麻煩來了——client 一連上會先做一輪握手、拿到一組 session id，之後每個請求都得回到同一台機器。於是你得在 gateway 掛 sticky routing，或架一個共享的 session store 讓每台機器都認得這組 session。一個本來該像 HTTP API 那樣「隨便丟上去就能擴充」的東西，硬是被 session 綁成了有狀態服務。

Model Context Protocol（MCP，Anthropic 2024 年底提出、現由開放社群治理的 AI 代理人工具連接標準）下一版規格，正是衝著這件事來的。版本代號 2026-07-28，它的 release candidate 已經在 2026-05-21 放出，最終規格會在 7 月 28 日定案，中間留十週給大家拿真流量驗證。6 月 29 日官方再補一篇：Python、TypeScript、Go、C# 四個 Tier 1 SDK 的 beta 都齊了。

這一版動的東西不少——Tasks、MCP Apps、授權、deprecation 政策都改了——但真正的主角只有一個。MCP 把 session 整個拿掉了，server 從此能像一般 HTTP API 那樣，隨便丟到哪台機器都接得住。 這種「不記得你是誰、每次請求自帶完整資訊」的設計，技術上叫無狀態（stateless）。

新版最大的動作：把 session 整個拿掉

先講清楚 session 在這裡是什麼。舊版的 MCP 連線像進一家會員店：你進門要先報身分（initialize／initialized 握手），店員發你一張號碼牌（Mcp-Session-Id），之後你每次講話，店員靠這張牌記得「你是誰、剛剛聊到哪」。方便，但代價是你只能回到同一個櫃台——換一台機器，那張牌就不認得了。

新版把號碼牌收掉了。連線不再有握手，client 的資訊、協定版本、能力宣告，改成放進每一個請求自帶的 _meta 欄位。等於你每次來都自己戴著識別證，哪個櫃台都能直接辦事。對部署的直接好處是：遠端 server 可以跑在一般的 round-robin 負載平衡後面，不用 sticky routing、也不用共享 session store。官方那句話說得很白——以前需要黏著會話、共享狀態、還要在 gateway 深度解析封包的遠端 server，現在「可以跑在一台普通的輪詢負載平衡器後面」。

為了讓負載平衡器不用拆封包就能路由，新版還加了 Mcp-Method／Mcp-Name 這兩個路由 header，以及 ttlMs／cacheScope 兩個快取參數，讓 client 可以照 server 允許的時間快取 tools/list 這類結果。

舊版對新版，具體差在哪

把會動到的地方並排看最清楚：

面向	舊版（2025-11-25 及更早）	2026-07-28 新版
連線起手	initialize／initialized 握手	拿掉握手，資訊放進每次請求的 _meta
會話識別	Mcp-Session-Id header ＋ sticky session	無 session，任何請求可打任何 server 實例
部署方式	需 sticky routing／共享 session store	一般 round-robin 負載平衡即可
長時任務	Tasks 是實驗性核心功能	Tasks 改成 extension；tasks/get／update／cancel，移除 tasks/list
server 主動提問	撐開 SSE 串流等回應	改回 InputRequiredResult
缺資源錯誤碼	自訂 -32002	JSON-RPC 標準 -32602（Invalid Params）
互動式 UI	無標準	MCP Apps：host 在 sandbox iframe 渲染 HTML

這張表裡任何一格，只要你的 server 或 client 現在依賴它，就是你採用新版時要處理的點。

除了 stateless，Tasks、MCP Apps、授權也一起改了

Tasks（讓一次工具呼叫變成可追蹤的長時任務）從實驗性核心功能升成正式的 extension。方法收斂成 tasks/get、tasks/update、tasks/cancel，由 server 決定何時把一次 tools/call 當成任務跑；tasks/list 被拿掉了，因為沒有 session 就很難安全地界定「列出誰的任務」。已經照 2025-11-25 版寫過 Tasks 的，這塊要遷移。

MCP Apps 是新東西：server 可以送一段互動式 HTML，host 端在 sandbox iframe 裡預取、快取、做資安審查之後才渲染，而且畫面上的每個動作都走跟直接呼叫工具一樣的授權與同意路徑。等於工具第一次能帶自己的介面，而不用逼 host 猜要怎麼呈現。

授權層則整體向 OAuth 2.0 與 OpenID Connect 靠攏——一組 SEP（規格增修提案）要求 client 依 RFC 9207 驗證 iss 之類的細節。另外新版立了正式的 deprecation 政策：每個功能有 Active → Deprecated → Removed 三段生命週期，從標記淘汰到最早移除至少隔 12 個月；Roots、Sampling、Logging 這三個舊功能這一版進入 deprecated，各自有替代路徑。

7/28 不是大限：官方說舊 server 照常跑

這點最容易被傳歪，得單獨講。7 月 28 日不是一個「不改就壞」的切換日。官方在 SDK 那篇寫得很直接：既有的 server 在 7/28 之後照常運作，採用新版是自願的。上面那些破壞性變更——session 消失、握手移除、錯誤碼換號——只有在你決定把 server 或 client 升到新規格時才會碰到。

換句話說，7/28 是「正式版定案」的日子，不是「舊版失效」的日子。你不會一覺醒來發現線上服務掛了。真正的時間壓力比較像：如果你想吃到 stateless 帶來的好處，或者你維護的是別人會依賴的 SDK／library，那這十週的驗證窗就是拿來測的。

在跑 MCP server？這週可以做的幾件事

如果你手上有 MCP server 或 client，官方建議的動作大致是這幾條，我把它整理成一份遷移前清單：

1. 先裝對應的 beta 測：Python v2、TypeScript v2、Go（v1.7.0-pre.1）、C# 都有 beta。開一條 branch，用你真實的流量跑，不要只測 happy path。
2. Pin 精確版本：RC 到正式版之間 public API 還可能動，測的時候把版本鎖死。
3. 是 library 作者就加版本上限：像 mcp>=1.27,<2，別讓下游使用者不小心被拉上 v2。
4. 盤點你依賴的「會變的東西」：有沒有用到 session／sticky routing、Mcp-Session-Id、initialize 握手、tasks/list、-32002 錯誤碼、或撐開 SSE 等回應？這些是要改的地方。
5. 記下淘汰功能的替代路徑：用到 Roots、Sampling、Logging 的，先想好換成工具參數／資源 URI、直接呼叫 LLM API、stderr 或 OpenTelemetry。
6. 對照授權新要求：如果你有做 OAuth／OIDC，檢查 client 驗 iss 等新規範。
7. 不急的就別急：舊 server 7/28 照常跑，先測、再排遷移時間，不用趕在定案日之前。

要不要遷、什麼時候遷，得看你 server 的部署形態（有沒有水平擴充需求）和你依賴了多少會變的東西——這個判斷留給你自己。但方向很清楚：MCP 正在從「本地跑得動就好」的連接器，往「能穩穩放上生產雲」的協定走。這一版把 session 拿掉，就是那條路上最實際的一步。

常見問題

7/28 我的 MCP server 會不會突然壞掉？ 不會。官方明說既有 server 在 7/28 照常運作、採用新版屬自願，破壞性變更只在你改用新規格時才適用。

這一版最關鍵的改動是什麼？ 把協定改成無狀態：拿掉 initialize 握手與 Mcp-Session-Id，client 資訊改放進每個請求的 _meta，遠端 server 因此能水平擴充。

我現在就該動手遷移嗎？ 不急。可以先裝對應 SDK 的 beta、用真實流量測、pin 精確版本；正式規格 7/28 定案，RC 到正式版之間 public API 仍可能微調。

---

資料來源：Model Context Protocol 官方 blog（2026-07-28 Specification Release Candidate、Beta SDKs 公告）、Stacktree、MCP.Directory、Akamai security research。

矽基前沿 · 工作現場線（編輯：廖玄同），《MCP 要拿掉 session 了：7/28 新版，server 該改什麼》，矽基前沿 [Si]gnals，2026-07-05。https://signals.tw/articles/mcp-stateless-spec-2026-07-28/