MCP（Model Context Protocol）正在從「讓模型呼叫工具」的介接格式，轉向可承載長時間代理任務、跨服務授權與企業級治理的基礎協定。官方最新路線圖將未來六至十二個月的工作集中在五個領域：代理訊息原語、HTTP 傳輸整合與強化、代理身分與安全、工具原語改善，以及 SDK 開發體驗。原始文件見 https://modelcontextprotocol.io/development/roadmap。
這不是功能清單，而是一次協定收斂
來源事實：現有 MCP 已陸續出現 Tasks、subscriptions/listen 與進度通知，分別處理非同步工作、訂閱及執行狀態。但官方承認，這些機制若各自發展，可能形成三套不同的生命週期、取消方式與錯誤介面。路線圖因此要求跨工作小組檢查它們能否組合，並加入頻道、訂閱與 webhook，讓伺服器在工作完成時主動通知客戶端，不必持續輪詢。
合理推論：MCP 面對的核心問題已不是「能不能呼叫工具」，而是「多步驟工作能否可靠地跑完」。一項代理任務可能執行數分鐘，期間需要串流結果、接受改向、被取消，甚至觸發另一個代理。如果上述狀態沒有一致語意，每套 SDK、閘道器與應用程式都得自行補上重試、逾時與錯誤映射，互通性很快就會名存實亡。
HTTP 統一背後的商業邏輯
2026 年 7 月版規格已把遠端 MCP 伺服器變成一般 HTTP 工作負載。現在官方希望更進一步，以 Streamable HTTP 作為單一模型，連本機子程序也透過標準輸入輸出承載 HTTP，並研究以 HTTP/2 取得多工能力。另一路工作則是把 ETag 納入快取設計，使工具列表、資源乃至工具結果具有可驗證的版本。
作者觀點：這項調整的價值不只在技術整潔。當遠端與本機各有一套傳輸管線，SDK 業者必須維護兩份狀態處理，伺服器也可能同時核對 HTTP 標頭與訊息欄位。若成功統一，既有 API 閘道器、負載平衡、快取及可觀測性工具便更容易介入，MCP 的商業部署成本也可能下降。不過，HTTP/2 over stdio 目前仍是路線圖方向，不能當成已定案的相容性保證。
代理身分才是企業採用的真正門檻
目前 MCP 授權主要假設使用者能在瀏覽器前同意存取；但雲端代理可能在使用者不在線時執行，也可能產生權限更小的子代理。官方因此把 DPoP、工作負載身分聯邦、ID-JAG 與 OAuth 權杖交換列為重點，希望取代貼上 API 金鑰或長期 refresh token 的做法。
IETF 的 RFC 9449 可交叉驗證 DPoP 的實際功能：客戶端以每次 HTTP 請求附帶的 JWT 證明自己持有私鑰，授權伺服器再把權杖綁定至相應公鑰，降低權杖遭竊後被其他持有者直接重播的風險。但標準也明確指出，DPoP 本身不是身分驗證或存取控制，而且仍依賴 TLS：https://datatracker.ietf.org/doc/html/rfc9449。
另一塊拼圖 RFC 8693 則定義 OAuth 2.0 權杖交換，涵蓋模擬與委派情境；服務也可將收到的權杖換成適合下游服務、範圍更窄的新權杖。這為「代理代表哪位使用者、哪個代理正在行動、可把多少權限交給子代理」提供既有標準基礎，而非由 MCP 另造一套安全體系：https://www.rfc-editor.org/rfc/rfc8693.html。
工具探索也開始面對規模問題
官方指出，tools/call 可同時回傳 content 與 structuredContent，已造成客戶端與伺服器實作分歧，因此準備重設結果結構。更值得注意的是「漸進式探索」：客戶端不再於連線時吞下完整工具與資源目錄，而是按需求發現能力，並與快取機制協同。
合理推論：當企業內部有數百個工具時，完整目錄不只增加延遲與模型上下文成本，也放大誤選工具及暴露不相關能力的機會。漸進式探索可能成為大型 MCP 平台的必要條件；但若搜尋排序、權限過濾與快取失效沒有一致語意，同一請求仍可能因不同客戶端而看到不同工具集合。
容易忽略的限制與新增風險
- 路線圖明言它反映「目前想法」，並非交付承諾；項目可能改變、延後或以不同形式實現。
- 伺服器主動推送可減少輪詢，卻也要求實作者重新處理事件驗證、重送、順序、冪等性與斷線恢復。
- DPoP 只能證明金鑰持有及限制權杖發送者，不能替代使用者授權、代理政策、稽核紀錄或私鑰保護。
- HTTP 統一可減少協定分歧，但不會自動消除本機程序、遠端服務與企業代理伺服器之間不同的信任邊界。
- 官方將符合優先領域的 SEP 列為加速審查對象；這代表路線圖同時也是有限維護資源的配置機制，而非所有社群需求都會等速前進。
對台灣團隊的實際意義
台灣企業若正在導入 MCP，不宜把單一日期版規格直接視為長期平台契約。較穩健的架構是隔離傳輸、授權與工具描述層，保留版本協商及功能旗標；長時間任務則先自行定義逾時、取消、重試與冪等規則。身分方面，應優先盤點既有 OAuth、雲端工作負載身分與金鑰管理能力，而不是為每個代理配置永久 API key。
採購 MCP 平台時，也應要求供應商說明：能否辨認「使用者、代理與子代理」三種主體；是否支援最小權限委派；事件是否可追蹤與重播；工具目錄如何依權限過濾；以及 SDK 是否通過一致性測試。真正的企業級差異，不會只在工具數量，而在事故發生後能否回答「誰以誰的名義、使用哪個權限、呼叫了什麼」。
後續觀察指標
- Tasks、Triggers 與訂閱機制是否形成共同生命週期、取消及錯誤模型。
- DPoP 與代理委派相關 SEP 是否進入正式規格，主流 SDK 是否同步支援。
- HTTP over stdio 能否證明跨平台互通，並維持本機子程序原有的安全與生命週期特性。
- 漸進式探索是否定義權限過濾、排序、ETag 與快取失效的一致行為。
- 由規格生成 SDK 的實驗能否通過一致性測試，並實際減少各語言版本落差。
MCP 這輪路線圖最重要的訊號，是它開始正面處理協定進入生產環境後才會暴露的難題：非同步狀態、身分委派、傳輸分歧與能力規模。方向合理，但完成度仍應以正式規格、SEP 狀態、SDK 支援及一致性測試為準，而不是以路線圖上的名稱判定。