Cloudflare One MCP Server Portal 支援新版協定：client 與 upstream 相容性怎麼查

Q: 我需要在 MCP Server Portal 裡指定 2026-07-28 嗎？

官方文件描述的相容流程不要求新增全域協定版本設定。先確認 client 使用 /mcp、upstream transport 和實際 log；只有自有 client 或 proxy 有額外硬編碼假設時，才需要修改那一側的程式。

2026-09-01

AI

Cloudflare

/

MCP

/

AI

/

設定管理

/

遷移指南

MCP 協定升級最容易讓人誤判的地方，是把 client、Cloudflare One MCP Server Portal 和 upstream server 當成同一個版本。實際上，三者可能各自處在不同的協定路徑；如果只看到 client 已支援 stateless，就以為所有 upstream 都已經完成升級，排錯時會很快走偏。

Cloudflare 在 2026 年 8 月 25 日的更新指出，MCP Server Portals 已支援 MCP 2026-07-28 的 stateless Streamable HTTP。portal 對外的 /mcp endpoint 同時接受較早的 2025 Streamable HTTP；upstream 若使用 Streamable HTTP，portal 會先嘗試新版，再回退到 2025 handshake。這是相容性處理，不是要求你在 portal 裡選一個全域版本。

如果你先前讀過 GitHub MCP Server 支援 Stateless MCP 的檢查方式，這篇的焦點不同：前者是檢查 GitHub MCP Server 與自有 client；這篇是檢查 Cloudflare One 作為入口時，入口兩側的協定如何各自協商。

先把三個協定角色分開#

Cloudflare One MCP Server Portal 的用途，是把多個 MCP server 集中到單一入口，並在入口處處理 Access 驗證、server 選擇與必要的 OAuth 狀態。相容性可以先用這張表定位：

角色	你要觀察的端點或行為	這次更新的意義
MCP client	連到 portal 的 `/mcp`，使用 Streamable HTTP 或舊版協定	可接受 `2026-07-28` stateless，也相容較早的 `2025` Streamable HTTP
Portal	對外入口與 Access／OAuth 邊界	不需要新增一個 portal 協定版本設定
Upstream MCP server	portal 連到的實際 server transport	Streamable HTTP 先探測新版，再回退到 2025 handshake
Legacy SSE	仍使用 SSE transport 的 server	仍屬 legacy 路徑，不能當作已升級到新版 stateless transport

關鍵是「client 與 upstream 的選擇彼此獨立」。client 可以用新版 stateless 連到 portal，而 portal 再依 upstream 的能力選擇新版或 2025 的 Streamable HTTP；反過來，client 使用較早版本，也不代表 upstream 必須降級到同一個版本。

三種常見組合，先判斷哪一側在協商#

新 client、新 upstream#

這是最簡單的情況。client 對 portal 的 /mcp 使用 MCP 2026-07-28，upstream 也支援新版 Streamable HTTP，portal 會走新版 stateless 路徑。不要在應用程式裡自行補一個 Mcp-Session-Id 生命週期來「確保相容」；先讓 portal 依官方流程處理。

舊 client、新 upstream#

portal 對外仍接受較早的 2025 Streamable HTTP，因此既有 client 不必因為公告發布就立刻全部重寫。這時 client 端看到的仍是舊版互動方式，portal 到 upstream 的協商則可以獨立採用新版。驗證重點是工具列舉、tool call、錯誤回應與驗證流程是否都能完成，而不是只比對一個版本字串。

新 client、SSE upstream#

SSE 仍是 legacy transport。client 對 portal 能使用新版，不代表後方以 SSE 提供服務的 upstream 也突然變成 Streamable HTTP；這條路徑要保留 legacy 的測試與監控。若你要升級 upstream，應先確認它是否真的改成 Streamable HTTP，再把 transport 變更當成獨立的遷移工作。

不要把 stateless 誤解成「沒有狀態」#

新版 MCP 在協定層不再依賴 initialize／initialized 和 Mcp-Session-Id，但這不等於整個入口不需要任何授權或工作狀態。Cloudflare 文件說明，portal 的 grant 仍會保留 client 的授權、server 選擇與 upstream OAuth 狀態；因此不能因為 transport 是 stateless，就移除 Access policy、OAuth callback 或 server selection 的驗證。

這也影響 log 設計：不要只靠 MCP session ID 關聯一次請求。至少要能把 request、tool call、Access 驗證結果、目標 server 與必要的 trace ID 對在一起；若 upstream 是 SSE，另保留長連線與斷線重連的觀察欄位。

一份不改 portal 設定的升級檢查表#

可以依照以下順序檢查，先確認事實，再決定是否要改 client 或 upstream：

確認入口：client 連的是 Cloudflare portal 的 /mcp，不是某個 upstream 的舊 SSE URL。
記錄 transport：把 client 到 portal、portal 到 upstream 各自標成 Streamable HTTP 或 SSE。
驗證雙側能力：client 測新版與 2025 相容路徑；upstream 若是 Streamable HTTP，確認新版探測失敗時仍能完成舊版 handshake。
測試實際工具：至少跑 tools/list、一個唯讀 tools/call、一個失敗案例，以及 server 選擇流程。
重測授權：確認 Access、OAuth callback、token refresh 和 grant 內保存的 upstream OAuth 狀態仍然正確。
檢查 observability：不把 Mcp-Session-Id 當成唯一關聯鍵，並分別查看 portal 與 upstream 的 log。
標記 SSE 邊界：若任何 upstream 仍是 SSE，將它列入 legacy 清單，另訂升級時程。

這份清單的完成條件是「每一側的協定與驗證結果都可描述」，不是在 Cloudflare dashboard 裡找到一個名為 protocol version 的開關。官方文件對 MCP Server Portals 的建議是由 portal 處理相容性；除非你的實際測試顯示 client、upstream 或自有 proxy 有額外假設，否則不必為了新版公告先改設定。

若 upstream 是你自己維護的 Agents MCP server，還要另外看 Cloudflare Agents SDK v2 的 MCP 遷移，因為 server SDK 的 API 遷移與 portal 的 transport 協商是兩件事。

結論：先畫出兩段連線，再決定要不要改#

Cloudflare One MCP Server Portal 現在可以讓新版與舊版 Streamable HTTP client 共存；對 Streamable HTTP upstream 會先探測 MCP 2026-07-28，失敗後回到 2025 handshake。這讓升級可以分段進行，但也要求你不要把 client 版本、portal 入口和 upstream transport 混在一起判讀。

實務上先固定 /mcp 入口、列出兩段 transport、驗證工具與 OAuth，再把 SSE upstream 標成獨立的 legacy 工作。只要沒有自有 proxy 把舊 session header 當成硬性條件，通常不需要為這次相容性更新新增 portal 版本設定。