MCP 的 stdio 和 Streamable HTTP 如何实现，后者是否属于流式协议？

核心回答

stdio 和 Streamable HTTP 都用来传递 MCP 的 JSON-RPC 消息，区别主要在服务怎样启动、消息怎样传输，以及响应是否可以分多次送达。

stdio：Client 拉起 Server 子进程，通过管道通信。Server 从标准输入读取请求，将响应写到标准输出；消息按换行分隔，日志写到标准错误。
Streamable HTTP：Server 独立提供 HTTP 服务，Client 向 MCP 端点发送 POST。响应可以一次返回 JSON，也可以在这次请求的 SSE 响应流中逐步发送消息。

所以它是支持流式响应的 HTTP 传输方式，每个请求不必都返回流。这种“流式”也不等于大模型必然逐 Token 输出，更不表示它是专门传送音视频帧的媒体协议。

下面的具体行为按 MCP 2026-07-28 说明；接入旧 Server 时，要匹配它实际使用的协议版本。

stdio 怎样实现？

Host 中的 Client 根据命令、参数和环境启动子进程，并连接它的 stdin、stdout、stderr。Client 把序列化后的 JSON-RPC 消息写入子进程 stdin，Server 读取后分发到对应方法，再经 stdout 返回结果。

实现时关注几件事：

**按消息边界读取。**一条消息对应一行紧凑 JSON，结尾加换行。底层一次读取可能只拿到半条消息，也可能包含多条，应先缓冲并按完整行解析；JSON 字符串内的换行需要转义。
**区分协议输出和日志。**stdout 只能写 MCP 消息，启动横幅、调试打印都会破坏解析。stderr 可以承载普通日志，看到 stderr 有内容不代表调用失败。
**按请求关联结果。**同一管道上可能交错出现不同请求的结果和通知，Client 按 JSON-RPC id 找到等待者，不能假定读到的下一行一定就是刚发请求的答案。
**处理进程生命周期。**包括超时、取消、退出及清理；关闭输入后应让子进程正常结束。进程重启不代表之前的业务动作没有发生，写操作重试仍要按业务结果与幂等设计判断。

stdio 常用于本地文件、命令行或桌面工具。它没有额外的 HTTP 服务入口，但子进程仍使用实际操作系统身份和权限，传输方式本身不会把它变成沙箱。

Streamable HTTP 怎样实现？

服务端提供一个 MCP 端点，例如 /mcp。每个客户端请求分别 POST 到该端点，携带协议版本等元数据；Client 在 Accept 中声明能处理 JSON 和 SSE，再按实际响应类型读取。

返回 application/json 时，一次读取完整 JSON-RPC 结果。返回 text/event-stream 时，逐个解析 SSE 事件，从事件数据取出 MCP 消息：可先收到与本次调用有关的进度等通知，最后收到响应。网络分块、SSE 事件、JSON-RPC 消息是不同层次，不能把每次收到的网络字节都直接当成一个完整结果。

远程部署还要处理认证、资源授权、Origin 校验、代理缓冲和超时。例如应用已经逐条写出 SSE，代理却一直缓冲，用户看到的仍可能是最后一次性出现。不能只检查服务端“用了流”，还要检查整条传输链路。

为什么旧教程里的实现可能不同？

2026-07-28 取消了旧的 GET 监听流和协议级会话，使用自包含请求；持续变更通知通过 subscriptions/listen 的 POST 响应流提供。旧版的初始化握手、Mcp-Session-Id 和连接级机制，应放在对应版本的兼容实现中理解。

此版本中，关闭请求的 SSE 响应流表示取消，不支持用 Last-Event-ID 恢复原流。取消也不等于撤销已经发生的外部操作，因此“断开后重新调用”与“接着读原结果”不能混为一谈。

请求取消和订阅机制会随协议版本影响 SDK 行为。实现时先确认 Client、Server 与 SDK 支持的版本，再使用相匹配的封装；不能仅把旧代码中的传输名称改成 streamable-http 就认为迁移完成。

常见追问

既然叫 Streamable，为什么还能返回普通 JSON？

因为它提供流式能力，而不是强制每次调用都建立 SSE 流。快速完成的调用可以返回一个 JSON 结果；长调用需要报告进度时，才有相应的分次交付价值。

这是双向流吗？

Client 可以持续发起请求，Server 可以在响应流中发送消息，但不能据此理解成一个任意双向读写的 WebSocket 通道。当前规范下客户端消息仍分别通过 POST 发送，Server 的消息也受请求和订阅规则约束。

适合直接传输实时音视频吗？

MCP 可以调用音视频处理工具、传递资源信息和处理结果；持续采集、编解码、媒体帧传输与播放则是另一层设计。是否能处理某种数据，取决于工具和应用实现，不能从“支持 SSE”推导出已经具有实时音视频链路。

用了 Streamable HTTP，模型就能逐字输出了吗？

还需要模型接口、应用和前端各自支持增量生成与展示。MCP 的进度通知或最终工具结果，与模型文本增量不是同一种消息语义。

对应教程

MCP 模型上下文协议：两类常见传输：§5.3 对比本地子进程与独立 HTTP 服务，并说明旧 SSE 案例的兼容背景，适合先建立部署与传输的基本关系，再对照协议版本细节。

参考资料

国内：JavaGuide：MCP：依据 stdio 与 Streamable HTTP 对子进程、HTTP 请求和响应类型的约定，说明正文中两种传输的实现区别及 stdout 混入日志的故障。
国内：WeThinkIn：MCP 与 A2A 协议高频考点：采用本地工具与远程共享服务的选型条件，说明正文中通信方式如何对应部署位置和访问范围。
国内：Datawhale：智能体通信协议：借鉴客户端进程命令与服务 URL 配置示例，说明正文中两类连接入口的区别；旧版封装与 SSE 演示按其版本理解。
国外：MCP 2026-07-28：stdio：依据换行分帧、标准输出、请求关联与进程关闭规则，说明正文中本地传输的解析与生命周期处理。
国外：MCP 2026-07-28：Streamable HTTP：依据 JSON、请求级 SSE、订阅和取消约定，解释正文中“可流式”为何不等于旧 GET 流、会话恢复或模型 Token 流。