MCP 的 stdio 和 Streamable HTTP 有什么区别？“流式”到底指什么？
🧑💻 面试官：MCP Server 提供了查询订单工具，Client 怎样调用它？
🙋♂️ 我：可以用 stdio，也可以通过 Streamable HTTP 连接。
🧑💻 面试官：如果这个服务由别的团队部署在远程服务器上，还适合让我的应用直接用 stdio 吗？
🙋♂️ 我：这种情况更适合 HTTP。
🧑💻 面试官：那名字里有 Streamable，是不是工具一调用，模型的回答就会逐字显示出来？
这里要分清：「消息怎样传」和「答案怎样生成」。MCP 的传输方式，不等于模型的 Token 输出方式，也不保证工具会连续返回业务结果。
面试速答（60 秒版）
stdio 和 Streamable HTTP 都是 MCP 的传输方式，区别主要是 Client 和 Server 怎样连接、怎样交换消息。
stdio 通常由应用启动本地 MCP Server 子进程，通过标准输入发送消息，通过标准输出接收消息。它比较适合由应用管理的本地工具。
Streamable HTTP 则通过 HTTP 连接独立运行的服务，更适合远程部署和多个客户端访问。服务端可以返回普通 JSON，也可以用 SSE 连续发送消息。
但“可以流式传输”不代表模型答案一定逐字生成，也不代表工具每完成一点工作，就自动返回一点业务结果。
实际接入时，还需要核对协议版本。MCP 的新版传输规范调整过会话和流连接方式，不能把旧教程里的 GET 长连接、会话标识直接当成所有版本都必须使用的机制。
知识点详解：两种传输方式到底连接了什么？
先把工具能力和传输方式分开
假设一个 MCP Server 提供两个工具：读取文件、查询订单。
工具定义告诉应用，这两个操作叫什么、需要哪些参数。传输方式则负责让 Client 把请求送到 Server，并把消息带回来。
因此，同样的工具能力，可以采用不同的传输方式提供。不能因为服务使用 HTTP，就认为它比 stdio 更“智能”；也不能因为服务在本地运行，就认为工具只允许读取本地文件。
工具最终能访问什么，由它自己的实现和权限决定。传输解决的是两端怎样通信。
stdio：应用启动一个进程，通过输入输出交换消息
如果咱们要在本地 AI 应用中接入一个文件工具，可以让应用启动 MCP Server 子进程。
Client 把协议消息写入子进程的标准输入，Server 把消息写到标准输出，Client 再读取。这里传递的是 MCP 使用的 JSON-RPC 消息，不是模拟人在终端里输入自然语言。
stdio 规范要求消息按换行分隔，标准输出只能写协议消息。因此，服务端的调试日志应该写到标准错误，不能随手打印到标准输出，打断 Client 的解析。
这种方式不需要为了本地通信专门开放 HTTP 端口，进程的启动和退出也可以由应用管理。
不过，它仍然是一个真实执行的程序。启动文件工具前，需要检查运行文件、权限和能够访问的目录。使用 stdio，不等于进程天然安全。
Streamable HTTP：服务独立运行，Client 通过网络发送请求
如果查询订单服务已经部署在另一台服务器，多个 AI 应用都需要访问，让每个应用再启动一份本地进程就不一定合适。
这时候，可以通过 Streamable HTTP 接入。Server 独立运行，Client 向 MCP 端点发送 POST 请求，并处理返回消息。
按本篇采用的 2026-07-28 规范 ，一个请求的响应可以是普通 JSON，也可以是 SSE。使用 SSE 时，服务端可以在请求处理期间发送进度等通知，再返回最终结果。Streamable HTTP 规范明确允许这两种响应形式。
这里的 SSE 是 HTTP 响应中的事件流，不是 stdio 的网络版，也不是一个能在同一条 SSE 连接上任意双向发送消息的通道。Client 发起的新请求，仍然通过对应的 HTTP 请求送出。
网络服务还需要处理身份认证、访问权限、连接失败和部署配置。传输规范不会替订单系统判断“这个用户能否查看这个订单”。
“流式”不代表逐字输出，而且必须注意版本
咱们把三个容易混淆的东西放在一起：
| 说法 | 实际要判断什么 |
|---|---|
| MCP 响应用 SSE | 协议消息是否通过事件流传输 |
| 工具报告处理进度 | 工具和应用是否实现了进度通知 |
| 模型逐字输出答案 | 模型接口和前端是否支持并正确处理流式内容 |
例如，订单工具只需要一次查询就得到结果，可以直接返回 JSON。生成大报表时，服务端也许会报告进度，但客户端收到进度以后，是否展示给用户，仍然取决于应用。
同样，模型可以在工具返回以后，再使用自己的流式接口输出解释。这是另外一段过程，不能因为接了 Streamable HTTP，就认为已经自动打通了。
还要特别注意：网上常见的旧实现，可能使用 GET 建立 SSE 流、维护 Mcp-Session-Id ，或者介绍重连后的事件恢复。2026-07-28 规范已移除 GET 流端点和协议会话，长时间通知采用的连接方式也发生了变化。
这不表示旧服务突然都不能用了。接入时，先确认 Client 和 Server 对应的规范及 SDK 版本，再按那个版本处理。文章里讲清版本，是为了避免把两代实现混在一起，而不是要求项目为了新名字立即迁移。
面试官继续追问
stdio Server 可以调用远程订单接口吗？
可以。stdio 规定的是 Client 和这个 Server 进程怎样交换消息，不限制 Server 内部一定只能做本地操作。
不过，远程订单接口的认证、网络失败和调用权限，仍然需要工具实现自己处理。
Streamable HTTP 就一定比 stdio 慢吗？
不能只按名称判断。
HTTP 可能增加网络等待，但工具本身执行多久、服务是否复用连接、服务端是否排队，都影响总耗时。选型先看部署和连接需求，再测实际任务，不把传输名称当成性能结论。
MCP Server 连上了，是不是就可以直接执行所有工具？
不是。连接成功，只证明能够通信。
应用还需要决定允许哪些工具、核对参数和用户权限，高风险操作还可能需要确认。不能把“工具发现成功”当成“操作获得授权”。
面试速记卡
- stdio：应用通常启动子进程，通过标准输入输出交换协议消息。
- 日志约束：标准输出留给 MCP 消息，调试日志不要混进去。
- Streamable HTTP：通过 HTTP 接入独立服务，响应可以是 JSON 或 SSE。
- 流式边界：消息流、工具进度和模型 Token 流是不同的事。
- 版本检查：本篇采用 2026-07-28，旧会话与 GET 流不能直接套用。
- 权限判断：连接和发现工具，不等于用户被允许执行操作。