MCP 2026-07-28 改了什麼？無狀態核心與企業部署指南（下）

上一篇把 MCP 放回 CLI 與 API 的分層中。本篇處理更實際的問題：2026-07-28 規格為什麼大改，以及已建置 MCP Server 的團隊現在要改什麼。

這次是底層重建

MCP 官方將核心改成無狀態（stateless）的請求／回應架構。Inside 的分析也指出，這次改版主要是為了支撐 Serverless、邊緣運算、負載平衡與生產流量，而不只是增加幾個 API。Inside 報導

1. 移除 handshake 與 session

新版移除：

• initialize / initialized
• Mcp-Session-Id
• 協定層級的 session affinity

每一筆請求都自行攜帶協定版本、Client 身分、能力與必要的 _meta。若要事先探索能力，可使用可選的 server/discover RPC。

結果是請求可以被一般的 round-robin load balancer 分配到任何 Server instance，不必共享 session storage。狀態仍然可能存在，但應由應用層以 handle 或任務 ID 管理。

2. HTTP Gateway 可以直接路由

Streamable HTTP 請求可帶上：

Mcp-Method: tools/call
Mcp-Name: search

Gateway、WAF 與服務網格不必先解析 JSON，就能依工具名稱做路由、授權、計費、稽核與流量限制。

3. MRTR 取代長連線互動

工具若執行到一半需要使用者補資料，Server 可回傳：

resultType: "input_required"

Client 取得答案後，將資料放入 inputResponses 再重送請求。這種 Multi Round-Trip Requests（MRTR）不需要持續開啟雙向串流，較適合雲端與暫態連線。

4. 工具清單可快取

tools/list、resources/list 與 prompts/list 的回應增加快取提示與確定性排序。企業可以降低重複探索成本，也能減少重新連線造成的提示快取失效。

5. OAuth 與企業身分治理強化

新版要求 Client 驗證 OAuth Authorization Server 的 iss，降低 mix-up 攻擊風險；憑證也會綁定核發它的 issuer。

DCR（Dynamic Client Registration）開始走向淘汰，長期方向改為 CIMD（Client ID Metadata Documents）。這讓 MCP 更容易接入 Entra、Okta 等企業 IdP。官方規格公告

6. Tasks 改成正式 Extension

Tasks 從核心協定移到：

io.modelcontextprotocol/tasks

長時間工作可以使用：

• tasks/get 查詢狀態。
• tasks/update 回報進度。
• 明確的 task handle 管理多次呼叫。

MCP Apps、Tasks 與 Enterprise Managed Authorization（EMA）都納入正式的 Extension framework。長任務與互動式 UI 可以獨立演進，不必每次都修改核心協定。

7. 企業需要安排的遷移

立即檢查

• 是否依賴 Mcp-Session-Id 或固定 Server instance。
• 是否仍使用舊版 HTTP+SSE transport。
• 是否依賴 Roots、Sampling、Logging。
• OAuth 是否驗證 issuer 與 resource indicator。
• 長任務是否有 handle、過期時間、權限檢查與回放紀錄。

新專案建議

1. 優先採用無狀態 HTTP。
2. 以 API Gateway 或 WAF 管理 MCP 流量。
3. 高風險工具先維持 read-only 或 draft-only。
4. 長任務採 Tasks Extension，不自行發明 session 協定。
5. 使用官方支援新規格的 TypeScript、Python、Go 或 C# SDK。

8. 無狀態不等於無治理

狀態從協定層移到應用層後，責任反而更清楚。企業必須自己管理：

• handle 與 task 的生命週期。
• 每位使用者的資料隔離。
• 工具白名單與最小權限。
• 人工審批與不可逆操作確認。
• 每次工具呼叫的 audit log。
• 失敗時的停止、轉人工與回滾路徑。

MCP 能讓 AI 使用工具，但不會自動替企業完成授權、稽核與風險治理。

9. MCP 接下來的改革方向

2026-08-22 發布的官方路線圖，將後續工作集中在五個方向：

• Agentic messaging primitives。
• HTTP-native transport 的統一與強化。
• Agent identity 與企業級安全。
• 更完整的工具與任務原語。
• 更好的 SDK 開發體驗與治理流程。

官方也建立 Contributor Ladder、Working Groups 與正式 feature lifecycle，代表 MCP 正從快速成長的協定，走向有版本治理與企業採用規範的基礎設施。官方路線圖

結論：先保留 API，再增加 AI 工具層

MCP 的正確落地方式不是把現有 API 全部改掉，而是：

既有 API / CLI
      ↓
MCP Server 工具層
      ↓
AI Agent + 權限 + 稽核 + 人工審批

2026-07-28 之後，MCP 更容易部署與擴充；同時，狀態、權限與復原責任也更明確地回到應用與企業治理層。

來源

• MCP 官方：2026-07-28 Specification，2026-07-28。
• MCP 官方：2026-07-28 Changelog，2026-07-28。
• MCP 官方：New MCP Roadmap，2026-08-22。
• INSIDE：MCP 新版規格上線，2026-07-30。

---

相關推薦與延伸閱讀

• AI Agent 進入 Production 前，FDE 要先建好控制面：企業 AI Agent 的關鍵不是 demo，而是把權限、成本、觀測、評估與人工升級，做成可營運的控制面。本文從三個近期訊號說明權限、成本與安全為何要一起設計，
• MCP、API、CLI 差在哪？AI 系統介面的 2026 白話指南（上）：用實際工作流拆解 CLI、API 與 MCP 的角色差異，說明為什麼 MCP 不是 API 的替代品，以及企業該如何選擇正確介面。本文以一張表比較三種介面，說明
• 台灣企業導入 AI Agent：真正要算的不是 token，而是工作流成本：AI Agent 正從聊天工具進入企業工作流。評論台灣 B2B 與製造業導入時，為什麼要先規劃成本與權限、釐清資料的業務脈絡，並訂定可驗證的成果。文中整理報價彙