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 传输方式的渐进式改进
  
• 灵活的传输方式：服务器可选择是否使用 SSE 进行流式响应
  

从 HTTP+SSE 到 Streamable HTTP 的变化

• 移除了 /sse 端点
  
• 所有客户端 → 服务端的消息都通过 /message（或类似端点）发送
  
• 所有客户端 → 服务端的请求都可以被服务器升级为 SSE，以发送通知或请求
  
• 服务器可以选择建立会话 ID 以维护状态
  
• 客户端可以通过对 /message 发送一个空的 GET 请求启动 SSE 流
  
• 该方法兼容旧版本的实现，并允许服务器保持无状态（如果有需要）
  

Streamable HTTP请求示例

无状态服务器模式

场景：简单工具 API 服务，如数学计算、文本处理等。
实现：
[code]客户端                                 服务器   |                                    |   |-- POST /message (计算请求) -------->|   |                                    |-- 执行计算   ||   |                                    |-- 启动处理任务   |