前言¶

Model Context Protocol（MCP）是 Anthropic 發起、社區共同維護的開放協議，用來讓 AI Agent 以統一方式連接外部工具、數據源與交互界面。自 2024 年底發佈以來，MCP 迅速成爲 Agent 工具鏈的事實標準——官方 Tier 1 SDK（TypeScript、Python 等）每月下載量已接近五億次，TypeScript 與 Python SDK 累計下載均突破十億。

2026 年 7 月 28 日，MCP 官方正式發佈 2026-07-28 版規範。這是協議自誕生以來最大的一次修訂：協議核心從「雙向有狀態」全面轉向 request/response 無狀態模型，移除了 initialize/initialized 握手與 Mcp-Session-Id 會話頭，Remote MCP Server 終於可以像普通 HTTP 服務一樣掛在負載均衡後面水平擴展。

本文基於 MCP 官方博客 與 Release Candidate 說明，梳理這次改動的核心機制、對部署架構的影響，以及開發者需要關注的遷移要點。

爲什麼需要無狀態¶

在 2025-11-25 版規範中，通過 Streamable HTTP 調用 Remote MCP 工具，需要先建立會話。客戶端發送 initialize，服務端返回 Mcp-Session-Id，後續每個請求都必須攜帶這個 ID，把客戶端「釘」在簽發會話的那臺實例上。

對單機部署來說，這套流程沒問題。但一旦把 MCP Server 放到負載均衡後面做水平擴展，麻煩就來了：

1. 必須配置 sticky session（會話親和），否則後續請求可能落到沒有會話狀態的實例上；
2. 或者維護 共享 Session Store（Redis 等），增加運維複雜度；
3. 網關在路由、限流、鑑權時往往要 深度解析 JSON-RPC 請求體，性能與實現成本都不低。

這正是社區開發者反饋最多的痛點之一。2026-07-28 版規範用六個 SEP（Specification Enhancement Proposal）協同完成無狀態改造，完成了 2025 年 12 月《The Future of MCP Transports》中提出的路線圖。

核心變化：每個請求自描述¶

握手與會話頭被移除¶

以下兩項在 2026-07-28 版中正式退役（參見 SEP-2575、SEP-2567）：

• initialize / initialized 握手交換
• Mcp-Session-Id HTTP 頭及協議層會話

協議版本、客戶端身份、客戶端能力等信息，改爲隨 每個請求 攜帶，放在 JSON-RPC 參數的 _meta 字段裏。如果客戶端想提前瞭解服務端能力，可以調用新增的 server/discover RPC——但這是可選的，不調用也能直接發起工具調用。

請求對比¶

2025-11-25：先握手，再帶 Session ID 調工具

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"}}}

服務端響應 Mcp-Session-Id: 1868a90c-3a3f-4f5b，後續請求必須帶上：

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

{"jsonrpc":"2.0","id":2,"method":"tools/call",
 "params":{"name":"search","arguments":{"q":"otters"}}}

2026-07-28：單次自包含請求，任意實例可處理

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"}}}}

關鍵差異一目瞭然：沒有握手、沒有 Session ID，任意請求可以落到負載均衡後面任意一臺實例，不再需要 sticky routing 或共享存儲。

協議無狀態，應用仍可有狀態¶

移除協議層會話，並不意味着你的 MCP Server 不能做有狀態業務。官方推薦的做法與 HTTP API 一致：由工具顯式 mint 一個 handle（如 basket_id、browser_id），讓模型在後續調用中作爲普通參數傳回。

官方認爲，這種「模型可見、可推理、可跨工具傳遞」的顯式 handle，往往比藏在傳輸層 metadata 裏的會話狀態更靈活——模型可以把 handle 在不同工具步驟之間串聯起來。

MRTR：無狀態下的服務端交互¶

無狀態協議面臨一個經典問題：工具執行到一半，服務端需要向用戶確認（elicitation）或請求採樣（sampling），怎麼辦？舊版依賴保持打開的 SSE 雙向流；新版引入 Multi Round-Trip Requests（MRTR，SEP-2322） 解決。

流程如下：

1. 客戶端發起 tools/call；
2. 服務端返回 resultType: "input_required"，附帶 inputRequests（需要用戶回答的問題）和 requestState（服務端狀態的編碼）；
3. 客戶端收集用戶輸入後，重新發起原始調用，在參數中附上 inputResponses 與 echo 回來的 requestState；
4. 任意服務端實例都能處理這次重試，因爲所需上下文全在 payload 裏。

示例響應：

{
  "resultType": "input_required",
  "inputRequests": {
    "confirm": {
      "type": "elicitation",
      "message": "Delete 3 files?",
      "schema": { "type": "boolean" }
    }
  },
  "requestState": "eyJzdGVwIjoxLCJmaWxlcyI6WyJhIiwiYiIsImMiXX0="
}

