MCP 2026-07-28 遷移指南：無狀態伺服器

TL;DR: MCP 2026-07-28 移除了協議層面的會話與強制的初始化握手。生產團隊應找出隱藏的會話相依性，改用每請求協議中繼資料，實作 Multi Round-Trip Requests，更新網關策略，並在淘汰舊行為前以金絲雀方式導入新協議。

2026 年 7 月 28 日發布的 Model Context Protocol 規範，帶來自新增遠端傳輸以來對 MCP 最大的架構變更。

協議核心改為無狀態的請求－回應模式。必需的 initialize 與 notifications/initialized 交換已移除，Mcp-Session-Id 被刪除，每個請求都攜帶處理所需的協議資訊。

此次發布還引入了 Multi Round-Trip Requests、HTTP 路由標頭、可快取的列表回應、更嚴格的授權行為、擴充框架，以及正式的汰除生命週期。協議層細節請見官方 MCP 2026-07-28 發布公告與完整規範變更記錄。

這些變更讓遠端 MCP 伺服器更容易在標準 HTTP 基礎設施後方擴展。但它們不會自動讓現有應用變為無狀態。

生產伺服器仍可能依賴記憶體內工作區、黏性路由、與會話綁定的憑證、長壽命串流，或伺服器主動發起的互動。本指南聚焦於識別並替換這些相依性。

若需要更入門的實作導覽，請在開始遷移前閱讀如何為 Claude Code 建立 MCP 伺服器。

誰需要遷移？

遷移工作量取決於您在系統中如何使用 MCP。

不跨請求保留狀態的本地伺服器，可能只需升級 SDK 與相容性測試。

使用會話、OAuth、串流或伺服器主動請求的遠端部署，則需要分階段遷移。

MCP 2026-07-28 有哪些變更？

1. 稽核現有實作

升級前，請在客戶端、伺服器、網關與部署設定中搜尋舊協議假設。

Mcp-Session-Id
initialize
notifications/initialized
sessionId
ctx.sessionId
extra.sessionId
sticky_session
sticky-session
elicitation/create
sampling/createMessage
roots/list
resources/subscribe
resources/unsubscribe
logging/setLevel
tasks/result
tasks/list
Last-Event-ID

接著回答以下問題：

1. 伺服器是否在初始化完成前拒絕呼叫？
2. 會話 ID 是否用於選擇使用者、憑證、工作區或對話？
3. 另一台伺服器個體能否延續由第一台啟動的工作流程？
4. 負載平衡器是否需要會話親和性？
5. 工具是否在請求確認前就執行副作用？
6. 網關是否解析本文以識別方法或工具？
7. OAuth 憑證是否在未記錄簽發授權伺服器的情況下儲存？
8. 客戶端是否依賴 SSE 重新連線或訊息重新投遞？
9. 工具或資源清單是否因連線而異？
10. 哪些已棄用功能仍接收生產流量？

在了解應用在其後保存了哪些內容前，請勿移除 Mcp-Session-Id。

僅移除標頭但仍把狀態保留於本機記憶體的伺服器，可能在開發時正常，當請求分散至多個個體後會間歇性失敗。

2. 取代隱藏會話狀態

MCP 2026-07-28 移除的是協議層會話，而非應用狀態。

跨呼叫所需的狀態應採以下三種模式之一。

顯式控制代碼

從一個工具回傳由伺服器簽發的控制代碼，並要求在後續呼叫中提供。

{
  "resultType": "complete",
  "content": [
    {
      "type": "text",
      "text": "Workspace created."
    }
  ],
  "structuredContent": {
    "workspaceHandle": "ws_7f93a2"
  }
}

後續請求以一般參數傳遞該控制代碼：

{
  "name": "update_workspace",
  "arguments": {
    "workspaceHandle": "ws_7f93a2",
    "status": "approved"
  }
}

此舉讓相依性在工具合約中可見，也允許任何相容的伺服器個體處理該請求。

共享儲存

在以下情況使用資料庫、分散式快取、物件儲存或可久存的工作系統：

• 多個工作者需要相同狀態；
• 工作流程需在重啟後存續；
• 狀態太大不適合以控制代碼承載；
• 工作流程超過單一請求；
• 需要交易性或一次性行為。

受保護的 requestState

MRTR 可回傳一個不透明的 requestState 值，客戶端在重試原始請求時回送它。

由於該值會經由客戶端傳遞，請以 HMAC 或具驗證的加密保護。當需要重放防護時，將其繫結至已驗證主體、原始操作、重要參數、到期時間與 nonce。

切勿僅因客戶端未改動就信任未簽名的 requestState。

3. 採用自含式請求與探索

現代 MCP 請求於 _meta 中包含協議脈絡。

