MCP 协议与传输方式：stdio、Streamable HTTP 与旧版 SSE

本文依据 Model Context Protocol 官方规范整理，核验日期：2026-05-25。协议仍在演进，开发时应以官方规范当前版本为准。

MCP 解决什么问题

Model Context Protocol（MCP）用于让应用以统一方式连接工具、资源与上下文提供方。它关注消息格式、生命周期与能力协商，而不是规定某一个特定模型或 Agent 框架必须如何实现。

MCP 消息使用 JSON-RPC 编码。对于客户端与服务端之间的连接方式，当前规范定义了两种标准传输：

1. stdio；
2. Streamable HTTP。

stdio：本地子进程方式

在 stdio 传输中，客户端启动 MCP Server 子进程，通过标准输入和标准输出交换 JSON-RPC 消息。这种方式适合本地工具、桌面客户端或命令行集成：

• 部署简单；
• 不需要额外开放网络端口；
• 进程生命周期由客户端管理；
• 服务端不得向 stdout 输出非 MCP 消息，日志应写到 stderr。

Streamable HTTP：当前远程连接主线

对于独立运行、可能服务多个客户端的 MCP Server，当前规范使用 Streamable HTTP。服务端提供一个同时支持 POST 与 GET 的 MCP endpoint，例如 /mcp：

• 客户端通过 HTTP POST 发送 JSON-RPC 消息；
• 服务端可以返回单个 JSON 响应，也可以用 SSE 流式返回多条消息；
• 客户端可以使用 GET 打开服务器到客户端的 SSE 流；
• 有状态会话可以使用 Mcp-Session-Id 管理。

这里需要区分：SSE 仍可能作为 Streamable HTTP 中的响应流机制使用，但旧的“HTTP+SSE transport”已经不是当前规范的主线。

旧版 HTTP+SSE 的兼容关系

官方规范明确说明，Streamable HTTP 取代了 2024-11-05 协议版本中的旧 HTTP+SSE transport。为了兼容旧客户端或旧服务器，实现者仍可以同时保留旧端点，但新实现不应继续把旧 HTTP+SSE 当作默认架构描述。

安全注意事项

官方规范针对 Streamable HTTP 特别提示：

• 服务端应验证 Origin，降低 DNS rebinding 风险；
• 仅供本机使用的服务应优先绑定 127.0.0.1，而不是直接监听所有网卡；
• 所有连接应采用适当的认证与授权机制；
• 对外开放的工具调用能力尤其需要控制权限范围。

参考来源

• MCP 官方传输规范：https://modelcontextprotocol.io/specification/2025-06-18/basic/transports
• MCP 官方文档入口：https://modelcontextprotocol.io/

本文只做协议结构说明，不代表本站已经部署或验证了某个具体 MCP Server 实现。