負責維護 MCP（Model Context Protocol）的核心維護者，於 2026 年 8 月 22 日公布了新版路線圖。MCP 是連接 AI 應用與外部工具的開放標準，這份路線圖把下一版規格及後續要處理的事項整理成 5 個重點領域，其中超出單次工具呼叫的長時間處理，以及代理如何證明自己的身分，都排在前面。
起點是 7 月那次拿掉工作階段的大改版
這份路線圖的前提，是上一輪工作剛剛告一段落。前一版在 2026 年 3 月推出，列出傳輸層的演進與擴充性、代理之間的通訊、治理的成熟化，以及企業導入的整備 4 個重點，其中大部分已經落在 2026 年 7 月 28 日的規格版本裡。
影響最大的，是拿掉了協定層的工作階段與初始化交握。伺服器不必再保有狀態，因此可以直接水平擴充。用戶端連上之後不必馬上進入正題，可以先呼叫 server/discover，確認伺服器支援哪些版本與功能。清單類請求的結果也變得可以快取。
在代理通訊這一側，Tasks 依照早期採用者的回饋重新設計，移到官方擴充功能的位置。原本由伺服器主動送出請求的機制，則由全新的 Multi Round-Trip Requests 模式取代。這項變更是為了讓需要多次往返的流程，在無狀態的伺服器上也能成立。
治理結構同樣定型。以階梯呈現貢獻者角色的 Contributor Ladder 正式採用，各工作小組開始分揀自己領域內的規格改進提案，功能的生命週期與淘汰程序也有了明文政策。7 月版本中被淘汰的項目，正是最先套用該政策的案例。
會讓人等待的代理，需要為等待而設計的零件
新路線圖的第一個重點領域，是代理專用的訊息傳遞基礎。現在代理的工作方式，已經裝不進送出請求、收到回覆這種單純的形狀。迴圈會跑得更久，伺服器會推送中途結果，有時還想對執行中的處理從旁調整方向。
MCP 為此陸續補上 Tasks、subscriptions/listen 與進度通知等零件。路線圖追問的並不是零件夠不夠，而是它們彼此能不能咬合。列出的工作包含由伺服器端觸發的事件，也就是導入 Webhook 與頻道，讓用戶端不必為了取得結果而反覆詢問。同時，Agents、Transports、Triggers & Events 各工作小組會跨組檢視這些零件的組合方式。把還停留在擴充功能階段的 Tasks 提升進規格本體，也列入目標。
也想讓本機的伺服器用 HTTP 說話
第二個重點是傳輸方式的統一。經過 7 月的變更，遠端 MCP 伺服器已經和一般的 HTTP 工作負載沒有差別，可以直接放在開發者與組織原本就用來跑 API 和服務的基礎架構上。這套做法在規模上已經證明可行，因此維護者想把它延伸到其他運作型態。
被點名的是在本機執行的伺服器，方向是讓它們在標準輸入輸出之上使用 Streamable HTTP。本機與遠端不必再各自維護一套傳輸方式的話，伺服器與用戶端的實作會更單純。
已經沒有人在旁邊按同意了
第三個重點是代理身分與企業級安全，起因是現行授權設計的前提正在鬆動。目前 MCP 的授權，是以人在瀏覽器裡核准存取為中心設計的。這對互動式用戶端很合適，但呼叫端愈來愈常是雲端上的工作負載，擁有自己的身分，代替不在場的使用者行動，還要把範圍更小的權限交給下層代理。
維護者想達成的，是讓伺服器以既有標準辨識並信任這些代理身分，而不是依賴貼上去的 API 金鑰與長期有效的權杖。工作項目包括：完成把存取權杖綁定到金鑰的 Demonstrating Proof of Possession（DPoP）並推動普及；結合 Workload Identity Federation、企業級授權背後使用的 ID-JAG 授權方式，以及標準的權杖交換，訂出身分與委派的建議路徑。與 IETF 的 OAuth 工作小組及 WIMSE 的往來也會持續。
不在使用者提問前就把 100 個工具全攤開
第四個重點是基本功能本身的改善。工具呼叫是開發者接觸 MCP 時最先用到的部分，一直沒出大問題，比較單薄的是結果的處理。tools/call 的回應可以用多種形式承載同一份內容，而伺服器開發者無從得知眼前的用戶端會把哪一種形式送到模型面前。這裡的方針是收斂成一份明確的約定。
另一個課題是規模。連上一台公開 100 個工具的伺服器，代表使用者還沒問任何問題，模型就得先讀完整份清單；而且清單愈長，該挑哪一個的判斷就愈鈍。因此將啟動漸進式揭露的工作：先只給出一個小入口，隨著對話聚焦再逐步展開其餘的目錄。
SDK 要以代理會來閱讀為前提來整理
第五個重點是 SDK 的開發者體驗。對許多開發者來說，SDK 幾乎就等於 MCP 本身。維護者表示會在易用性、與規格的一致性，以及所支援各語言與各平台文件的正確度上持續投入。
理由很有現在的味道：愈來愈多開發者是把函式庫交給代理去讀，由它寫出 MCP 用戶端與伺服器，於是 API 夠不夠清楚、文件正不正確，直接決定產出的程式碼能不能跑。
提案能不能過的門檻變了
路線圖也直接牽動哪些提案會被優先審查。落在這 5 個重點領域內的規格改進提案（SEP），審查會走快速通道，被採納的機會也比較高。領域之外的提案不會自動被否決，但路線圖明白寫出，維護者的時間有限，會優先分配給這些重點領域。
對於正在考慮提案的人，建議先判斷自己的想法屬於哪個重點領域，帶到對應的工作小組，與小組成員一起把提案打磨成形。每個領域都寫明了負責的核心維護者。
總結
7 月的規格修訂讓 MCP 更接近一個不保存狀態的一般 HTTP 服務，而這份路線圖給出了在這個基礎上的下一步：整理長時間處理所需的零件、把傳輸方式統一到含本機在內、以無人可核准為前提驗證代理身分、用漸進式揭露讓工具變多之後仍挑得準，以及 SDK 的品質，共 5 項。它們的共同點，是一點一點拆掉有人在旁邊看著這個前提，而這與把代理放進正式環境的團隊真正在意的事情高度重疊。
來源: https://blog.modelcontextprotocol.io/posts/mcp-roadmap/
