传输层：stdio 与 Streamable HTTP

传输层决定"消息走什么管道"。MCP 目前主推两种传输：stdio 用于本地子进程，Streamable HTTP 用于远程服务；曾经流行的 HTTP+SSE 传输已弃用。理解二者的取舍是选择部署形态的前提。

stdio：本地子进程通信

客户端把服务器作为子进程启动，用其标准输入（stdin）发送 JSON-RPC，从标准输出（stdout）读取响应，日志走 stderr 以免污染协议流。服务器因此被"打包"成一个可执行命令：

# 客户端视角：把服务器当命令拉起，例如
python server.py
# 输出：进程常驻，等待 stdin 上的 JSON-RPC 消息（不会打印业务日志到 stdout）

• 优点：零网络配置、权限随进程、进程退出即断开，最适合桌面应用与 CLI。
• 局限：客户端与服务器必须在同一台机器，多客户端共享同一服务器不方便。

Streamable HTTP：远程服务通信

Streamable HTTP 于 2025-03 规范引入，逐步取代早期的 HTTP+SSE 组合。客户端向服务器端点（默认路径常为 /mcp）发送 POST 请求：

curl -X POST http://localhost:3000/mcp \
  -H 'Content-Type: application/json' \
  -H 'Accept: application/json, text/event-stream' \
  -d '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{}}'

要点：

• 普通请求走 HTTP POST 返回 JSON；需要持续推送（服务器主动消息、进度）时，响应可用 SSE 流式返回。
• 服务器通过响应头（如 Mcp-Session-Id）标记会话，客户端后续请求携带该标识维持状态。
• 远程部署通常还涉及授权（规范采用 OAuth 相关流程），细节以官方规范为准。

两种传输对比

维度	stdio	Streamable HTTP
进程关系	本地子进程	独立 HTTP 服务
数据通道	stdin/stdout	POST 请求 + 可选 SSE 流
适用场景	本地、单用户、桌面	远程、多客户端、云端
会话	进程即会话	会话标识维持
鉴权	依赖进程权限	网络层授权
典型端点	无（命令本身）	https://host/mcp

怎么选

• 个人本机用、改完就跑：选 stdio，配置最简单。
• 要部署给多个应用/团队共用、需要独立运维：选 Streamable HTTP。
• 注意：HTTP+SSE 旧传输已弃用，新项目一律用 Streamable HTTP；传输与端点细节持续演进，以 modelcontextprotocol.io 官方文档为准。

小结

stdio 把服务器变成可执行命令，适合本地；Streamable HTTP 把服务器变成网络服务，适合远程。下一章动手写第一个 MCP 服务器，默认就走 stdio。