MCP協議7月28日鎖定無狀態規范：握手和會話將移除，這款零配置CLI能提前掃出所有破壞性變更

如果你正在運行一個MCP服務器，下個月28日可能會是一個棘手的時間節點——2026年7月28日，Model Context Protocol將正式鎖定其2026-07-28規范。這將是一次影響巨大的變更：握手流程和會話機制會被徹底移除，整個協議轉向無狀態。許多今天還能正常工作的集成，屆時會直接停擺。

為了應對這場遷移，一位開發者構建了名為mcp-vet的零配置命令行工具。它不需要賬戶、不需要API密鑰，甚至不需要網絡連接，就能直接掃描你的MCP服務器源代碼，找出所有即將失效的模式，并告訴你該改什么。運行方式只有一行命令：npx @booyaka/mcp-vet 。

7月28日正式生效：哪些東西會停止工作

這次規范鎖定的變化集中在五個核心方向，每一項都意味著現有代碼必須做出調整。最根本的改變是：協議不再維護服務端與客戶端之間的會話狀態。

首先，Mcp-Session-Id請求頭和協議級會話被徹底刪除。過去，客戶端信息與能力交換依賴這個會話頭。現在，這些信息全部挪到每個請求的_meta字段里，隨請求一起傳遞。這意味著不再有任何全局會話上下文，每個請求都自包含所需元數據。

其次，初始化握手流程（initialize/notifications/initialized）不復存在。協議版本、客戶端信息、能力聲明不再是通過一次握手“協商”出來的，而是在每條請求中攜帶。從設計角度看，這迫使客戶端和服務端都接受一種更松散、更可組合的交互模型。

第三，錯誤代碼-32002（missing resource）會被替換為JSON-RPC標準錯誤-32602 Invalid Params。對于已經做過錯判處理的應用，需要重新梳理這些錯誤碼的映射。

第四，遺留的Tasks方法也迎來了大改。tasks/get、tasks/update、tasks/cancel的參數形狀會發生變化，而tasks/list和tasks/result兩個方法直接被移除。想要獲取任務狀態，只能通過tasks/get進行輪詢。如果代碼中有對舊清單或結果端點的調用，都需要替換或重構。

最后，三個能力被標記為“棄用”并進入12個月的寬限期：roots、sampling和logging。這意味著它們不會立刻中斷服務，但在未來一年內會逐步退出規范。如果服務器依賴這些功能，現在是規劃替代方案的窗口期。

不止匹配字符串，而是理解代碼怎么寫

mcp-vet的巧妙之處在于，它并不是一個簡單的文本搜索腳本。它用編譯器級別的代碼分析（TypeScript/JavaScript端基于ts-morph，Python端通過一個綁定的AST腳本）去理解代碼結構，然后匹配實際開發中最常見的幾十種書寫形式。

它能夠識別直接寫在代碼里的方法名字符串，比如'tasks/list'、'sampling/createMessage'、'logging/setLevel'。但它也知道很多開發者是通過SDK的schema常量來注冊處理程序的，例如server.setRequestHandler(InitializeRequestSchema, …)。在這種情況下，工具會自動將InitializeRequestSchema映射到相應的規則，判斷它是否指向即將失效的初始化握手。

對于Python SDK，情況更復雜一些。許多開發者通過構造器形成能力聲明，例如ClientCapabilities(roots=RootsCapability())。mcp-vet會在AST層面識別這種結構，并精準地標記出來。同樣，對sessionIdGenerator的使用，它能夠區分真正的生成器（需要標記）和已經遷移后給出的sessionIdGenerator: undefined（應被忽略）。

在真實服務器上跑出零誤報

為了驗證可靠性，這套工具被直接拿來掃描官方的MCP TypeScript SDK范例服務器。結果找到了6個真實問題，包括一處sessionIdGenerator的使用——這種模式往往隱藏在代碼中，很少會以字面頭信息的形式出現，卻依然被捕捉到了。同時，對那些只出現在注釋里的Mcp-Session-Id或initialize字樣，工具保持沉默，沒有產生誤報。

在更廣范圍的官方參考服務器（同時包含TypeScript和Python實現）上運行后，mcp-vet報告了0個誤報。這種精確性源于靜態結構化檢查，而非基于文本的模糊匹配。每條發現都攜帶一個置信度標簽（high、medium、low），團隊可以通過--min-confidence參數調節輸出信號的強度，讓流水線只對高置信度的破壞性變更報錯。

下面是一個典型的輸出片段：

legacy-routing.ts:36 BREAKING MCP_SESSION_ID req.headers['mcp-session-id']legacy-routing.ts:41 BREAKING MCP_SESSION_ID sessionIdGenerator: () => randomUUID()sse-polling.ts:34 DEPRECATED LOGGING_CAP capabilities: { logging: {} }6 finding(s): 5 BREAKING, 1 DEPRECATED

從這個例子可以看到，每條發現都給出了文件、行號、嚴重級別（BREAKING或DEPRECATED）、規則標識以及匹配到的具體代碼片段。這讓修復變得目標明確。

自動修復與CI集成

除了檢測，mcp-vet還嘗試對機械性的修改提供一鍵自動修復。開發者期待的大規模遷移中，有些破壞點是可以完全由工具代為處理的，比如將舊的初始錯誤碼替換為新的JSON-RPC標準代碼。盡管不能覆蓋所有情況，這種自動化能力已經能節省大量重寫時間。

更關鍵的是，它在進程退出時，只要發現任何BREAKING級別的問題，就會返回非零退出碼。這個設計讓它可以直接嵌入持續集成流水線：在每次代碼提交后，自動對MCP服務端代碼進行掃描，一旦發現適配于2026-07-28規范的新增破壞點，就阻斷構建。對于維護著多個MCP服務器的團隊來說，這幾乎是把七個多月后的兼容性風險提前“凍結”在當前時刻。

距離2026年7月28日只剩下不到五周。無狀態化的協議設計終究會帶來更簡潔的實現和更少的會話維護負擔，但前提是目前的代碼能夠平穩度過這次鎖定。如果還沒有跑過一遍全量掃描，那可能真的需要現在就開始動手了。