版本與相容性

本頁說明 MCP 用戶端與伺服器如何決定彼此使用的協定版本、如何透過 capabilities 協商 optional extensions，以及如何與仍使用 initialize handshake 的較早版本互通。

2026-07-28 沒有版本協商 handshake。每一個請求都直接宣告自己的協定版本，伺服器則逐一接受或拒絕各請求。

術語

為了描述不同 MCP 世代之間的互通，本頁使用下列術語：

• Modern（現代版本）：以每次請求的 metadata 攜帶版本、身分與能力的協定版本；從 2026-07-28 起屬於此類。
• Legacy（舊版）：透過 initialize handshake 建立 session 的協定版本；2025-11-25 與更早版本屬於此類。
• Dual-era（雙世代）：同時支援 Modern 與 Legacy 行為的實作。

協定版本協商

每個請求都會在 _meta.io.modelcontextprotocol/protocolVersion 宣告使用中的協定版本；使用 HTTP 時，版本也會出現在 MCP-Protocol-Version header。

若伺服器不支援請求指定的版本，不論該版本完全未知，或只是伺服器選擇不支援，伺服器都 MUST（必須）回傳 UnsupportedProtocolVersionError，並列出它支援的版本：

{
  "jsonrpc": "2.0",
  "id": 1,
  "error": {
    "code": -32022,
    "message": "Unsupported protocol version",
    "data": {
      "supported": ["2026-07-28", "2025-11-25"],
      "requested": "1900-01-01"
    }
  }
}

用戶端 SHOULD（應該）從 supported 中選擇雙方都能支援的版本並重送請求；若沒有相容版本，則應把錯誤呈現給使用者。

伺服器 MUST（必須）實作 server/discover。用戶端 MAY（可以）在送出其他請求前先呼叫它，以預先取得伺服器支援的版本；但這不是必要步驟。用戶端也可以直接送出任何 RPC，若收到 UnsupportedProtocolVersionError 再處理版本不相容。

擴充功能協商

用戶端與伺服器可以在 core protocol 之外協商 optional extensions。擴充功能會放在 capabilities 的 extensions map 中；key 是 extension identifier，value 則是該擴充功能自己的設定物件。

Extension identifier MUST（必須）遵循 MCP _meta key 的命名規則，且必須具有 prefix。例如 MCP Apps 使用 io.modelcontextprotocol/ui：

{
  "capabilities": {
    "extensions": {
      "io.modelcontextprotocol/ui": {
        "mimeTypes": ["text/html;profile=mcp-app"]
      }
    }
  }
}

Tasks extension 則使用 io.modelcontextprotocol/tasks：

{
  "capabilities": {
    "tools": {},
    "extensions": {
      "io.modelcontextprotocol/tasks": {}
    }
  }
}

每個 extension 自行定義其 settings object；空物件表示支援該 extension，但沒有額外設定。若一方支援某 extension、另一方不支援，支援方 MUST（必須）回到 core protocol 行為，或以適當錯誤拒絕請求。Extensions SHOULD（應該）明確記錄其 fallback 行為。

與初始化式版本的向後相容

需要同時服務 Legacy 與 Modern 用戶端的伺服器 MAY（可以）同時實作兩套行為。需要與兩種伺服器互通的用戶端，則依 transport 使用不同方式判斷伺服器屬於哪個世代：

• stdio：先用 server/discover 探測；若回傳不是已知 Modern error 的其他錯誤，或探測逾時，再 fallback 至 Legacy。
• Streamable HTTP：先嘗試 Modern request；若收到 400 Bad Request，檢查 response body，再決定是否 fallback。

若回應是可辨識的 Modern JSON-RPC error，例如 UnsupportedProtocolVersionError，就代表對方是 Modern server；用戶端應改用彼此支援的版本重試，而不是退回 Legacy。其他非 Modern 的錯誤則代表對方可能是 Legacy server。

世代判斷是「伺服器」的性質，不是單一請求的性質。用戶端 SHOULD（應該）在 stdio server process 或 HTTP origin 的生命週期內快取判斷結果；也 MAY（可以）跨重啟保存，但當假設失敗時應重新探測。

只支援 Modern 的伺服器在收到 initialize 時，SHOULD（應該）在錯誤訊息中指出支援的協定版本，且此要求適用於所有 transport。Legacy client 沒有自動向前升級機制，因此這可能是使用者唯一能看到的診斷資訊。

相容性矩陣

Client	Server	結果
Modern	Modern	可運作。server/discover 為選用；版本不符時由 UnsupportedProtocolVersionError 引導用戶端改用雙方支援的版本重試。
Modern	Legacy	失敗。Legacy server 可能以實作自訂錯誤拒絕、保持沉默，甚至把世代語意模糊的方法依 Legacy semantics 處理。stdio 用戶端 SHOULD（應該）先以 server/discover 探測，以得到可預期的失敗結果，再向使用者呈現可操作的錯誤。
Dual-era	Modern	可運作。stdio probe 會得到 DiscoverResult 或 UnsupportedProtocolVersionError；HTTP 的第一個 Modern request 會成功或回 Modern error。用戶端維持 Modern 行為。
Dual-era	Legacy	可運作。stdio 中，probe 會得到非 Modern error 或逾時，之後 fallback 至 initialize；HTTP 中，Modern request 會得到沒有可辨識 Modern error body 的 4xx，之後 fallback 至 initialize，必要時還可能進一步退回已 deprecated 的 HTTP+SSE transport。
Legacy	Modern	失敗。stdio 中，Modern server 會以 JSON-RPC error 拒絕 initialize；確切 error code 由實作決定，因為 initialize 是未知方法且請求也缺少必要的 _meta。HTTP 中，請求缺少必要 headers，會依 Streamable HTTP server validation 以 400 Bad Request 拒絕；使用 deprecated HTTP+SSE 的 client 則會在一開始的 GET 就失敗。Legacy client 沒有自動向前升級機制。
Legacy	Dual-era	可運作。伺服器回應 initialize，並依協商出的 Legacy revision 服務。
Legacy	Legacy	依該 Legacy revision 運作；不屬於本頁規範範圍。

Dual-era server 會根據用戶端一開始採用的方式決定行為：

• 帶有 Modern per-request _meta 的請求，依 2026-07-28 的無狀態語意處理。
• initialize 請求選擇 Legacy semantics；stdio 下其範圍是程序，HTTP 下其範圍是 session，並依協商出的 Legacy protocol version 決定。

Dual-era server MAY（可以）在同一 endpoint 或 process 中同時服務兩個世代。