最近，MCP协议迎来了一次重大升级——全新的Streamable HTTP传输机制正式引入。没错，这次改动可不是小打小闹，它直接化解了当前HTTP+SSE传输方式的诸多限制，同时完整保留了原有的优势。那么，这项改进具体带来了哪些变化？背后又蕴含着怎样的设计考量？
先简单回顾一下这张图，帮助你快速了解MCP协议的基本框架。
值得一提的是，这次更新离不开Shopify、Pydantic、Cloudflare、LangChain、Vercel、Anthropic团队以及MCP社区众多成员的热心反馈。可以说，这是一场真正的“集体共创”式演进。
主要变更：从端点设计到会话管理
与现有的HTTP+SSE传输相比，新版Streamable HTTP做出了几个关键调整：
- 移除了`/sse`端点：这个旧的路径标识直接被取消了。
- 所有客户端到服务器的消息，现在统一通过`/message`（或类似端点）来传输。
- 所有客户端到服务器的请求，都可以由服务器主动升级为SSE，用于发送通知或发起请求——控制权交回给服务器。
- 会话ID由客户端在请求头中提供，服务器可以根据自身需求决定是否关注这个ID。
- 客户端还可以通过向`/message`端点发送一个空GET请求，来初始化SSE流。
这样一来，新方案既实现了向后兼容，也让服务器能够根据需要灵活地保持无状态运行——这才是真正意义上的弹性设计。
更新动机：旧的HTTP+SSE到底卡在哪？
我们先来看看原来的远程MCP通过HTTP+SSE传输时，存在哪些令人困扰的问题：
- 不支持断线恢复：一旦连接中断，整个会话就必须重新开始。
- 要求服务器维护高可用的长连接：这对服务器的硬件资源和网络环境造成了不小的压力。
- 服务器消息只能通过SSE传递：消息传输的通道被锁定，缺乏灵活性。
换个角度来看，正是这些痛点，才催生了本次更新。
主要优势：Streamable HTTP的新意在哪？
- 无状态服务器成为可能：不再需要费力维持高可用的长连接，服务器可以变得更“轻量”。
- 纯HTTP实现：MCP可以在纯HTTP服务器中正常运行，完全不需要依赖SSE支持。
- 基础设施兼容性：它本质上就是“普通HTTP”，所有中间件和基础架构都能无缝集成。
- 向后兼容：不是推倒重来，而是对现有传输机制的渐进式升级。
- 灵活的升级路径：服务器可以根据实际需求，随时启用SSE进行流式响应。
应用场景：不同服务器类型下的玩法
无状态服务器
一个完全无状态的服务器，甚至可以完全不支持长连接：初始化时，它只需要一次性确认（无需保存任何状态）；需要列出工具时，直接通过单个JSON-RPC响应处理；执行工具调用时，完成后便将结果作为HTTP响应体返回。整个流程干净利落。
带流式处理的无状态服务器
即使是无状态服务器，依然可以实现流式处理：当接收到一个工具调用请求时，服务器先主动提示响应将采用SSE；在执行工具的过程中，可以发送进度通知；一旦执行完毕，再发送最终响应，然后关闭SSE流。这相当于一边干活一边向你实时汇报进度。
有状态服务器
有状态服务器类似于当前实现，但需要额外处理会话ID头，确保在水平扩展部署时，消息能够准确路由到对应的会话。
为何不选择WebSocket？
团队在讨论中详细评估了将WebSocket作为主要远程传输方案的可行性，但最终暂时不予采用。原因非常实际：
- 在“RPC式”使用场景下，WebSocket会带来不必要的运营和网络开销。
- 浏览器环境无法为WebSocket附加授权等头部信息。
- 只有GET请求能透明升级为WebSocket连接，这需要复杂的两次握手升级步骤。
说白了，现阶段WebSocket对MCP的使用场景而言，有些“杀鸡用牛刀”的味道。
总结
这次更新让MCP协议的灵活性和稳健性迈上了一个新台阶，能够更从容地应对更广泛的应用场景。尽管当前选择了基于HTTP的方案，但未来依然保留了对WebSocket等其他传输方式探索的可能性。通过这次技术升级，MCP协议将更好地契合现代应用架构的要求，为开发者提供更强大、更可靠的消息通信能力。一句话：更简单、更灵活、更稳定。