Choose your path
了解如何遷移至 MCP 2026-07-28，包括無狀態傳輸、MRTR、路由標頭、快取、OAuth 變更與 SDK 升級。
from openai import OpenAI
client = OpenAI(
api_key="YOUR_COMETAPI_KEY",
base_url="https://api.cometapi.com/v1",
)
response = client.chat.completions.create(
model="gpt-5-mini",
messages=[{"role": "user", "content": "Build this workflow."}],
)
print(response.choices[0].message.content)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 伺服器更容易在標準 HTTP 基礎設施後方擴展。但它們不會自動讓現有應用變為無狀態。
生產伺服器仍可能依賴記憶體內工作區、黏性路由、與會話綁定的憑證、長壽命串流，或伺服器主動發起的互動。本指南聚焦於識別並替換這些相依性。
若需要更入門的實作導覽，請在開始遷移前閱讀如何為 Claude Code 建立 MCP 伺服器。
遷移工作量取決於您在系統中如何使用 MCP。
| 目前實作 | 遷移風險 | 主要動作 |
|---|---|---|
| 使用單次工具的一個本地 stdio 伺服器 | 低 | 升級 SDK 並測試協議協商 |
| 無跨請求狀態的遠端 HTTP 伺服器 | 中 | 新增現代中繼資料、探索與 HTTP 標頭 |
| 使用 Mcp-Session-Id 進行業務狀態 | 高 | 以顯式控制代碼或共享儲存取代隱藏狀態 |
| 由網關解析 JSON-RPC 本文以進行路由 | 中到高 | 新增並驗證 MCP 路由標頭 |
| 工具在呼叫中途請求資訊或核准 | 高 | 將互動遷移至 MRTR |
| 使用 Dynamic Client Registration 的客戶端 | 高 | 強化簽發者處理並為 CIMD 做準備 |
| 使用舊版 HTTP+SSE 的伺服器 | 高 | 遷移到 Streamable HTTP |
| 使用實驗性 Tasks 的工作流程 | 高 | 採用正式的 Tasks 擴充 |
不跨請求保留狀態的本地伺服器，可能只需升級 SDK 與相容性測試。
使用會話、OAuth、串流或伺服器主動請求的遠端部署，則需要分階段遷移。
| 領域 | 過往行為 | MCP 2026-07-28 | 遷移動作 |
|---|---|---|---|
| 初始化 | 需要初始化握手 | 不再需要握手 | 移除現代請求的初始化閘門 |
| 會話 | Mcp-Session-Id | 無協議層會話 | 將必要狀態顯式化 |
| 探索 | 在初始化期間協商 | 可選的 server/discover 呼叫 | 實作探索與版本協商 |
| 請求脈絡 | 儲存在連線上 | 包含於請求的 _meta | 每個請求都傳送協議中繼資料 |
| HTTP 路由 | 網關解析 JSON 本文 | Mcp-Method 與 Mcp-Name 標頭 | 更新路由、策略與可觀測性 |
| 呼叫中互動 | 伺服器主動發送 JSON-RPC 請求 | Multi Round-Trip Requests | 處理 input_required 與重試 |
| 列表快取 | 反覆抓取目錄 | ttlMs、cacheScope、決定性排序 | 新增授權感知的快取 |
| 通知 | GET 串流與資源訂閱 | subscriptions/listen | 將變更通知移至新串流 |
| 授權 | 以 DCR 為中心的註冊 | 更強的簽發者規則與 CIMD 方向 | 稽核 OAuth 客戶端與憑證儲存 |
| 長時間工作 | 核心中的實驗性 Tasks | io.modelcontextprotocol/tasks 擴充 | 移至擴充合約 |
| 舊功能 | Roots、Sampling、Logging、HTTP+SSE |
升級前，請在客戶端、伺服器、網關與部署設定中搜尋舊協議假設。
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
接著回答以下問題：
在了解應用在其後保存了哪些內容前，請勿移除 Mcp-Session-Id。
僅移除標頭但仍把狀態保留於本機記憶體的伺服器，可能在開發時正常，當請求分散至多個個體後會間歇性失敗。
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"
}
}
此舉讓相依性在工具合約中可見，也允許任何相容的伺服器個體處理該請求。
在以下情況使用資料庫、分散式快取、物件儲存或可久存的工作系統：
requestStateMRTR 可回傳一個不透明的 requestState 值，客戶端在重試原始請求時回送它。
由於該值會經由客戶端傳遞，請以 HMAC 或具驗證的加密保護。當需要重放防護時，將其繫結至已驗證主體、原始操作、重要參數、到期時間與 nonce。
切勿僅因客戶端未改動就信任未簽名的 requestState。
現代 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 並不會自動讓客戶端切換至新協議。
使用 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 協議支援指南。
早期 MCP 可由伺服器向客戶端發送 elicitation/create、sampling/createMessage 或 roots/list 等請求。
新協議以 Multi Round-Trip Requests 取代此模型。
流程如下：
resultType: "input_required"。inputResponses 與原始的 requestState。回應範例：
{
"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 規範。
基礎設施相關變更彼此緊密相連，應一併測試。
Streamable HTTP POST 請求現在包含：
MCP-Protocol-VersionMcp-MethodMcp-Name這些標頭讓網關無需解析每個 JSON 本文即可進行路由、計量、授權與速率限制。
可支援如下控管：
這些值仍由客戶端提供。於套用策略前，請將其與 JSON-RPC 本文比對。
請求不應能在 Mcp-Name 中宣稱低風險工具卻在本文呼叫其他工具。標頭與本文不一致時應拒絕並記錄。
新協議為可快取結果新增 ttlMs 與 cacheScope，涵蓋：
tools/listprompts/listresources/listresources/templates/listresources/read快取鍵通常應包含：
protocol version
server identity
method
request parameters
authenticated principal or tenant
authorization scope
cacheScope
server configuration version
切勿僅因 TTL 未過期，就在不同使用者或租戶間共用私人快取項目。
決定性工具排序也很重要。穩定的目錄可避免不必要的快取失誤，並在將工具定義插入提示時，提升模型提示快取的再利用率。
在授權遷移期間：
iss 值；application_type；Dynamic Client Registration 仍為相容性而保留，但已不再是首選註冊方式。
舊的 HTTP GET 通知路徑與 resources/subscribe、resources/unsubscribe 流程已由 subscriptions/listen 取代。
客戶端開啟長時間 POST 回應串流，並選擇加入所需通知類別。請求層級的進度與日誌通知仍附加於其所描述請求的回應串流上。
對多個體部署而言，當在一個伺服器個體上產生的通知必須送達連線到另一個個體的訂閱時，請使用共享事件匯流排。
長時間工作的能力已自核心實驗功能移至：
io.modelcontextprotocol/tasks
該擴充使用：
tasks/get 以輪詢；tasks/update 進行客戶端到伺服器更新；subscriptions/listen 以接收選擇加入的更新。舊的 tasks/result 與 tasks/list 模式不應帶入新實作。
以下功能已棄用：
| 功能 | 建議方向 | MCP 2026-07-28 | 遷移動作 |
|---|---|---|---|
| Roots | 透過工具參數、資源 URI 或設定傳遞目錄 | 不再需要握手 | 移除現代請求的初始化閘門 |
| Sampling | 直接整合模型供應商 API | 無協議層會話 | 將必要狀態顯式化 |
| Logging | 在 stdio 使用 stderr，生產環境使用 OpenTelemetry | 可選的 server/discover 呼叫 | 實作探索與版本協商 |
| Dynamic Client Registration | 移向 Client ID Metadata Documents | 包含於請求 _meta | 每請求傳送協議中繼資料 |
| 舊版 HTTP+SSE | 遷移至 Streamable HTTP | Mcp-Method 與 Mcp-Name 標頭 | 更新路由、策略與可觀測性 |
| 已棄用的 includeContext 值 | 省略該欄位或使用 "none" | Multi Round-Trip Requests | 處理 input_required 與重試 |
| 列表快取 | 反覆抓取目錄 | ttlMs、cacheScope、決定性排序 | 新增授權感知的快取 |
| 通知 | GET 串流與資源訂閱 | subscriptions/listen | 將變更通知移至新串流 |
| 授權 | 以 DCR 為中心的註冊 | 更強的簽發者規則與 CIMD 方向 | 稽核 OAuth 客戶端與憑證儲存 |
| 長時間工作 | 核心中的實驗性 Tasks | io.modelcontextprotocol/tasks 擴充 | 移至擴充合約 |
在汰除視窗期間，已棄用功能仍可使用，但新實作不應採用。MCP 生命週期政策提供至少 12 個月的棄用期；這不代表每個功能都具有相同且已確定的移除日期。
在設定退休期限前，請檢閱官方的已棄用功能登錄。
請勿在一次無監控的發布中同時變更客戶端、伺服器、網關、快取與授權。
server/discover 與版本協商。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 與託管平台將以不同速度遷移。
| 訊號 | 可揭示的內容 |
|---|---|
| 每請求的協議版本 | 採用情況與不相容組合 |
| 探索成功與回退比率 | 版本協商行為 |
| 缺少或無效的 MCP 標頭 | 舊客戶端或網關錯誤 |
| 標頭／本文不一致 | 客戶端錯誤或嘗試繞過策略 |
| MRTR 的請求與完成 | 互動式工作流程的可靠性 |
| MRTR 被拒絕或逾時 | 使用者與客戶端的失敗路徑 |
| 請求狀態驗證失敗 | 竄改、重放或到期 |
| 重複操作防護 | 冪等控管的有效性 |
| 依範圍的快取命中率 | 安全的流量降低 |
| 簽發者驗證失敗 | OAuth 設定問題 |
| HTTP+SSE 流量 | 剩餘的傳輸遷移工作 |
| 已棄用方法的流量 | 退休規劃的依據 |
| 工具延遲與已接受任務比率 | 使用者可感知的可靠性 |
僅有單次 tools/call 的成功並不足以衡量遷移。反覆逾時、要求不必要輸入或重複外部寫入的工作流程，仍屬生產失敗。
MCP 並不取代模型 API。兩者解決不同的整合問題。
| 層級 | 主要責任 |
|---|---|
| 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 流程。
當以下情況發生時，統一模型閘道可降低營運負擔：
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 伺服器仍負責工具合約、授權、狀態與結果處理。模型閘道負責模型選擇、供應商存取與推理回應。
保持這些層次分離有兩個實務好處：
更多實作細節請見 CometAPI 快速上手、API 文件，以及多模型 AI 應用指南。
server/discover。resultType。requestState。subscriptions/listen。Mcp-Session-Id 的相依。server/discover。resultType。requestState。inputResponses。MCP 2026-07-28 是於 2026 年 7 月 28 日發布的 Model Context Protocol 規範。它引入無狀態協議核心、Multi Round-Trip Requests、HTTP 路由標頭、可快取結果、授權變更、擴充與正式的汰除生命週期。
Mcp-Session-Id 是否被移除？是。新的 Streamable HTTP 協議不再使用 Mcp-Session-Id。
應用仍可透過顯式控制代碼、共享儲存、可久存任務或受保護的請求狀態值保存狀態。
是。現代請求不再需要 initialize 與 notifications/initialized 交換。
伺服器必須實作 server/discover，但客戶端不必在每次操作前都呼叫。
否。無狀態指的是協議層。
工具仍可保存狀態，但請求處理不應依賴隱藏的傳輸親和性，或某一特定伺服器行程。
Multi Round-Trip Requests 讓伺服器在不依賴持續開啟的雙向連線發送主動請求的情況下，向客戶端或使用者索取額外輸入。
伺服器回傳 input_required，客戶端以所需回應重試原始操作。
否。它是被棄用，而非立即移除。
新伺服器應使用 Streamable HTTP，現有系統則應衡量並遷移剩餘 HTTP+SSE 流量。
不會。TypeScript v2 SDK 需要明確的版本協商設定才能使用現代協議。
當客戶端必須同時支援現代與舊伺服器時，請使用自動協商。
MCP 2026-07-28 讓遠端 MCP 基礎設施更易擴展、路由、快取與觀測。主要遷移風險不僅是移除標頭或握手，而是仍依賴它們的隱藏應用狀態與互動邏輯。
在部署新協議前：
找出所有對初始化與 Mcp-Session-Id 的相依。
將此次遷移視為基礎設施變更，而非例行 SDK 升級。
當 MCP 層無狀態且可觀測後，請將模型存取維持在獨立介面背後。這可讓工具協議與模型供應商層得以各自演進。
| 已棄用 |
| 停止新採用並衡量現有用量 |
| 舊功能 |
| Roots、Sampling、Logging、HTTP+SSE |
| 已棄用 |
| 停止新採用並衡量現有用量 |