一個 Streamable HTTP 工具呼叫可能如下：

POST /mcp HTTP/1.1
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: search
Content-Type: application/json
Authorization: Bearer <token>
{
  "jsonrpc": "2.0",
  "id": "req-101",
  "method": "tools/call",
  "params": {
    "name": "search",
    "arguments": {
      "query": "stateless MCP migration"
    },
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientInfo": {
        "name": "example-client",
        "version": "2.0.0"
      },
      "io.modelcontextprotocol/clientCapabilities": {
        "elicitation": {}
      }
    }
  }
}

目標為新協議的伺服器必須實作 server/discover，用以宣告支援的版本、能力與伺服器身分。客戶端可在其他操作前呼叫，或用於判斷是否需要傳統回退。

請閱讀官方的 server/discover documentation 以了解回應合約。

TypeScript SDK 版本協商

僅升級 TypeScript SDK 並不會自動讓客戶端切換至新協議。

使用 v2 SDK 的客戶端必須明確選擇加入：

const client = new Client(
  {
    name: "my-client",
    version: "1.0.0"
  },
  {
    versionNegotiation: {
      mode: "auto"
    }
  }
);

await client.connect(transport);

在自動模式下，SDK 會以 server/discover 探測，並在遇到舊伺服器時回退至舊初始化流程。

仍使用 @modelcontextprotocol/sdk v1 的團隊，應先依照官方的 TypeScript SDK v1-to-v2 遷移指南。已使用 v2 的團隊，則參考2026-07-28 協議支援指南。

4. 以 MRTR 取代伺服器主動請求

早期 MCP 可由伺服器向客戶端發送 elicitation/create、sampling/createMessage 或 roots/list 等請求。

新協議以 Multi Round-Trip Requests 取代此模型。

流程如下：

1. 客戶端送出原始請求。
2. 伺服器回傳 resultType: "input_required"。
3. 客戶端收集所需資訊或核准。
4. 客戶端以新的 JSON-RPC ID 重試原始操作。
5. 重試包含 inputResponses 與原始的 requestState。
6. 伺服器完成請求，或開始下一輪。

回應範例：

{
  "jsonrpc": "2.0",
  "id": "delete-1",
  "result": {
    "resultType": "input_required",
    "inputRequests": {
      "confirm_delete": {
        "method": "elicitation/create",
        "params": {
          "mode": "form",
          "message": "Delete project project_123?",
          "requestedSchema": {
            "type": "object",
            "properties": {
              "confirmed": {
                "type": "boolean"
              }
            },
            "required": ["confirmed"]
          }
        }
      }
    },
    "requestState": "protected-expiring-state"
  }
}

客戶端重試原始操作：

{
  "jsonrpc": "2.0",
  "id": "delete-2",
  "method": "tools/call",
  "params": {
    "name": "delete_project",
    "arguments": {
      "projectId": "project_123"
    },
    "inputResponses": {
      "confirm_delete": {
        "action": "accept",
        "content": {
          "confirmed": true
        }
      }
    },
    "requestState": "protected-expiring-state"
  }
}

生產環境中的 MRTR 實作應定義：

• 最大輪數；
• 請求狀態到期時間；
• 取消與拒絕行為；
• 回應結構驗證；
• 每次重試的授權檢查；
• 重放防護；
• 具副作用操作的冪等性；
• 當客戶端不支援所需能力時的行為。

避免在返回 input_required 前完成購買、刪除、扣點或外部寫入。

使用分段操作或冪等鍵，以避免重試造成重複動作。完整互動模型請見官方 MRTR 規範。

5. 更新網關、快取與授權

基礎設施相關變更彼此緊密相連，應一併測試。

驗證 MCP 路由標頭

Streamable HTTP POST 請求現在包含：

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

這些標頭讓網關無需解析每個 JSON 本文即可進行路由、計量、授權與速率限制。

可支援如下控管：

• 針對特定工具的速率限制；
• 將列表與執行方法分開的策略；
• 為昂貴工具配置專屬工作池；
• 限制高風險操作的存取；
• 依工具的延遲與錯誤指標；
• 基礎設施成本歸因。

這些值仍由客戶端提供。於套用策略前，請將其與 JSON-RPC 本文比對。

請求不應能在 Mcp-Name 中宣稱低風險工具卻在本文呼叫其他工具。標頭與本文不一致時應拒絕並記錄。

使用具授權意識的快取鍵

新協議為可快取結果新增 ttlMs 與 cacheScope，涵蓋：

• tools/list
• prompts/list
• resources/list
• resources/templates/list
• resources/read

快取鍵通常應包含：

protocol version
server identity
method
request parameters
authenticated principal or tenant
authorization scope
cacheScope
server configuration version

