MCP 的 stdio、SSE 和 Streamable HTTP 有什麼區別：本地與遠程 MCP 怎麼選

本文根據 MCP 官方規範《Transports》（協議版本 2025-11-25）整理，資料核對於 2026-10-11。MCP 的基本概念見《MCP 是什麼》。

適用於誰

• 搜「mcp stdio sse 區別」「mcp streamable http 和 sse 的區別」「mcp streamable http 協議」的人；
• 配 MCP 時看到 command 和 url 兩種寫法、sse 和 http 兩種類型，不知道該用哪個的人；
• 自己寫 MCP 伺服器，要決定用哪種方式對外提供的人。

結論先說

1. 規範只定義了兩種標準傳輸方式：stdio 和 Streamable HTTP。
2. stdio = 本地子進程。客戶端啟動伺服器程序，通過標準輸入輸出傳消息。配置裏寫的是 command 和 args。
3. Streamable HTTP = 網絡服務。伺服器獨立運行，提供一個 HTTP 端點，客戶端用網址連接。配置裏寫的是 url。
4. SSE 有兩個意思，別混了：一是舊版協議（2024-11-05）裏的「HTTP+SSE」傳輸方式，已被 Streamable HTTP 取代；二是 Streamable HTTP 內部仍然可以用 SSE 這種流式響應格式。看到配置裏的 sse 類型，指的是前者。
5. 怎麼選：需要訪問你本機文件和程序的，用 stdio；只是調用某個雲服務的，優先用廠商提供的遠程伺服器。

一、stdio：把伺服器當子進程

規範描述的工作方式：

• 客戶端把 MCP 伺服器作為子進程啟動；
• 伺服器從標準輸入讀取 JSON-RPC 消息，把消息寫到標準輸出；
• 消息之間用換行分隔，消息內部不得包含換行；
• 伺服器可以向標準錯誤寫日誌；客戶端不應把標準錯誤裏有輸出當作出錯的證據；
• 伺服器不得向標準輸出寫入任何不是合法 MCP 消息的內容。

最後一條是寫伺服器的人最容易違反的：一句調試用的打印語句就會讓通信出錯。

規範還有一句：客戶端在可能的情況下應當支持 stdio。所以幾乎所有 MCP 客戶端都能配本地伺服器。

典型配置長這樣（Claude 桌面版的官方示例）：

json
{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem", "/Users/username/Desktop"]
    }
  }
}

二、Streamable HTTP：一個端點，兩種響應

規範描述的工作方式：

• 伺服器提供一個 MCP 端點，同時接受 POST 和 GET；
• 客戶端發的每條消息都是一次新的 POST，請求頭 Accept 裏要同時列出 application/json 和 text/event-stream；
• 對於請求，伺服器可以直接回一個 JSON，也可以打開一條 SSE 流陸續返回，客戶端兩種都必須能處理；
• 客戶端可以用 GET 打開一條 SSE 流，用來接收伺服器主動發來的消息；伺服器不支持時返回 405。

「Streamable」指的就是這一點：簡單的調用一問一答，耗時的調用可以流式返回進度和結果，用的是同一個端點。

會話

• 伺服器可以在初始化響應裏通過 MCP-Session-Id 響應頭分配一個會話 ID；
• 之後客戶端的所有請求都必須帶上它；
• 伺服器可以隨時結束會話，此後對該會話的請求返回 404，客戶端必須重新初始化；
• 客戶端不再需要會話時，應當發一個 HTTP DELETE 來結束它。

斷線續傳

• 伺服器可以給 SSE 事件加上事件 ID；
• 連接斷開後，客戶端用帶 Last-Event-ID 請求頭的 GET 請求續上；
• 規範特別說明：連接斷開不等於取消。要取消一個請求，客戶端應當顯式發送取消通知。

協議版本頭：初始化之後，客戶端的所有請求都要帶 MCP-Protocol-Version 請求頭，例如 2025-11-25。

