MCP Streamable HTTP：面向远程智能体连接的单端点传输规范
Streamable HTTP 是 MCP 在 2025-03-26 规范中引入的远程传输方式，以单一 HTTP 端点统一消息提交与可选 SSE 流，替代旧版 HTTP+SSE，并明确了会话恢复、版本兼容和基础安全要求。
MCP Streamable HTTP transport mcp agent-protocol interoperability protocol-testing Streamable HTTP 是 MCP 在 2025-03-26 规范中引入的远程传输方式，以单一 HTTP 端点统一消息提交与可选 SSE 流，替代旧版 HTTP+SSE，并明确了会话恢复、版本兼容和基础安全要求。
1. 项目定位
Streamable HTTP 是 Model Context Protocol（MCP）的标准传输方式之一，用于客户端与独立运行的服务器进程通过网络交换 JSON-RPC 消息。它在 2025-03-26 版规范中取代旧版 HTTP+SSE 传输，是该次规范的主要变化之一。[S1][S2]
2. 核心机制
服务器必须提供一个同时支持 POST 与 GET 的 MCP 端点。客户端用新的 HTTP POST 提交每条 JSON-RPC 消息；服务器可以直接返回 JSON，也可以用 Server-Sent Events（SSE）连续发送多条消息。GET 则可用于打开由服务器发起的 SSE 流。[S1]
3. 响应与会话
客户端请求需要声明接受 application/json 与 text/event-stream。只有响应或通知的提交被接受时，服务器可返回无正文的 202；包含请求的提交则按规范返回 JSON 或 SSE。[S1] 服务器还可分配会话标识，客户端后续请求携带该标识，使有状态会话与重连成为可能。
4. 适用场景
它适合远程 MCP 服务、共享工具网关、需要流式进度的长任务，以及服务器主动通知客户端的连接。纯本机、由客户端拉起的短生命周期工具通常仍适合 stdio；规范也建议客户端在可能时支持 stdio。[S1] 两种传输不必二选一，可按部署边界分别提供。
5. 部署路径
最小实现先提供单一 HTTPS 端点，完成 POST 请求、JSON 响应和无状态调用，再按需要加入 SSE、会话与恢复。网关层应保留 MCP 协议版本、会话标识、请求 ID、响应类型和耗时，但日志中不应直接记录密钥、完整提示或工具返回的敏感数据。
6. 兼容性
2025-03-26 规范明确 Streamable HTTP 替换 2024-11-05 的 HTTP+SSE。[S1][S2] 为兼容旧客户端，服务器可在旧 SSE 端点与新 MCP 端点之间采用过渡方案，但应把支持范围写进能力说明，并通过协议版本协商避免把旧行为静默解释为新行为。
7. 安全要求
官方规范要求服务器验证所有连接的 Origin，本机运行时只绑定 127.0.0.1，并建议实施适当认证；这些措施用于降低 DNS rebinding 等攻击风险。[S1] 生产环境还应限制工具权限、请求体大小、并发和超时，并把高风险工具置于独立授权层。
8. 评估与验收
协议测试至少覆盖：JSON 与 SSE 两种响应、通知的 202、错误状态码、断线重连、会话终止、并发请求、版本不匹配和非法 Origin。验收不只看“能连通”，还要检查重复消息是否幂等、断线后是否丢事件、代理缓存是否干扰流，以及认证失败是否会泄露服务细节。
9. 结论
Streamable HTTP 的关键价值是用一个端点覆盖简单请求、流式响应和服务器通知，降低远程 MCP 部署的传输分裂。实现难点主要在会话、重连、代理行为和安全边界，因此团队应从最小无状态实现开始，再用明确测试逐层开放流式与持久能力。
10. 来源与更新时间
本文研究日期与信息截止日期均为 2026-08-07，核心行为以 2025-03-26 版官方规范为准。接入其他版本时应重新核对对应版本规范与变更记录。