DMBot onepage/ MCP protocol
MCP 2026-07-28 · protocol revision
MCP 2.0 升級解析：它不是取代 HTTP，而是更像 HTTP
這次演進把 MCP 的遠端核心改成無狀態、每個請求自我描述的協定；它仍跑在 HTTP 上，但不再把協定 session 綁在某一台 server，讓 agent 工具更容易進入標準雲端基礎設施。
Published: 2026-07-29Revision: 2026-07-28Source: ChatGPT share + MCP docs
01 / transport
HTTP 還在底下
HTTP 負責傳輸 request 與 response；MCP 定義的是 client 如何發現 server 能力、呼叫 tool、交換資源與處理 agent 工作流。
02 / core change
協定層不再記 session
新版拿掉 protocol-level session 與 Mcp-Session-Id；請求可由任一實例處理，不必 sticky routing 或共用 session store。
03 / application state
狀態改成顯式 handle
應用程式仍可有狀態，但由 tool 回傳 basket_id、workflow_id 或 task_id，後續呼叫明確帶回。
Key signals
這個修訂真正改變的四件事
Lifecycle
no session
無狀態核心移除舊有 handshake 與 session header；能力發現轉為
server/discover。Routing
any instance
每個請求含版本與 client metadata，可由一般負載平衡器分派到任一 server。
Extension
Tasks + Apps
長任務與 server-rendered UI 進入 extensions，讓核心協定維持精簡。
Caution
migrate deliberately
2026-07-28 是重大 wire-level 變動；實作端需看 SDK 與 client 的支援、協商與回退策略。
Before / after
從「server 偷記住」到「工具明確交還狀態」
舊
Session 綁住連線與實例
先 initialize，server 回傳 session ID；後續呼叫持續帶著它。遠端部署因此常需要黏著路由、共享 session store，或讓 gateway 理解更多協定細節。
新
每次 request 都帶自己的描述
新版以每請求 metadata 表示 protocol version、client info 與 capabilities；server 不可假設上一次請求留下的協定狀態，任一實例都能處理這一次工作。
關鍵
無狀態 protocol，不等於無狀態產品
購物籃、瀏覽器、對話與 workflow 一樣能保存；差別是 tool 要明確回傳 handle，模型在下一個 tool call 將它當作普通參數傳回。這使狀態可觀察、可組合，也更容易治理。
What ships around it
不是只有 Stateless：核心外圍也正在模組化
Tasks：讓長工作有正式生命週期server 可以把
tools/call 回成 task handle，再由 client 查詢、更新或取消；不必為了等一個長任務始終維持原始連線。MCP Apps：tool 結果可以有 UIserver 不只回 JSON，還能以 MCP Apps 帶出 server-rendered 的互動介面；適合把「工具結果」升級成可操作的小型 app。
OAuth / OIDC：朝實際企業部署對齊授權規範強化 issuer 驗證、credential isolation 與 scope 等議題，使 remote connector 的身份與權限模型更貼近既有 OAuth 與 OpenID Connect 實務。
Cache：讓能力清單不必反覆重抓
tools/list 可由 server 以 ttlMs 指示快取時間；對工具很多、變動不頻繁的 server，能減少發現階段的重複成本。Practical migration
如果你在做 remote MCP server，先檢查這四件事
把 session 內的隱性資料盤點出來區分「協定 session」與真正的業務狀態；後者改由資料庫或服務保存，並以明確 handle 讓 tool input/output 串起來。
讓每個請求能獨立驗證與路由不要依賴上次請求推斷 client capabilities；在 HTTP transport 上，確認版本協商、標準 headers、觀測資料與 load balancer 路由能接受無狀態請求。
為舊 client 留協商或回退路徑新版與舊版 wire protocol 有實質差異。先確認採用 SDK 的版本支援範圍，再用相容測試而非只看 server 是否能啟動來判定遷移完成。
把 handle 當成權限與生命週期物件handle 要能被授權、過期、撤銷與稽核；尤其是 browser、conversation、workflow 這類可能跨越敏感資料或長時間工作的識別碼。
Reading map
用四個問題判斷它對你的影響
你是否因 session 無法水平擴展？若 remote MCP server 目前需要 sticky session 或共用 session store，無狀態核心能直接簡化基礎設施；本機 stdio server 則未必是第一優先。
你的 tool 是否回傳了可延續工作的明確 ID？若後續步驟靠 server 內存猜 context，這是優先重構點。讓模型拿到並傳回 handle，將工作流變成可追蹤的資料合約。
長任務與互動 UI 是核心情境嗎？若是，留意 Tasks 與 MCP Apps 的 extension 支援；它們是與無狀態核心一同出現、但採獨立演進節奏的能力。
你的 client / SDK 是否真的支援這個 revision？規格版本與 SDK 實作速度並不同步。先測 protocol negotiation、舊 client fallback、OAuth 和實際部署路徑，再安排正式切換。
References