
MCP 標準更新! TAG 準備好了嗎?
昨天缺的那個 tag,昨天下午補上了。
昨天早上九點,本刊核對官方 repo 時只看到 5 月 29 日打的 2026-07-28-RC,正式 tag 還沒出現。昨天那篇稿子就是在那個狀態下寫的。
現在它出來了。GitHub releases 頁顯示 2026-07-28 已於 7 月 28 日發布,頁面寫明這是該版的 stable release。四個 Tier 1 SDK(TypeScript、Python、Go、C#)都已更新,Rust SDK 是 beta。
昨天講過的不重複(無狀態核心、拿掉 initialize 與 Mcp-Session-Id、Tasks 升為正式擴充、Apps 進來、Roots/Sampling/Logging 標 deprecated)。定案版多出來、而且會影響你怎麼寫程式的是這幾項:
- 版本協商改成逐請求。 每個請求用
_meta裡的io.modelcontextprotocol/protocolVersion宣告版本,server 逐請求接受或拒絕;Streamable HTTP 上同一個值也走MCP-Protocol-Version標頭。不支援就回UnsupportedProtocolVersionError,並附上它支援哪些版本。 server/discover是強制 RPC。 一次請求拿回 server 支援的協定版本、能力與身分。client 可以不叫它,直接送請求再處理版本錯誤。- HTTP+SSE transport 標為 deprecated,官方給 12 個月的下車期。
- Dynamic Client Registration 轉向 CIMD(Client ID Metadata Documents),DCR 過渡期仍可用;授權流程要求 RFC 9207 的 issuer 驗證。
- list 結果可快取,回應帶
ttlMs與cacheScope。
有一個對不上的地方值得記一筆:文件站的 versioning 頁到本刊今天上午核對時,仍寫著 current protocol version 是 2025-11-25。 但同一頁的內文已經整頁連向 /specification/2026-07-28/ 的各節——deprecated 清單、transports、versioning 都是。看起來是文件更新的時間差,不是規格本身的矛盾;不過如果你的實作是照那一頁的 current 值去決定預設協定版本,今天要自己確認一次。
今天三件事:確認你用的 SDK 版本有沒有跟上定案版;把還在讀 Mcp-Session-Id 的 transport 改成逐請求從 _meta 讀版本;還在用 2025-11-25 實驗版 Tasks API 的實作照官方指引遷移——那仍是唯一明講的破壞性遷移。
本篇是對官方 releases 頁、官方部落格與文件站的檢視,本刊沒有實際跑過遷移。
SOURCES
- Amodelcontextprotocol/modelcontextprotocol releases:2026-07-28 stable release
- AThe 2026-07-28 Specification(MCP 官方部落格)
- AVersioning(MCP 官方文件站)
來源分級:A = 一手公告/論文/官方文件 · B = 可信媒體 · C = 可參考但需脈絡 · D = 觀察用,不可當事實。
本文由 AI 協助研究與起草,矽基前沿編輯部編修,總編輯廖玄同審閱定稿。 編輯方針與 AI 使用說明

