StreamableHTTP 是 MCP 針對一個根本性問題所提出的解決方案：某些 MCP 功能需要伺服器向客戶端發出請求，但 HTTP 讓這件事變得具有挑戰性。讓我們來探討 StreamableHTTP 如何繞過這項限制，以及您何時可能需要打破這個變通方法。
核心問題
某些 MCP 功能，例如取樣（sampling）、通知（notifications）和日誌記錄（logging），依賴於伺服器主動向客戶端發出請求。然而，HTTP 的設計是讓客戶端向伺服器發出請求，而不是反過來。StreamableHTTP 透過使用伺服器發送事件（Server-Sent Events，SSE）的巧妙變通方法解決了這個問題。
StreamableHTTP 的運作方式
這個魔法是透過一個多步驟的流程實現的，該流程在客戶端和伺服器之間建立持久連線。
初始連線設定
這個流程的開始方式與任何 MCP 連線相同：
- 客戶端向伺服器發送
Initialize Request - 伺服器以包含特殊
mcp-session-id標頭的Initialize Result回應 - 客戶端發送帶有 session ID 的
Initialized Notification
這個 session ID 至關重要——它能唯一識別客戶端，並且必須包含在所有後續的請求中。
SSE 變通方法
初始化完成後，客戶端可以發出 GET 請求以建立伺服器發送事件連線。這會建立一個長時間存在的 HTTP 回應，伺服器可以隨時利用它將訊息串流回客戶端。
這個 SSE 連線是實現伺服器對客戶端通訊的關鍵。伺服器現在可以透過這個持久通道發送請求、通知和其他訊息。
工具呼叫與雙重 SSE 連線
當客戶端進行工具呼叫時，情況會變得更複雜。系統會建立兩個獨立的 SSE 連線：
- 主要 SSE 連線： 用於伺服器發起的請求，並會無限期保持開啟
- 工具專屬 SSE 連線： 為每次工具呼叫建立，並在工具結果發送後自動關閉
訊息路由
不同類型的訊息會透過不同的連線進行路由：
- 進度通知： 透過主要 SSE 連線發送
- 日誌訊息與工具結果： 透過工具專屬 SSE 連線發送
會打破變通方法的設定旗標
StreamableHTTP 包含兩個重要的設定選項：
stateless_httpjson_response
將這些設為 True 可能會破壞 SSE 變通機制。在某些情境下，您可能會想啟用這些旗標，但這樣做會限制依賴伺服器對客戶端通訊的完整 MCP 功能。
重點整理
StreamableHTTP 比其他 MCP 傳輸方式更為複雜，因為它必須繞過 HTTP 的限制。基於 SSE 的變通方法使完整的 MCP 功能得以在 HTTP 上運作，但理解雙連線模型對於除錯和最佳化至關重要。
在使用 StreamableHTTP 建構 MCP 應用程式時，請記住初始化後的所有請求都需要 session ID，而系統會自動管理多個 SSE 連線，以處理不同類型的伺服器對客戶端通訊。