MCP 传输：stdio、Streamable HTTP 与旧 SSE

• 能说明MCP 传输：stdio、Streamable HTTP 与旧 SSE解决什么问题，以及何时适用。
• 能解释为什么“把 SSE 事件流等同于旧 HTTP+SSE 传输”是误区。

同样的 MCP 能力可以由本地进程提供，也可以由远程服务提供。传输决定消息如何到达、如何取消与如何管理连接，部署方式不同，认证、生命周期和故障处理也不同。

旧教程常把 SSE 当成某一种协议的全部名称。需要区分“用 SSE 承载某次响应”与已被替代的旧 HTTP+SSE 传输设计，不能只按是否出现事件流判断版本。

传输规定 Client 与 Server 如何承载协议消息；它不改变 Tool、Resource、Prompt 的语义。

同一份协议消息可以走本地管道或网络公路，但路线、认证和攻击面不同。

stdio 由 Client 启动本地子进程，通过标准输入输出交换换行分隔的 JSON-RPC 消息。stdout 是协议通道，调试日志应写 stderr；进程退出、阻塞和缓冲问题都会影响调用。

Streamable HTTP 使用一个 MCP HTTP 端点发送请求，响应可以是 JSON，也可以是请求范围内的 SSE 流。SSE 是响应承载形式之一，所以使用 SSE 并不意味着仍在采用旧双端点传输。

2026-07-28 规范强调每个请求自带协议版本与客户端能力，传输负责承载这些消息，不能改变 Tool 等能力的语义。旧版本存在连接级初始化与其他消息模式，迁移时要同时检查协议版本与传输绑定。

旧 HTTP+SSE 已被 Streamable HTTP 替代，弃用与最早移除时间应查官方生命周期记录，不能自行假定统一的一年期限。新接入优先评估当前传输，兼容旧服务时明确维护边界、认证方式与迁移计划。

这些区别见 传输规范 与 弃用登记。

1. 判断本地还是远程
2. 本地优先评估 stdio
3. 远程使用当前 Streamable HTTP
4. 配置认证与来源校验
5. 旧 Server 仅在迁移期兼容

• 本地开发
• 远程 MCP 服务

• 把所有 SSE 流都称为旧 HTTP+SSE，或者因为 SDK 兼容旧方式就把它当新项目首选。
• 在 stdio 的 stdout 输出调试信息，破坏协议消息边界。
• 只替换连接地址，不核对协议版本、认证、取消语义和有副作用请求的恢复策略。

输入

• 协议消息
• 进程管道或 HTTPS 请求

输出

• 协议响应或流式事件

能力

• 本地开发
• 远程 MCP 服务

性能考虑

• stdio 启动简单但受本机进程生命周期影响。
• 远程 HTTP 需要处理网络延迟、认证、重试与速率限制。