7 個 MCP 變更，幫助代理建構者上手
7 項 MCP 變更一次看懂：無狀態請求、明確狀態、擴充機制、任務、授權、JSON Schema 與治理，幫你判斷該先改哪一塊。
這份清單整理 7 個 MCP 變更，幫你判斷代理系統該先改無狀態請求、授權，還是工具契約與擴充機制。
如果你正在做代理式系統，這 7 項變更可以直接幫你決定：哪些地方要先調整，哪些功能可以延後，哪些設計會影響之後的擴充與維運。
| 項目 | 變更重點 | 實際影響 |
|---|---|---|
| 無狀態請求 | 請求攜帶版本、用戶端資訊、能力宣告 | 更容易做路由與水平擴充 |
| 明確狀態把手 | 像 basket_id 這類狀態改由工具輸出傳遞 | 工作流程更透明 |
| 擴充機制 | 反向 DNS 命名、版本化倉庫、能力協商 | 新功能更好長出來 |
| 任務 | task/get、task/update、task/cancel | 長時間工作可納入協定 |
| 授權更新 | 更明確的 OAuth／OIDC 規則 | 多伺服器部署更安全 |
| JSON Schema 2020-12 | 支援組合、條件式、參照 | 工具契約更精準 |
| 治理政策 | Active、Deprecated、Removed 狀態 | 升級路徑更清楚 |
1. 無狀態請求
訂閱 AI 趨勢週報
每週精選模型發布、工具應用與深度分析，直送信箱。不定期，不騷擾。
不會寄垃圾信，隨時可取消。
MCP 正在把協定層往無狀態請求推進，這會讓它更適合放在負載平衡器、閘道器和速率限制器後面。也就是說，伺服器不必再依賴跨請求保留的會話，單次請求就能帶齊需要的資訊。
這個改動的價值，在於它讓 MCP 更像一般 HTTP 服務。團隊可以更容易做路由、擴充與除錯，不必為了會話黏著性額外補很多基礎設施。草案甚至使用 Mcp-Method、Mcp-Name 這類標頭，讓基礎設施能直接判斷請求類型。
- 適合
tools/call這類自包含呼叫 - 協定層不再需要 sticky session
- 更適合分散式部署與多節點架構
2. 明確狀態把手
無狀態不代表沒有狀態，而是把狀態移到代理看得見的地方。工具可以回傳一個把手，例如 basket_id 或 browser_id，後續呼叫再直接帶著這個值繼續做事。
這樣的好處是工作流程更好推理，模型不必依賴隱藏的 session 資訊。對於記錄、觀測與編排來說，也更容易在整條流程中追蹤同一個明確識別碼。
- 像
basket_id這種識別碼會變成流程的一部分 - 前一步工具輸出可直接餵給下一步
- 仍然需要做範圍控管、驗證與到期處理
3. 結構化擴充機制
MCP 現在替擴充功能提供更正式的位置，包含反向 DNS 識別、版本化擴充倉庫、委派維護者與能力協商。這讓有用但還不適合放進核心規格的功能，有了更清楚的成長路徑。
最先出現的例子是 MCP Apps 和 Tasks。MCP Apps 可以提供互動式 HTML，讓主機在沙箱 iframe 中呈現；Tasks 則讓伺服器把長時間工作包成可追蹤的把手，客戶端之後可以查詢、更新或取消。
- 擴充 ID 採用反向 DNS 命名
- 客戶端與伺服器透過能力表宣告支援項目
- Tasks 支援
tasks/get、tasks/update、tasks/cancel
4. 有政策的淘汰機制
Roots、Sampling 和 Logging 已經被列入淘汰範圍，這代表 MCP 正在收斂它的核心責任。規格想把焦點放回客戶端與伺服器之間的契約，其他相鄰功能則交給更適合處理它們的系統。
這也意味著，工作區邊界常常可以移到工具輸入、資源 URI 或伺服器設定；觀測資料則可以交給 stderr 或 OpenTelemetry。這些淘汰目前只是標註，不是立刻移除，真正刪除還需要另開 SEP，團隊有時間慢慢調整。
- Roots 可改由工具參數或資源 URI 承接
- Sampling 可交給供應商 API
- Logging 可改走 stderr 與 OpenTelemetry
5. 更嚴謹的授權規則
這次草案把 OAuth 與 OpenID Connect 的細節收緊，特別是那種「一個用戶端連很多 MCP 伺服器」的常見情境。內容包含發行者驗證、憑證綁定、localhost 重新導向支援，以及桌面或命令列用戶端的註冊方式。
這些改動看起來不大，但在真實部署裡很重要。只要系統會碰到私有資料、付費服務或使用者專屬流程，授權規則就不是附屬細節，而是產品安全的一部分。
用戶端 → 授權伺服器 → MCP 伺服器
驗證發行者
將憑證綁定到發行伺服器
支援桌面與 CLI 的 localhost 重新導向6. 完整 JSON Schema 支援
MCP 的工具 schema 現在支援完整的 JSON Schema 2020-12，這會讓工具契約更精準。輸入仍然要求最外層是 object，但作者可以用組合、條件式與參照去描述更接近真實世界的資料形狀。
對於有多條分支、可選欄位或輸出結構不固定的工具，這特別有用。不過規格也提醒實作者不要盲目追外部參照，驗證工作量也要設上限，否則表達力變強，效能與安全風險也會跟著上升。
- 支援組合與條件式
- 輸出 schema 不受同樣限制
- 驗證時要注意效能與安全邊界
7. 能吸收變動的治理方式
草案也補上治理機制，讓未來變更更容易管理。功能生命週期政策定義了 Active、Deprecated、Removed 三種狀態，而且從標註淘汰到最早移除，至少要隔 12 個月。
另外，標準路線的 SEP 也要求在進入 Final 前，對應情境要先出現在相容性測試套件中。這讓 SDK、伺服器與用戶端有共同目標，降低各自解讀規格時產生的偏差。
怎麼挑
如果你在管 MCP 基礎設施，先看無狀態請求與授權更新；如果你在做工具或代理流程，優先處理明確狀態把手、Tasks 與 JSON Schema；如果你在維護平台或 SDK，擴充機制與治理政策會最直接影響你的路線圖。
多數團隊可以先從兩件事下手：把隱藏狀態攤平，並把長時間或可選功能改成明確的擴充或任務。這樣最容易降低後續維運成本，也比較不會在下一版規格更新時被迫大改。