MCP 传输标准化：stdio、HTTP+SSE 与 Streamable HTTP

JSON-RPC 2.0定义消息格式，却不规定字节怎样抵达对端。MCP 的传输层使相同的初始化与工具方法可以运行在本地子进程或 HTTP 服务上。本文以 MCP 2025-11-25 传输规范 为基线。

三种名称分别指什么

名称	连接与消息路径	定位
stdio	Client 启动 Server 子进程；双方用标准输入、标准输出交换 JSON-RPC 消息	当前标准传输，适合本地进程
旧版 HTTP+SSE	Client 先打开 SSE 连接；Server 告知消息 POST 端点，Client 再向该端点发请求	旧版传输，主要用于兼容已有服务
Streamable HTTP	Client 向单一 MCP 端点 POST 消息；Server 可返回 JSON 响应或 SSE 流，必要时 Client 可用 GET 打开服务端事件流	当前标准 HTTP 传输

这里的 HTTP+SSE 是一套旧传输协议，SSE 本身只是 HTTP 的服务端事件流格式。替代旧传输不等于禁用 SSE：Streamable HTTP 的响应仍可以使用 SSE。MCP 旧传输说明

stdio：本机进程之间的管道

Host 中的 Client 启动本机 Server，向其标准输入写入一行 JSON-RPC 消息，再从标准输出读取响应或通知。每条消息以换行分隔，消息本身不得包含未转义的换行。Server 的日志应写到标准错误，避免污染协议输出。stdio 规范

stdio 不需要监听端口，生命周期通常跟随启动它的 Client。它适合 IDE、桌面助手或本机脚本接入本地文件和开发环境。信任边界仍很重要：启动命令、环境变量和文件权限决定子进程能访问什么；不能仅因为它在本机就默认可信。

旧版 HTTP+SSE 为什么让位

旧版方案需要先建立专门的 SSE 通道，再从服务端发来的 endpoint 事件取得请求提交地址。Client 的请求经 POST 发送，服务端响应经另一条 SSE 通道返回。这使连接建立和请求路径耦合于两套端点，HTTP 的一次请求与对应响应不再自然相邻，也增加代理、负载均衡和无状态部署的处理成本。

Streamable HTTP 将客户端消息统一提交到一个 MCP 端点，服务端可按请求性质选择普通 JSON 响应或 SSE 流。它也支持服务端到客户端的流式消息，并允许不同实现按需要管理会话。规范将旧版 HTTP+SSE 留作向后兼容，新实现应优先采用 Streamable HTTP；这是一种协议演进和互操作选择，不代表所有旧服务立即失效。MCP 传输规范、TypeScript SDK 服务端指南

Streamable HTTP 如何工作

Client 对 MCP 端点发 POST，每个请求体是一条 JSON-RPC 消息。请求应声明接受 application/json 和 text/event-stream。若请求需要响应，Server 可以直接返回 JSON，也可以返回 SSE 事件流；Client 不能假定所有响应都长期保持连接。Client 还可向同一端点发 GET 以接收服务端主动消息；Server 不支持时可以返回 405 Method Not Allowed。Streamable HTTP 规范

规范还规定协议版本头、可选会话标识、断线恢复等行为；客户端和服务端应按协商的规范版本实现，不能把某个 SDK 的默认行为当作所有版本的通则。远程暴露时需校验 Origin，本地监听应绑定回环地址；如需跨网络访问，应实施鉴权、传输加密和工具权限检查。传输安全要求

如何选择

场景	优先方式	原因与代价
IDE 启动本机工具，访问本地工作区	stdio	启动简单、无监听端口；每个 Client 要管理子进程
多个 Host 访问独立部署的服务	Streamable HTTP	可通过网络共享服务；需要部署、鉴权和网络治理
连接只支持旧版 HTTP+SSE 的服务	旧版 HTTP+SSE 兼容模式	保持旧系统可用；新服务不宜以此作为首选接口

传输只负责送达消息。工具是否可见、谁能调用、调用失败如何呈现，仍取决于协议能力、Host 策略和 Server 实现。接着阅读 MCP 工具提供与调用流程。