可串流 HTTP 傳輸讓 MCP 用戶端能夠透過 HTTP 連線連接到遠端託管的伺服器。與要求用戶端和伺服器必須位於同一台機器上的標準 I/O 傳輸不同，這種傳輸方式為任何人都能存取的公開 MCP 伺服器開啟了可能性。
然而，有一個重要的注意事項：某些設定選項可能會大幅限制您的 MCP 伺服器的功能。如果您的應用程式在本機使用標準 I/O 傳輸時運作完美，但在以 HTTP 傳輸部署後卻出現問題，這很可能就是罪魁禍首。
重要的設定選項
有兩個關鍵設定控制可串流 HTTP 傳輸的行為方式：
stateless_http- 控制連線狀態管理json_response- 控制回應格式處理
預設情況下，這兩個設定都是 false，但某些部署情境可能會迫使您將它們設為 true。啟用後，這些設定可能會破壞核心功能，例如進度通知、日誌記錄和伺服器發起的請求。
HTTP 通訊的挑戰
要理解為什麼會存在這些限制，我們需要回顧一下 HTTP 通訊的運作方式。在標準 HTTP 中：
- 用戶端可以輕鬆地向伺服器發起請求（伺服器有已知的 URL）
- 伺服器可以輕鬆地回應這些請求
- 伺服器無法輕鬆地向用戶端發起請求（用戶端沒有已知的 URL）
- 從用戶端回到伺服器的回應模式會變得有問題
受影響的 MCP 訊息類型
這種 HTTP 限制會影響特定的 MCP 通訊模式。以下訊息類型在純 HTTP 下難以實作：
- 伺服器發起的請求： Create Message 請求、List Roots 請求
- 通知： 進度通知、日誌記錄通知、初始化完成通知、取消通知
這些正是在您啟用限制性 HTTP 設定時會損壞的功能。進度條消失、日誌記錄停止運作，伺服器發起的取樣請求也會失敗。
可串流 HTTP 的解決方案
可串流 HTTP 傳輸確實提供了一個巧妙的解決方案來繞過 HTTP 的限制，但這是有取捨的。當您被迫使用 stateless_http=True 或 json_response=True 時，您實際上是在告訴傳輸層在 HTTP 的限制範圍內運作，而不是繞過這些限制。
了解這些限制有助於您就以下事項做出明智的決策：
- 針對不同的部署情境應使用哪種傳輸方式
- 如何設計您的 MCP 伺服器以優雅地處理 HTTP 限制
- 何時應為了遠端託管的好處而接受功能上的縮減
關鍵在於了解這些限制確實存在，並據此規劃您的 MCP 伺服器架構。如果您的應用程式高度依賴伺服器發起的請求或即時通知，您可能需要重新考慮您的傳輸選擇，或實作替代的通訊模式。