MCP 2026-07-28 規格更新：無狀態協定、MRTR 與開發者遷移指南

MCP 2026-07-28 規格更新：無狀態協定、MRTR 與開發者遷移指南

<

p class=”wp-block-paragraph”>MCP 2026-07-28 是 Model Context Protocol 推出以來規模最大的底層改版。新版移除 initialize／initialized 握手與 Mcp-Session-Id，讓每個請求自行攜帶協定版本、客戶端資訊與能力，使 MCP Server 能直接部署在一般 Round-robin Load Balancer 後方。

這次更新也重新設計伺服器向客戶端索取資料的方式，加入 Multi Round-Trip Requests、Header 路由、結果快取、正式擴充框架與更嚴格的 OAuth 驗證。對開發者而言，2026-07-28 已經不是增加幾個欄位的小改版，而是一次 Transport、State、Authorization 與 Server Architecture 的共同遷移。

• MCP 核心改為無狀態，每個請求都包含自身所需的版本、身份與能力資訊。
• initialize 握手與 Mcp-Session-Id 已移除，Server 不再需要依賴 Sticky Session。
• server/discover 成為 Server 必須提供的能力探索 RPC，但 Client 可以選擇是否預先呼叫。
• MRTR 透過 input_required 結果與重送原始請求，取代依賴長時間雙向串流的 Server-to-client Request。
• Mcp-Method、Mcp-Name、ttlMs 與 cacheScope 讓 Gateway、WAF、快取與 Prompt Cache 更容易管理。
• Roots、Sampling、Logging 與舊式 HTTP+SSE 已進入棄用期，但至少會保留十二個月。

文章實體化：MCP 2026-07-28 規格更新：無狀態協定、MRTR 與開發者遷移指南

MCP規格更新要區分協定語意、傳輸狀態、MRTR與開發者遷移，讀者才知道哪些是架構改變、哪些是實作相容性問題。

• MCP：模型上下文協定與工具、資源、提示之間的介面
• 2026年7月28日規格更新：版本與時間節點
• 無狀態協定：影響伺服器如何保存工作階段與請求狀態
• MRTR：規格中需要對照的技術術語與傳輸／路由脈絡
• 開發者遷移指南：將規格變化落到相容性、測試與部署步驟

本文以「MCP 2026-07-28 規格更新：無狀態協定、MRTR 與開發者遷移指南」為主線，補回人物、組織、作品、技術節點、時間、場景與它們之間的關係，讓讀者能從具名實體一路追到文本、實際流程、文化語境與影響。

MCP 為什麼要改成無狀態協定

舊版 MCP 的 Streamable HTTP 流程需要先執行 initialize。Server 建立 Session 後回傳 Mcp-Session-Id，Client 後續的請求都必須攜帶這個 ID。

這種設計在單一 Server 上容易理解，但當系統需要水平擴展時，基礎設施必須確保相同 Client 持續連到同一個 Instance，或讓所有 Instance 共用 Session Store。負載平衡器需要 Sticky Session，Server 也必須管理 Session 過期、重連與同步。

MCP 2026-07-28 移除了這個協定層 Session。每個請求現在都會在 _meta 中攜帶協定版本、Client Capabilities 與 Client Info，任何相容的 Server Instance 都能獨立處理請求。

舊版流程大致如下：

POST /mcp HTTP/1.1
Content-Type: application/json
{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "initialize",
  "params": {
    "protocolVersion": "2025-11-25",
    "capabilities": {},
    "clientInfo": {
      "name": "my-app",
      "version": "1.0"
    }
  }
}

Server 回傳 Session ID 後，後續請求綁定該 Session：

POST /mcp HTTP/1.1
Mcp-Session-Id: 1868a90c-3a3f-4f5b
Content-Type: application/json

新版請求則可以直接送出：

POST /mcp HTTP/1.1
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: search
Content-Type: application/json
{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/call",
  "params": {
    "name": "search",
    "arguments": {
      "q": "otters"
    },
    "_meta": {
      "io.modelcontextprotocol/clientInfo": {
        "name": "my-app",
        "version": "1.0"
      }
    }
  }
}

新版規格要求每個請求自行描述協定版本與 Client Capabilities。Client Info 屬於建議攜帶資訊，Server 也應在結果的 _meta 中提供自身身份。

無狀態協定不代表應用程式不能保存狀態

移除 Mcp-Session-Id 不代表購物車、瀏覽器工作階段、長任務或資料處理流程不能保存狀態。

新版建議 Server 明確建立可傳遞的 Handle，例如：

• browser_id
• workspace_id
• basket_id
• task_id
• upload_id

Tool 第一次呼叫時回傳 Handle，Model 或 Client 在下一次呼叫中把 Handle 當成一般參數傳回。狀態因此成為 Tool Contract 的一部分，不再隱藏於 Transport Session 中。

