MCP协议Streamable HTTP

一、概述

2025 年 3 月 26 日，模型上下文协议(Model Context Protocol，简称 MCP)引入了一项关键更新：用 Streamable HTTP 替代原先的 HTTP + SSE 作为默认传输方式。
这一变更在解决原有方案中连接不可恢复、服务端长连接压力大等问题的同时，依然保留了 SSE 带来的流式响应优势。

HTTP + SSE 的缺陷

远程 MCP 通过 HTTP + SSE 的传输方式工作，存在以下问题，这也是它所被替换的根本原因：

• 不支持恢复连接
• 要求服务器保持高可用的长连接
• 服务器只能通过 SSE 发送消息

不支持恢复连接

如果客户端和服务器之间的 SSE 连接中断了，就无法 “从端点继续”，只能重新开始新的连接，之前的上下文可能会丢失。

要求服务器保持高可用的长连接

服务器必须一直保持一个稳定、不中断的 SSE 长连接，否则通信就中断。

服务器只能通过 SSE 发送消息

服务器无法在已有的请求之外，主动地发送消息给客户端，除了通过专门的 /sse 通道。换句话说，它是“单向被动响应”，而不是“任意时机推送”。

二、Streamable HTTP

Streamable HTTP 并不是传统意义上的 流式 HTTP(Streaming HTTP)，它指的是一种 兼具以下特性的传输机制：

• 以普通 HTTP 请求为基础，客户端用 POST/GET 发请求；

• 服务器可选地将响应升级为 SSE 流，实现 流式传输 的能力(当需要时)；

• 去中心化、无强制要求持续连接，支持 stateless 模式；

• 客户端和服务端之间的消息传输更加灵活，比如同一个 /message 端点可用于发起请求和接收 SSE 流；

• 不再需要单独的 /sse 端点，一切通过统一的 /message 协议层处理。

Streamable HTTP 的优势

• 支持无状态服务器：无需维持高可用的长连接

• 纯 HTTP 实现：MCP 可在纯 HTTP 服务中实现，无需 SSE 支持

• 兼容基础设施：因为 “只是 HTTP”，可以与中间件和现有基础设施良好集成

• 向后兼容：是当前 HTTP+SSE 传输方式的渐进式改进

• 灵活的传输方式：服务器可选择是否使用