切勿僅因 TTL 未過期，就在不同使用者或租戶間共用私人快取項目。

決定性工具排序也很重要。穩定的目錄可避免不必要的快取失誤，並在將工具定義插入提示時，提升模型提示快取的再利用率。

強化 OAuth 簽發者處理

在授權遷移期間：

• 針對流程記錄的簽發者驗證返回的 iss 值；
• 以簽發者為鍵儲存客戶端憑證；
• 切勿在另一個授權伺服器上重用憑證；
• 在 DCR 期間設定合適的 application_type；
• 為 Client ID Metadata Documents 做好新整合準備。

Dynamic Client Registration 仍為相容性而保留，但已不再是首選註冊方式。

6. 遷移通知、任務與已棄用功能

舊的 HTTP GET 通知路徑與 resources/subscribe、resources/unsubscribe 流程已由 subscriptions/listen 取代。

客戶端開啟長時間 POST 回應串流，並選擇加入所需通知類別。請求層級的進度與日誌通知仍附加於其所描述請求的回應串流上。

對多個體部署而言，當在一個伺服器個體上產生的通知必須送達連線到另一個個體的訂閱時，請使用共享事件匯流排。

Tasks 擴充

長時間工作的能力已自核心實驗功能移至：

io.modelcontextprotocol/tasks

該擴充使用：

• tasks/get 以輪詢；
• tasks/update 進行客戶端到伺服器更新；
• 可久存的任務控制代碼；
• subscriptions/listen 以接收選擇加入的更新。

舊的 tasks/result 與 tasks/list 模式不應帶入新實作。

已棄用功能

以下功能已棄用：

在汰除視窗期間，已棄用功能仍可使用，但新實作不應採用。MCP 生命週期政策提供至少 12 個月的棄用期；這不代表每個功能都具有相同且已確定的移除日期。

在設定退休期限前，請檢閱官方的已棄用功能登錄。

7. 安全地推出遷移

請勿在一次無監控的發布中同時變更客戶端、伺服器、網關、快取與授權。

建議的遷移順序

1. 盤點協議版本、SDK、會話、SSE 流量、DCR 客戶端與已棄用方法。
2. 先升級非生產環境 SDK。
3. 新增 server/discover 與版本協商。
4. 取代隱藏的會話相依性。
5. 實作並加固 MRTR。
6. 新增已驗證的路由標頭與具範圍的快取。
7. 測試授權簽發者邊界。
8. 在舊路徑旁以金絲雀方式導入現代協議。
9. 僅在檢視遙測後退休舊行為。

金絲雀期間的相容性

Modern client + modern server
→ Use MCP 2026-07-28

Modern client + legacy server
→ Probe and fall back when supported

Legacy client + dual-version server
→ Continue on the legacy path

Unsupported combination
→ Return a clear protocol-version error

新 MCP 規範的發布並非整個生態系的即時切換。客戶端、伺服器、SDK 與託管平台將以不同速度遷移。

建議記錄的遙測

僅有單次 tools/call 的成功並不足以衡量遷移。反覆逾時、要求不必要輸入或重複外部寫入的工作流程，仍屬生產失敗。

CometAPI 在 MCP 架構中的定位

MCP 並不取代模型 API。兩者解決不同的整合問題。

典型生產架構如下：

Application or agent
        ↓
MCP clients and servers
Tools, resources, approvals, tasks
        ↓
Unified model API
GPT, Claude, Gemini, DeepSeek, and other models

MCP 標準化代理與工具與脈絡的互動方式。它不標準化模型定價、供應商憑證、推理端點或供應商切換。

當從已棄用的 Sampling 能力遷移時，這種分離特別實用。若 MCP 伺服器或其消費的代理仍需模型推理，應用可以直接呼叫模型 API，而非依賴過去的 MCP Sampling 流程。

何時需要統一模型閘道

當以下情況發生時，統一模型閘道可降低營運負擔：

• 多個 MCP 伺服器需要存取不同模型供應商；
• 不同工具需要不同模型；
• 團隊希望在不重寫供應商特定整合的情況下切換模型；
• 需要集中管理憑證、用量與計費；
• 模型存取應與 MCP 傳輸變更保持獨立。

CometAPI 提供相容 OpenAI 的端點，可作為 MCP 應用背後的模型存取層。此舉將模型供應商邏輯與 MCP 工具、資源與任務協調分離。

例如，MCP 工具可透過應用其他部分已使用的相容 OpenAI 客戶端呼叫模型：

import OpenAI from "openai";

const client = new OpenAI({
  apiKey: process.env.COMETAPI_KEY,
  baseURL: "https://api.cometapi.com/v1"
});

