大家通过上面这张图简单了解一下什么是MCP
MCP协议迎来重大更新，引入了全新的Streamable HTTP传输机制。这一更新解决了当前HTTP+SSE传输方式的关键限制，同时保留了其优势。这项改进得益于来自Shopify、Pydantic、Cloudflare、LangChain、Vercel、Anthropic团队及MCP社区众多成员的宝贵反馈。
主要变更
与当前HTTP+SSE传输相比，新版本有以下变化：
- 移除了`/sse`端点
- 所有客户端→服务器消息通过`/message`(或类似)端点传输
- 所有客户端→服务器请求都可由服务器升级为SSE，用于发送通知/请求
- 客户端在请求头中提供会话ID；服务器可根据需要关注此ID
- 客户端可通过空GET请求到`/message`端点来初始化SSE流
这种方法可以向后兼容实现，并允许服务器根据需要完全无状态运行。
更新动机
当前的远程MCP通过HTTP+SSE传输工作，存在以下问题：
- 不支持恢复性
- 要求服务器维护高可用性的长连接
- 服务器消息只能通过SSE传递
主要优势
1. 无状态服务器可行性：不再需要高可用性的长连接
2. 纯HTTP实现：MCP可在纯HTTP服务器中实现，无需SSE支持
3. 基础设施兼容性：仅是"普通HTTP"，确保与中间件和基础设施兼容
4. 向后兼容：现有传输机制的增量演进
5. 灵活升级路径：服务器可根据需要使用SSE进行流式响应
应用场景
无状态服务器
一个完全无状态的服务器可以不支持长连接：
- 始终确认初始化（无需保存状态）
- 通过单个JSON-RPC响应处理工具列表请求
- 执行工具调用请求，完成后将响应作为HTTP响应体返回
带流式处理的无状态服务器
无状态服务器仍可利用流式处理：
- 接收工具调用请求时，服务器指示响应将使用SSE
- 执行工具时发送进度通知
- 工具执行完成后发送响应并关闭SSE流
有状态服务器
类似当前实现，但需要处理会话ID头，以便在水平扩展部署中正确路由消息。
为何不选择WebSocket
团队详细讨论了将WebSocket作为主要远程传输的可能性，但决定暂不采用，原因如下：
- 在"RPC式"使用场景下会产生不必要的运营和网络开销
- 浏览器无法附加授权等头信息
- 只有GET请求可透明升级到WebSocket，需要复杂的两步升级过程
总结
此次更新为MCP协议带来更高的灵活性和稳健性，使其能够适应更广泛的应用场景。虽然当前选择了基于HTTP的方案，但未来仍可能探索WebSocket等其他传输方式。
通过这次技术升级，MCP协议将更好地满足现代应用架构的需求，为开发者提供更强大、更可靠的消息通信能力。
