探索 MCP 传输的未来

当 MCP 于 2024 年 11 月首次发布时，相当多的用户依赖本地环境，通过 STDIO 将客户端连接到服务器。随着 MCP 成为 LLM 集成的首选标准，社区需求不断演变，导致围绕远程服务器构建基础设施。现在对于可以大规模运行的分布式部署的需求日益增长。

可流式 HTTP 传输是向前迈出的重要一步，实现了远程 MCP 部署并解锁了新的用例。然而，随着企业部署扩展到每天数百万次请求，早期采用者遇到了实际挑战，使得难以利用现有的基础设施模式。有状态连接的摩擦已成为托管服务和负载均衡的瓶颈。

其中一些挑战包括：

• 基础设施复杂性：负载均衡器和 API 网关必须解析完整的 JSON-RPC 负载来路由流量，而不是使用标准的 HTTP 模式。
• 扩展摩擦：有状态连接强制"粘性"路由，将流量固定到特定服务器，阻碍有效的自动扩展。
• 简单工具的高门槛：构建简单、临时工具的开发人员通常需要管理复杂的后端存储以支持基本的多轮交互。
• 会话范围模糊：没有可预测的机制来定义对话上下文在分布式系统中的开始和结束位置。

路线图

在过去几个月中，传输工作组与社区和 MCP 核心维护者合作，开发了解决这些挑战的方案。

在这篇文章中，我们分享了可流式 HTTP 传输演进的路线图，并邀请社区反馈来帮助塑造 MCP 传输的未来。

无状态协议

MCP 最初被设计为一个有状态协议。客户端和服务器通过持久的双向通道保持相互感知，该通道以交换能力和协议版本信息的握手开始。由于此状态在整个连接中保持固定，扩展需要粘性会话或分布式会话存储等技术。

我们设想一个未来，其中代理应用程序是有状态的，但协议本身不需要是无状态的。无状态协议实现扩展，同时在需要时仍提供支持有状态应用程序会话的功能。

我们正在探索通过以下方式使 MCP 无状态：

• 替换 initialize 握手，并在每个请求和响应中发送共享信息。
• 提供 discovery 机制，让客户端查询服务器能力（如果它们需要尽早获取信息），例如 UI 水合场景。

这些更改启用了更动态的模型，其中客户端可以乐观地尝试操作，如果不支持某项功能，则会收到明确的错误消息。

注意：许多 SDK 在其服务器传输配置中已经提供了 stateless 选项，尽管行为在不同实现中有所变化。作为此路线图的一部分，我们将致力于在所有官方 SDK 中标准化"无状态"的含义，以确保一致的行为。

提升会话

目前，会话是传输连接的副作用。使用 STDIO，会话隐含在进程生命周期中；使用可流式 HTTP，会话在服务器初始化期间分配 Mcp-Session-Id 时创建。这可能导致传输层和应用层关注点之间的混淆。

我们正在考虑将会话移至 数据模型层，使它们显式而不是隐式。

这将允许 MCP 应用程序将会话作为其域逻辑的一部分来处理。我们正在探索几种方法，其中类似 cookie 的机制是一个潜在的候选者，用于将会话状态与传输层解耦。

这个方向反映了标准 HTTP，其中协议本身是无状态的，而应用程序使用 cookie、令牌和类似机制构建有状态语义。会话创建的确切方法仍在设计中，目标是消除远程 MCP 场景中会话含义的现有模糊性。

引导和采样

两个 MCP 功能是现代 AI 工作流程的核心：引导，请求人工输入，以及采样，启用代理 LLM 交互。

大规模支持这些功能需要重新思考它们依赖的双向通信模式。目前，当服务器需要更多信息来完成工具调用时，它会暂停执行并等待客户端响应，需要它跟踪所有未完成的请求。

为了解决这个问题，我们正在考虑设计服务器请求和响应，使其类似于聊天 API。服务器照常返回引导请求，客户端同时返回请求 和 响应。这允许服务器纯粹从返回的消息中重建必要的状态，避免节点之间的长时间状态管理，并可能完全消除对后端存储的需求。

更新通知和订阅

MCP 在设计上是动态的 - 工具、提示词和资源可以在操作期间更改。目前，服务器向客户端发送 ListChangedNotification 消息，作为使其缓存失效的提示。

我们正在探索用显式订阅流替换通用 GET 流。客户端将为其想要监视的特定项目打开专用流，支持多个并发订阅。如果流中断，客户端只需重新启动它，无需复杂的恢复逻辑。

为了使通知真正可选 - 作为优化而不是要求 - 我们正在考虑向数据添加生存时间（TTL）值和版本标识符（如 ETags）。这将允许客户端独立于通知流做出智能缓存决策，显著提高可靠性。

JSON-RPC 信封

MCP 对所有消息信封使用 JSON-RPC，包括方法名和参数。当我们为 HTTP 部署进行优化时，一个常见的问题是路由信息是否应该更容易访问底层 MCP 服务器基础设施。

虽然我们将 JSON-RPC 保留为消息格式，但我们正在探索通过标准 HTTP 路径或标头暴露路由关键信息（如 RPC 方法或工具名）的方法。这将允许负载均衡器和 API 网关在不解析 JSON 正文的情况下路由流量。

服务器卡

目前，客户端必须完成完整的初始化握手才能了解 MCP 服务器的基本信息，如其能力或可用工具。这给发现、集成和优化场景带来了摩擦。

我们正在探索引入 MCP 服务器卡的方向：结构化元数据文档，服务器通过标准化的 /.well-known/mcp.json 端点暴露。服务器卡使客户端能够在建立连接 之前 发现服务器能力、身份验证要求和可用的原语。这解锁了用例，如自动配置、自动发现、静态安全验证和减少 UI 水合的延迟——所有这些都不需要完整的初始化序列。

官方和自定义传输

为了确保整个生态系统的最低兼容性基线，MCP 将继续仅支持两种官方传输：用于本地部署的 STDIO 和用于远程部署的可流式 HTTP。这保持了核心生态系统的统一，其中每个 MCP 客户端和服务器都可以开箱即用地互操作。

我们也认识到传输和协议变更可能会造成破坏。向后兼容性是优先事项，我们只会在关键用例绝对必要时引入重大更改。

对于有特殊需求的团队，MCP 规范支持自定义传输，为开发人员提供了构建适合其需求的替代方案的灵活性。我们的重点是通过改进 SDK 集成使自定义传输更容易实现——以便社区可以自由实验，而不会分散标准。

总结

这些更改将 MCP 重新定位为无状态、独立的请求——而不牺牲使其强大的丰富功能。服务器开发人员获得更简单的水平扩展，无需粘性会话或分布式存储。客户端获得更可预测的架构。

对于大多数 SDK 用户，无论是客户端还是服务器端，影响都将是最小的——我们专注于将重大更改减少到绝对最小。我们概述的转换是架构性的：更简单的部署、高级 MCP 功能的无服务器可行性，以及与现代基础设施模式的更好对齐。

下一步

工作已经在进行中。我们的目标是在 2026 年第一季度最终确定所需的规范增强提案 (SEP)，以包含在下一个规范版本中，该版本暂定于 2026 年 6 月发布。通过这些更改，MCP 可以轻松扩展，同时保持使其成功的人机工程学。

我们需要您的意见。在 MCP 贡献者 Discord 服务器中加入我们，或直接在 Model Context Protocol 存储库中参与传输相关的 SEP。

此路线图由使用 MCP 构建的开发人员和公司的真实反馈塑造。我们很高兴与 MCP 社区合作，不断改进协议及其功能！