這種模式也讓 Agent 能在不同 Tool 之間傳遞、儲存與檢查 Handle。Server 必須自行處理 Handle 的權限、租戶範圍、過期時間與撤銷機制，不能把一串可猜測的 ID 當成完整授權。

server/discover 如何取代初始化握手

MCP 2026-07-28 新增 server/discover RPC。Server 必須實作這個方法，回傳支援的協定版本、身份與能力；Client 可以在第一個正式請求前呼叫，也可以直接送出自我描述的請求。

這裡有一個容易誤讀的差異：

• Server 必須支援 server/discover。
• Client 不必每次都先呼叫 server/discover。
• Client 可以使用它進行版本選擇與相容性偵測。
• 舊版 Server 仍可能需要退回 initialize 流程。

因此，Client SDK 需要同時處理新版探索流程與舊版握手，避免所有 Server 必須在同一天完成升級。

MRTR 如何處理中途確認與補充資料

MCP Tool 在執行途中經常需要更多資訊，例如：

• 要求使用者確認刪除檔案。
• 補充缺少的日期或收件人。
• 選擇付款方式。
• 完成外部 OAuth 授權。
• 核准高風險操作。

舊版可以透過 Server-initiated Request，在保持開啟的 Stream 上呼叫 elicitation/create、sampling/createMessage 或 roots/list。

無狀態核心不再依賴持續存在的雙向 Stream。Multi Round-Trip Requests（MRTR）改為讓 Server 暫停目前工作，回傳 resultType: "input_required"：

{
  "resultType": "input_required",
  "inputRequests": {
    "confirm": {
      "type": "elicitation",
      "message": "確定要刪除 3 個檔案嗎？",
      "schema": {
        "type": "boolean"
      }
    }
  },
  "requestState": "opaque-server-state"
}

Client 收集使用者答案後，重新送出原始 Tool Call，並附上 inputResponses 與 Server 提供的 requestState。由於完整上下文都存在請求中，重送請求可以由另一個 Server Instance 接手。

新版也要求所有結果包含 resultType：

• complete：一般完成結果。
• input_required：需要 Client 補充資料。

相容舊版協定的 Client 遇到沒有 resultType 的結果時，應將其視為 complete。

Header 路由讓 Gateway 不必解析 JSON Body

Streamable HTTP 的 POST 請求現在必須包含：

• Mcp-Method
• Mcp-Name
• MCP-Protocol-Version

例如 tools/call 搭配 search Tool 時，Gateway 可以直接從 Header 判斷請求類型與 Tool 名稱，不必先解析 JSON-RPC Body。規格也要求 Server 檢查 Header 與 Body 是否一致。

這項改動直接影響以下基礎設施：

• API Gateway 路由
• Tool 級 Rate Limit
• WAF 規則
• 權限政策
• 成本計量
• Audit Log
• OpenTelemetry Trace

企業可以針對 tools/call、特定 Tool 名稱或協定版本建立不同的限制，而不必讓 Gateway 理解完整 MCP Payload。

Tool Catalog 與 Resource 結果可以快取

tools/list、prompts/list、resources/list、resources/read 與 resources/templates/list 的結果，現在必須包含：

• ttlMs
• cacheScope

ttlMs 告訴 Client 結果可以維持新鮮多久；cacheScope 則區分結果可否由共享中介快取，值為 public 或 private。Server 也應以固定順序回傳 Tool，避免每次重新連線時因排序變化破壞上游 Prompt Cache。

這項功能對 Tool 數量龐大的 Agent 平台尤其重要。Tool Catalog 不必在每次任務開始時重新抓取，穩定排序也能減少相同 Tool 定義產生不同 Prompt 的情況。

快取仍須遵守租戶與使用者權限。含有個人權限、企業內部 Tool 或動態 Resource 的結果，通常應使用 private，不能只為降低請求量而放進共享 Cache。

OAuth 授權有哪些安全變更

授權是 MCP Server 導入時最容易出現互通問題的部分。2026-07-28 主要調整四個方向。

驗證 Authorization Server Issuer

Authorization Server 應依 RFC 9207 在授權回應中加入 iss。Client 收到 iss 後，必須確認它和先前記錄的 Issuer 一致，再交換 Authorization Code。

這可以降低 Authorization Server Mix-up Attack。當一個 MCP Client 同時連接多個 Server 與授權服務時，Issuer 驗證尤其重要。

Dynamic Client Registration 必須標明應用類型

Client 使用 Dynamic Client Registration 時，必須提供適當的 application_type。

Desktop 與 CLI App 若被錯誤判定為 Web App，Authorization Server 可能拒絕 localhost Redirect URI。新版讓 SDK 與 Client 更明確地區分 Native App 和 Web App。