同時，SEP-2260 規定服務端只能在 正在處理客戶端請求期間 發起 server-to-client 請求，用戶不會被「無緣無故」彈窗打斷——每一次交互都能追溯到用戶或 Agent 主動發起的操作。

MRTR 替代了原先需要長連接的 elicitation/create、sampling/createMessage、roots/list 等 server-initiated 請求，使 elicitation 等交互能力在無狀態 HTTP 上傳輸成爲可能。Supabase 等已在生產環境運行的 stateless MCP Server 正是因此才能落地「刪除數據前確認」這類場景。

基於 Header 的路由與可緩存列表¶

Mcp-Method 與 Mcp-Name¶

Streamable HTTP 傳輸現在 必須 攜帶 Mcp-Method 和 Mcp-Name 兩個 HTTP 頭（SEP-2243）。方法名（如 tools/call）和工具/資源名（如 search）同時出現在 Header 與 JSON body 中；若兩者不一致，服務端應拒絕請求。

這意味着負載均衡器、API 網關、WAF、限流器可以直接基於 Header 做路由與策略，無需先解析 JSON-RPC body。例如：

• 對 Mcp-Name: expensive-query 路由到專用後端；
• 對特定工具做 per-tool 限流或鑑權；
• 在基礎設施層統一計量 MCP 流量。

ttlMs 與 cacheScope¶

tools/list、prompts/list、resources/list、resources/read 的響應現在攜帶 ttlMs 和 cacheScope（SEP-2549），語義類似 HTTP 的 Cache-Control。客戶端可以據此決定工具目錄緩存多久、是否可跨用戶共享，減少每次重連都重新拉取 catalog 的開銷，同時保持上游 prompt cache 在 reconnect 之間的穩定性。

此外，W3C Trace Context（traceparent、tracestate、baggage）在 _meta 中的鍵名已在規範中固定（SEP-414），便於跨 SDK、網關與下游服務的分佈式追蹤關聯。

同期重要變更一覽¶

2026-07-28 版不止是無狀態改造，還包含多項與生產落地密切相關的變更：

SDK 與生態¶

官方 Tier 1 SDK（TypeScript、Python、Go、C#）已同步支持 2026-07-28 版規範，Rust SDK 處於 beta。各 SDK 均提供 breaking changes 的遷移說明。

雲廠商與工具鏈夥伴也在發佈日即宣佈支持，包括 AWS Bedrock AgentCore、Cloudflare Workers、Google Cloud、Microsoft Foundry、Netlify 等。FastMCP 4.0、Manufact 的 mcp-use 等社區框架也報告了因 client-server 拆分帶來的包體積與性能收益。

對於依賴 Mcp-Session-Id 做路由或狀態管理的現有實現，遷移成本確實存在，但官方在 SDK beta 階段已根據早期測試反饋做了簡化。

開發者遷移建議¶

如果你正在維護 Remote MCP Server 或集成 MCP Client，可按以下步驟評估遷移：

1. 檢查 Session 依賴：搜索代碼中對 initialize、Mcp-Session-Id 的引用；若僅用於協議握手，直接移除；若用於業務狀態，改爲顯式 handle 模式。
2. 補充 HTTP Header：Streamable HTTP 請求加上 Mcp-Method、Mcp-Name，並確保與 body 一致。
3. 處理 MRTR 流程：若工具需要用戶確認，實現 input_required → 收集輸入 → 帶 inputResponses 重試的客戶端邏輯。
4. 利用緩存 hint：讀取 tools/list 等響應中的 ttlMs，避免無謂的 catalog 刷新。
5. 關注棄用項：新實現不要再採用 Roots、Sampling、Logging 及 legacy HTTP+SSE 傳輸；OAuth 集成逐步從 DCR 轉向 CIMD。
6. 閱讀 SDK 遷移筆記：TypeScript / Python / Go / C# 各 SDK 倉庫均有針對 2026-07-28 的 breaking change 說明。

規範全文與 changelog 可在 MCP 規範倉庫 查閱；實現問題可通過 contributor Discord 的 Working Group 頻道快速獲得解答。

小結¶

MCP 2026-07-28 把 Remote MCP Server 從「需要特殊會話管理的協議」變成了「標準無狀態 HTTP 工作負載」。負載均衡、Header 路由、響應緩存、分佈式追蹤——這些 Web 基礎設施數十年來驗證過的能力，現在可以直接服務於 Agent 工具鏈。

對 Agent 開發者而言，這意味着 MCP Server 的部署與運維複雜度顯著下降；對平臺與雲廠商而言，MCP 正從實驗性集成走向生產級基礎設施。如果你已經在用 Remote MCP 連接 GitHub、Linear、Supabase 等官方託管端點，這次規範升級值得儘快跟進 SDK 版本，把架構從無狀態改造中真正獲益。