MCP 协议迎来重大更新：走向完全无状态化，简化 HTTP 通信

核心要点： MCP 协议通过引入 “流式 HTTP” 传输方案，实现了完全无状态化，并简化了通信方式，为未来更广泛的应用奠定了基础。

近日，消息通道协议 (MCP) 的一项关键技术改进提议获得通过，预示着这项新兴协议将迎来更广阔的应用前景。本次更新的核心在于革新 MCP 的数据传输方式，使其能够完全实现无状态化，并简化为使用普通的 HTTP 协议进行通信。

背景：HTTP+SSE 的局限性

此前，MCP 协议采用 HTTP 加 SSE (服务器发送事件) 的方式传输数据。这种方式存在一些局限性：

• 不支持断线重连
• 服务器需保持长连接以确保稳定
• 服务器消息仅能通过 SSE 发送

革新方案：流式 HTTP

为了解决上述问题，社区提出了 “流式 HTTP” 传输方案。该方案包含以下关键调整：

• 取消 /sse 接口： 所有客户端到服务器的消息统一通过 /message (或类似的) 接口传输。
• 请求升级为 SSE： 服务器可将客户端请求升级为 SSE 连接，用于实时推送通知或数据。
• 会话 ID 管理： 客户端在 HTTP 请求头中提供会话 ID，服务器可选择性地利用该 ID 识别会话。
• 启动 SSE 流： 客户端可向 /message 接口发送空 GET 请求，建立 SSE 数据流。

这些改进使 MCP 服务器能够实现完全无状态化，无需长期保持连接，显著降低了服务器复杂性和资源消耗。同时，纯 HTTP 协议的应用提升了 MCP 的兼容性，使其能更好地融入现有网络设施和中间件。

社区积极响应

这项改进提议受到了 MCP 社区的广泛欢迎和积极反馈。Shopify、Pydantic、Cloudflare、LangChain、Vercel 以及 Anthropic 团队等众多机构和个人都为此贡献了宝贵意见。

无状态化的多重优势

无状态化是本次 MCP 协议更新的核心亮点，它为 MCP 带来了多重优势：

• 简化部署与维护： 无需处理会话数据的持久化和同步，服务器部署和扩展更简便。
• 提升系统稳定性： 单个服务器故障不影响系统整体运行，更易实现高可用性。
• 降低资源消耗： 无需维护长连接和会话状态，服务器资源占用和成本均降低。

应用场景展望

无状态 MCP 的实现为众多应用场景开启了新的可能性：

• 无状态工具服务器： 可构建完全无状态的 MCP 服务器，仅提供语言模型工具功能，无需状态管理，简化工具调用流程。
• 支持流式响应的无状态服务器： 即使无状态服务器，亦可利用 SSE 提供流式响应，例如在工具执行期间实时推送进度信息。

为何选择流式 HTTP 而非 WebSocket？

在传输方案选择上，WebSocket 也曾被考虑，但最终社区选择了 “流式 HTTP”，主要基于以下考量：

• RPC 场景的开销： 对于简单的 RPC (远程过程调用) 场景，强制使用 WebSocket 会引入不必要的运维和网络负担。
• 浏览器兼容性： 浏览器环境下，WebSocket 在 HTTP 请求头设置和第三方库实现方面不如 SSE 灵活。
• 协议升级复杂性： WebSocket 仅支持 GET 请求升级，POST 请求升级过程复杂，增加延迟。
• 协议规范精简： MCP 协议规范倾向于限制官方传输协议种类，以避免兼容性问题。

安全性的探讨

无状态化虽带来诸多优势，但也引发了关于安全性的讨论，特别是会话 ID 管理和授权方面。

部分开发者指出，若服务器使用 Mcp-Session-Id 请求头管理会话，应将会话 ID 与授权环境绑定，防止其在不同授权环境中被滥用。这意味着会话 ID 应与特定用户或客户端会话关联，而非全局通用。

对于追求极简服务器的开发者，复杂的身份验证机制可能并不适用。在有状态模式下，HTTP 请求本身可视为会话边界。但在无状态模式下，如何在无 HTTP-only Cookie 情况下安全管理会话，仍需关注。

有开发者建议引入 HTTP-only Cookie 管理客户端会话，并为每个客户端会话分配唯一 ID，再在其下管理多个 MCP 会话 ID，实现分层会话管理，兼顾安全性和灵活性。

总结与展望

MCP 协议向无状态化的演进是迈向实用化和易用性的重要一步。“流式 HTTP” 方案的采用，有望降低 MCP 部署门槛，吸引更多开发者和应用场景。尽管安全性方面仍有讨论空间，但相信随着社区不断完善，MCP 协议的未来值得期待。

相关提案