摘要： MCP 在 2026 年 7 月 28 日發表新版規格，以單一 HTTP 請求和標頭取代初始化握手與 session ID。改為無狀態後，伺服器不再需要 sticky routing，端點可快取、可路由並全球擴展，四種語言 SDK 同步更新。文章提醒提示注入的防護責任仍在伺服器端。
2026 年 7 月 28 日，Model Context Protocol（MCP）發表新版規格，社群替它取了「MCP 2.0」的暱稱，Simon Willison 則形容為「MCP 問世以來最大的改變」。真正被改動的設計只有一項，衝擊卻擴散到整個代理工具生態：MCP 由有狀態轉為無狀態。
舊架構的痛點：兩段式握手
舊規格採用 JSON-RPC 的有狀態架構：客戶端想呼叫任何工具，都得先發一個初始化請求拿到 Mcp-Session-Id，再靠第二個請求夾帶這個 ID 去執行工具。要讓服務橫向擴展，這在實務上是明顯的拖累——Willison 的說法是，伺服器端得自行保存 session 狀態，還要面對「把同一個 session 路由到同一台後端機器」的 sticky routing 難題。
改版後的做法：一次請求，協定資訊改走標頭
新版規格（2026-07-28 版）把整個流程收束為單一 HTTP 請求：協定版本、方法、工具名稱全交由 Mcp-Protocol-Version、Mcp-Method、Mcp-Name 三個 HTTP 標頭承載，客戶端資訊則塞進參數裡的 _meta 欄位。session 與握手都不復存在，一次請求結束。
Cloudflare 把它背後的意義說得最清楚：MCP 基礎設施這下「像網路的其他部分一樣運作——無狀態、可快取、可路由、可全球擴展」；加上 TypeScript、Python、Go、C# 四套 SDK 同步更新，代表 MCP 已經「完全生產就緒」。企業端缺的授權一角也補齊了：Enterprise-Managed Authorization 擴展轉入穩定狀態，帶來集中式身分驗證。
獨立開發者為何該關注
Willison 這番見解值得細讀，因為他既是 MCP 的批評者、也是實際動手的人。他肯定的地方是：單一請求的設計「從客戶端與伺服器端來看都乾淨太多」，實作複雜度明顯下降；而 MCP 工具「更容易審計與控制，簡單到連跑在筆電上的小模型」也足以驅動。相較之下，讓代理握有 shell 與 curl 權限「風險纏身」，MCP 則讓人「更容易推理代理的能力與哪裡可能出錯」。
他該提醒的一項也沒漏：他心裡始終卡著 2025 年 4 月的提示注入問題——那種「讓終端使用者自由混搭工具」的做法，等於把防堵資料外洩的差事丟回使用者身上。後來這段經歷長成他著名的「致命三體」（Lethal Trifecta）論述。
實作上，他一週就交出三樣東西：可零安裝執行的檢查工具 mcp-explorer；架在他個人部落格 Datasette 上的 datasette-mcp（提供 execute_sql 等三個工具，SQL 目前限定唯讀）；以及給 LLM 用的外掛 llm-mcp-client。他的結論說得很白：「在 LLM 上建置敏感應用時，我打算大幅加重對 MCP 的倚賴。」
工具開發者該做的三件事
第一，MCP 伺服器若還在跑舊式有狀態實作，改採 2026-07-28 版規格後，維運上不必再養 session 儲存，也不必處理 sticky routing。第二，無狀態又加上可快取，CDN 與邊緣節點就有辦法直接供應 MCP 端點——工具清單與 schema 放到邊緣快取，是這一輪最順手的效能紅利。第三，提示注入的責任歸屬不會因為規格改版而鬆動：工具混搭越普遍，伺服器端的輸出過濾與權限限縮就越要做足。