MCP 進企業：用閘道、角色與新版規格治理 agent 的工具

MCP 已經是 agent 接工具最普遍的共同介面，而 2026 年 7 月 28 日發布的新版規格，把它往企業部署推了一大步。這一版移除了 initialize 握手與 Mcp-Session-Id，改為無狀態核心：每個請求在 _meta 裡帶上協定版本、client 身分與能力，任何請求都可以落在負載平衡器後的任一實例上，不需要共用儲存。需要跨呼叫保留狀態的 server，被建議明確發給模型一個 handle 讓它帶回來。

對閘道最直接的影響是 header。新版要求 Streamable HTTP 請求攜帶 Mcp-Method 與 Mcp-Name header，閘道、限流器與 WAF 因此可以不解析請求內容，就依「呼叫的是哪個方法、哪個工具」做路由、計量與授權。過去要在閘道上對 MCP 做細緻管控，往往得解開 JSON-RPC 的內容；現在可以在 header 層完成，對既有的 API 閘道與觀測工具友善得多。

授權部分也收緊了。Server 應依 RFC 9207 回傳 iss 參數，client 必須在兌換授權碼前驗證；client 憑證綁定到發出它的授權伺服器；Dynamic Client Registration 正式棄用，改用 Client ID Metadata Documents（CIMD）。新版也建立正式的 extensions 框架，並對破壞性變更設定 12 個月的棄用期。治理面上，MCP 與 A2A 都已在 Linux Foundation 旗下的 Agentic AI Foundation 之中，由中立組織維護。

企業接入 MCP 時，最重要的觀念轉換是：每一個 MCP server 都是一組會被 agent 自動呼叫的能力，應該像 API 一樣盤點與治理。實務上可以從五件事開始：建立工具清冊，記下每個 server 由誰提供、能讀寫什麼；依角色開放工具，而不是對所有人全開；記錄每一次工具呼叫的身分、參數與結果；把寫入型與對外型工具放到人工核准之後；升級規格版本前，用回歸測試確認既有工具在新協定下仍能運作。

X Cube 在這兩個方向都有實作。作為 MCP server，X Cube 在 /mcp 對外提供 chat 與 list_models 兩個工具；作為 MCP client，X Cube 以 Streamable HTTP 連接外部 MCP server，並透過 connector registry 管理這些連線，管理員可以設定每個 connector 開放給哪些角色、在後台測試呼叫。這讓企業可以把 MCP 工具納入既有的身分與權限體系，而不是讓每個 agent 各自連線。

接下來值得觀察的有三點：主要 MCP client 與 server 實作多快跟上無狀態核心與新的授權要求；閘道與觀測工具是否開始原生解讀 Mcp-Method 與 Mcp-Name；以及 Agentic AI Foundation 底下的協定，會不會在身分、授權與稽核上收斂出共同做法。對企業來說，現在就以 header 層的路由與記錄為目標設計閘道，可以少走一次改架構的路。