export async function summarizeResource(content: string) {
  const response = await client.chat.completions.create({
    model: "your-selected-model",
    messages: [
      {
        role: "system",
        content: "Summarize the supplied resource clearly and concisely."
      },
      {
        role: "user",
        content
      }
    ]
  });

  return response.choices[0]?.message?.content ?? "";
}

MCP 伺服器仍負責工具合約、授權、狀態與結果處理。模型閘道負責模型選擇、供應商存取與推理回應。

保持這些層次分離有兩個實務好處：

1. MCP 客戶端與伺服器可在不變更模型整合層的情況下遷移至新協議。
2. 可在不重新設計 MCP 工具或傳輸行為的情況下更換模型供應商。

更多實作細節請見 CometAPI 快速上手、API 文件，以及多模型 AI 應用指南。

MCP 2026-07-28 遷移清單

客戶端

• 升級至相容的 SDK。
• 啟用現代版本協商。
• 支援 server/discover。
• 在每個請求包含協議中繼資料。
• 處理 resultType。
• 支援或明確拒絕 MRTR。
• 為重試使用新的 JSON-RPC ID。
• 保存並回傳 requestState。
• 驗證 OAuth 簽發者。
• 依簽發者儲存憑證。
• 遵循快取提示。
• 需要時支援 subscriptions/listen。

伺服器

• 移除現代請求的初始化閘門。
• 移除對 Mcp-Session-Id 的相依。
• 實作 server/discover。
• 以控制代碼或共享儲存取代隱藏狀態。
• 回傳 resultType。
• 以 MRTR 取代伺服器主動請求。
• 保護 requestState。
• 驗證所有 inputResponses。
• 為具副作用操作加入冪等性。
• 回傳決定性的列表。
• 發布保守的快取提示。
• 將長時間工作遷移至 Tasks 擴充。

網關與基礎設施

• 驗證 MCP 請求標頭。
• 比對標頭與請求本文。
• 移除不必要的黏性路由。
• 在多個個體間測試請求。
• 依授權邊界分割快取。
• 必要時新增共享通知匯流排。
• 追蹤舊版與已棄用流量。
• 在金絲雀期間保留回滾路徑。

常見問題

什麼是 MCP 2026-07-28？

MCP 2026-07-28 是於 2026 年 7 月 28 日發布的 Model Context Protocol 規範。它引入無狀態協議核心、Multi Round-Trip Requests、HTTP 路由標頭、可快取結果、授權變更、擴充與正式的汰除生命週期。

Mcp-Session-Id 是否被移除？

是。新的 Streamable HTTP 協議不再使用 Mcp-Session-Id。

應用仍可透過顯式控制代碼、共享儲存、可久存任務或受保護的請求狀態值保存狀態。

MCP 初始化握手是否被移除？

是。現代請求不再需要 initialize 與 notifications/initialized 交換。

伺服器必須實作 server/discover，但客戶端不必在每次操作前都呼叫。

無狀態 MCP 是否代表工具不能保存狀態？

否。無狀態指的是協議層。

工具仍可保存狀態，但請求處理不應依賴隱藏的傳輸親和性，或某一特定伺服器行程。

什麼是 MRTR？

Multi Round-Trip Requests 讓伺服器在不依賴持續開啟的雙向連線發送主動請求的情況下，向客戶端或使用者索取額外輸入。

伺服器回傳 input_required，客戶端以所需回應重試原始操作。

HTTP+SSE 是否立即移除？

否。它是被棄用，而非立即移除。

新伺服器應使用 Streamable HTTP，現有系統則應衡量並遷移剩餘 HTTP+SSE 流量。

TypeScript SDK v2 客戶端會自動使用 MCP 2026-07-28 嗎？

不會。TypeScript v2 SDK 需要明確的版本協商設定才能使用現代協議。

當客戶端必須同時支援現代與舊伺服器時，請使用自動協商。

最終建議

MCP 2026-07-28 讓遠端 MCP 基礎設施更易擴展、路由、快取與觀測。主要遷移風險不僅是移除標頭或握手，而是仍依賴它們的隱藏應用狀態與互動邏輯。

在部署新協議前：

找出所有對初始化與 Mcp-Session-Id 的相依。

1. 將必要狀態移入顯式控制代碼或共享儲存。
2. 實作具到期、重放防護與冪等性的 MRTR。
3. 驗證 MCP 標頭與 JSON-RPC 本文一致。
4. 依租戶與授權範圍分割快取。
5. 加固 OAuth 簽發者驗證。
6. 衡量已棄用方法與舊傳輸流量。
7. 在退休前，以金絲雀方式並行現代與舊協議路徑。

將此次遷移視為基礎設施變更，而非例行 SDK 升級。

當 MCP 層無狀態且可觀測後，請將模型存取維持在獨立介面背後。這可讓工具協議與模型供應商層得以各自演進。