Client Credentials 必須綁定 Issuer

Client 保存的 Registration 與 Credentials 必須以 Authorization Server Issuer 為索引，不能把同一組 Client Credentials 重複用在另一個 Authorization Server。

當 Resource Server 更換 Authorization Server 時，Client 應重新註冊，不能只替換 Token Endpoint。

DCR 開始讓位給 Client ID Metadata Documents

Dynamic Client Registration 已正式進入棄用方向，未來標準將轉向 Client ID Metadata Documents。DCR 目前仍保留相容性，但新 Client 與 Authorization Server 應開始規劃 CIMD 支援。

Tasks 為什麼移出核心協定

Tasks 在 2025-11-25 中屬於實驗性核心功能。新版將它移到正式擴充：

io.modelcontextprotocol/tasks

新的 Tasks Lifecycle 以 Polling 與明確 Handle 為中心：

• tasks/get
• tasks/update
• tasks/cancel

舊有的 Blocking tasks/result 被移除，tasks/list 也因缺少 Session 範圍而取消。Server 可以在 Tool Call 中直接回傳 Task Handle，Client 再依 Handle 查詢進度或補充輸入。

已使用 2025-11-25 實驗 Tasks API 的專案，不能只更改版本字串。舊版和新版的 API 與 Wire Format 並不相容，需要重新設計任務建立、查詢、更新與取消流程。

擴充框架解決核心規格過度膨脹

2026-07-28 正式建立 Extensions Framework。擴充功能使用 Reverse-DNS ID，在 Client 與 Server Capabilities 的 extensions Map 中協商，並可以擁有獨立版本與維護團隊。

目前重要方向包括：

• Tasks：長時間執行與可恢復任務。
• MCP Apps：在對話中呈現互動式 UI。
• Enterprise 授權與組織管理能力。
• Skills 與結構化 Agent Instructions。

這套設計讓新功能可以先以 Opt-in Extension 發展，不必持續把所有能力塞進核心協定。Client 沒有宣告支援時，Server 也不能假設擴充功能存在。

哪些 MCP 功能已經進入棄用期

Roots、Sampling 與 Logging 在目前版本仍能使用。正式的生命週期政策要求，從標記 Deprecated 到最早移除日期之間，至少保留十二個月。新實作不應再依賴這些功能，既有專案則可以在保留期內安排遷移。

Tier 1 SDK 更新到哪些版本

升級 SDK 前應先閱讀各語言的 Migration Guide。這次改版同時改變 Transport、Request Lifecycle、Tasks、Authorization 與部分 API 名稱，直接更新 Dependency Version 很可能造成編譯或執行錯誤。

開發者遷移清單

1. 搜尋所有 Session 相依程式

檢查程式碼、Gateway、Database 與 Log 中是否使用：

initialize
notifications/initialized
Mcp-Session-Id
Last-Event-ID
resources/subscribe
resources/unsubscribe

這些功能可能已移除、改版或只適用於舊協定。

2. 將隱藏狀態改成明確 Handle

任何跨 Tool Call 保存的 State，都應定義 Handle 格式、所屬 User 與 Tenant、過期時間、撤銷方式、重試條件，以及是否能跨 Server Instance 使用。

3. 實作 server/discover

Server 必須回傳支援版本、Server Info 與 Capabilities。Client 需要處理新版 Discovery 成功、舊版 Server 不支援 Discovery、協定版本不相容，以及自動降級或明確拒絕等情況。

4. 更新所有 Tool Result

所有新版結果都需要 resultType。一般結果使用 complete，中途需要輸入時使用 input_required。

5. 將 Server-initiated Request 改成 MRTR

1. Server 回傳 Input Required。
2. Client 收集輸入。
3. Client 重送原始請求。
4. Server 驗證 requestState。
5. Server 繼續執行。

6. 加入標準 Header

Streamable HTTP Request 必須帶上正確的 Mcp-Method 與 Mcp-Name，Server 應驗證 Header 和 JSON-RPC Body 一致。

7. 為 List Result 設計快取策略

設定合理的 ttlMs、cacheScope、固定排序、權限隔離與 listChanged Notification。

8. 更新 OAuth Storage Schema

Client Registration 與 Credentials 應以 Issuer 作為索引，並加入 iss 驗證與 application_type。

9. 建立棄用功能退出計畫

盤點 Roots、Sampling、Logging 與 HTTP+SSE 的使用位置，決定替代方案與完成日期。

10. 同時測試新版與舊版 Peer

• 新 Client 對新 Server
• 新 Client 對舊 Server
• 舊 Client 對新 Server
• MRTR 重送
• Server Instance 切換
• OAuth Issuer 不一致
• Cache 過期與權限隔離
• Gateway Header Mismatch