三、舊的 HTTP+SSE 是怎麼回事

協議版本 2024-11-05 裏的 HTTP 傳輸方式叫 HTTP+SSE，它用兩個端點：一個 SSE 端點用來收，一個 POST 端點用來發。Streamable HTTP 把它們合併成了一個端點，並取代了它。

規範給出的兼容辦法：

• 伺服器想照顧老客戶端，可以在新的 MCP 端點之外繼續保留舊的 SSE 和 POST 端點；
• 客戶端先向網址 POST 一個初始化請求，成功就說明是 Streamable HTTP；如果返回 400、404 或 405，再發一個 GET，如果收到的第一個事件是 endpoint，說明對方是舊的 HTTP+SSE 伺服器。

落到日常使用上：

這個按結尾判斷的辦法，MCP 官方調試工具 Inspector 自己也在用：它的文檔寫明，不指定傳輸方式時，網址必須以 /mcp 或 /sse 結尾才能自動判斷。Claude Code 裏連接遠程伺服器的具體命令見《Claude Code MCP 配置教學》。

四、對比

五、本地還是遠程，怎麼選

先問一個問題：它真的需要跑在我的電腦上嗎？

• 需要本機資源的，用 stdio：讀寫本地文件、操作本地瀏覽器、連只在內網或本機的數據庫、調用本機的命令行工具；
• 只是調用雲服務的，用遠程伺服器：GitHub、Notion、Sentry 這類服務，廠商提供官方遠程端點的，用遠程的。不用在本機跑一個第三方進程，授權也可以隨時在服務方撤銷。

本地 MCP 伺服器是以你的身份運行的程序。MCP 官方的本地伺服器教學裏就有這樣的提醒：伺服器以你的用戶帳號權限運行，你能手動做的文件操作它都能做。所以本地伺服器裝得越少越好，安裝前的檢查見《MCP 伺服器怎麼選、裝之前怎麼審》。

六、自己提供 HTTP 服務時的安全要求

規範在 Streamable HTTP 一節有一段安全警告，三條要求：

1. 伺服器必須校驗所有傳入連接的 Origin 請求頭，不合法的返回 403，用來防止 DNS 重綁定攻擊；
2. 在本機運行時，伺服器應當只綁定到 127.0.0.1，而不是所有網卡；
3. 伺服器應當為所有連接實現適當的鑑權。

規範解釋，不做這些防護的話，攻擊者可以通過惡意網頁去訪問你本機上的 MCP 伺服器。用官方 SDK 寫伺服器時，核對一下這三條是否已經滿足。

常見問題

Q：同一個伺服器可以兩種方式都支持嗎？

可以。很多伺服器同時提供本地安裝和遠程端點兩種用法；官方 Python SDK 寫的伺服器也可以通過參數切換傳輸方式，見《MCP Server 開發入門（Python）》。

Q：SSE 是不是被廢棄了？

被取代的是舊的「HTTP+SSE 傳輸方式」。SSE 作為一種流式響應格式，仍然是 Streamable HTTP 的組成部分。

Q：遠程伺服器連不上怎麼查？

先確認網址和類型對得上（/mcp 配 http、/sse 配 sse）；再看是否需要登入授權；最後用 MCP Inspector 直接連一下，排除客戶端配置的因素，見《MCP Inspector 怎麼用》。

Q：還有別的傳輸方式嗎？

規範允許自定義傳輸方式，只要保持 JSON-RPC 消息格式和 MCP 的生命週期要求。日常使用碰到的基本只有上面兩種。

參考資料

• Transports（MCP 規範 2025-11-25）：https://modelcontextprotocol.io/specification/2025-11-25/basic/transports
• Inspector v1 → v2 migration（MCP 官方倉庫）：https://github.com/modelcontextprotocol/inspector/blob/main/docs/v1-to-v2-migration.md
• Connect to local MCP servers（MCP 官方）：https://modelcontextprotocol.io/docs/develop/connect-local-servers