對台灣開發團隊的實際影響

台灣許多 MCP 專案目前仍停留在單機開發、stdio 或單一 HTTP Server。這些專案短期內可能感受不到 Sticky Session 的成本，但只要服務開始進入 Kubernetes、Serverless、Multi-region 或企業 API Gateway，無狀態核心就會直接降低部署複雜度。

更重要的改變是責任變得清楚。State、Authorization、Task Handle、Cache Scope 與 User Confirmation 都必須成為可見的 Application Contract，不能再依賴某條連線仍然存在。

對內部 Agent 平台而言，這有利於建立統一 Gateway、Tool 權限與 Audit。對 SaaS MCP Server 而言，新的 Header、Issuer Binding 與 Private Cache Scope 也提供更明確的多租戶治理基礎。

遷移成本主要集中在早期採用者。已深度使用 Session ID、Sampling、Roots 或實驗 Tasks API 的專案，需要重新檢查架構；只使用簡單 stdio Tools 的 Server，改動通常會小得多。

第一次接觸 MCP 的讀者，可先閱讀站內核心指南：MCP 是什麼？Host、Client、Server、Tools 與 Transport 完整架構。需要把協定放進完整工作流時，也可延伸閱讀AI Agent 工作流怎麼設計？從任務契約到驗證的七層架構。

常見問題

MCP 2026-07-28 已經是正式規格嗎？

是。官方已上線 2026-07-28 正式規格與相對於 2025-11-25 的變更清單。TypeScript、Python、Go 與 C# SDK 也已推出支援版本。

無狀態 MCP Server 完全不能保存資料嗎？

可以保存。新版移除的是協定層 Session。Server 仍能使用資料庫、Cache 或 Durable Storage，但應回傳明確 Handle，並要求 Client 在後續 Tool Call 中帶回。

所有 Client 都必須先呼叫 server/discover 嗎？

不必。Server 必須實作 server/discover，Client 可以用它預先探索能力，也可以直接送出包含版本與 Capabilities 的自我描述請求。

MRTR 是否完全不使用 Stream？

MRTR 的補充輸入流程不需要長時間保持雙向 Stream。Server 回傳 input_required 後結束目前 Round Trip，Client 收集答案並重送原始請求。其他通知仍可能使用明確訂閱的 Stream。

Roots、Sampling 和 Logging 現在會立刻失效嗎？

不會。它們已被標記為 Deprecated，但仍可在棄用期間使用。依正式政策，最早移除時間至少在標記棄用後十二個月，新專案不應再採用。

現有 MCP Server 是否需要立即升級？

公開服務與多人共用 Server 應優先評估，尤其是依賴 Session、OAuth 或 Tasks 的系統。單機 stdio Tool 可以先更新測試環境，確認 Host 與 SDK 相容後再切換正式版本。

MCP 正在成為真正的基礎設施協定

MCP 最早解決的是 LLM 如何以共同格式連接 Tools、Resources 與 Prompts。2026-07-28 開始處理更接近生產環境的問題：Server 如何擴展、Gateway 如何路由、Cache 如何隔離、OAuth 如何辨認 Issuer，以及長任務如何在中途中斷和恢復。

這次更新把每個 Request 變成可獨立理解、授權、追蹤與重試的協定單位。它降低了 Transport 對隱藏狀態的依賴，也把更多責任交還給 Application Contract。

對開發者而言，最重要的工作不是立刻更換版本號，而是找出系統目前在哪些地方依賴 Session、雙向 Stream、隱藏狀態與舊式授權流程。這些位置才是 MCP 2026-07-28 真正要求重新設計的部分。

若要把 MCP 2026-07-28 的無狀態傳輸、Tasks 與擴充框架，接到其中 MCP Apps 如何提供互動 UI、UI Resource 與 sandbox 邊界，可延伸閱讀 MCP Apps 是什麼？互動 UI、Tool、UI Resource、Sandbox 與實作指南，補上同一實體脈絡的延伸閱讀。

參考資料

• Model Context Protocol Specification 2026-07-28
• MCP 2026-07-28 Changelog
• MCP 2026-07-28 Release Candidate
• MCP TypeScript SDK v2
• MCP Python SDK Releases
• MCP Go SDK v1.7.0
• MCP C# SDK Releases

以 MCP 官方規格頁作為遷移依據

Model Context Protocol 的官方 Specification 頁是這次規格版本與後續修訂的權威入口。本文補上直接連結，讓開發者能回到規格原文確認協定要求、變更紀錄與實作細節，而不是把文章摘要當成最終依據。

新增圖像取自官方文件的公開分享素材，並連回對應規格頁。對於持續更新的技術標準，這條路徑比靜態轉述更有用：讀者可在實作前自行確認當前文件狀態。