MCP 协议新路线图：Agentic 消息原语与传输统一

今天我们很高兴发布更新版路线图适用于模型上下文协议（MCP），涵盖下一个规范版本及之后。

路线图为未来几个月的议定书工作设定了方向。它由核心维护者与我们的维护者社区及工作组共同开发。

探索路线图→

优先区域

路线图分为五个优先领域。其中几位接手的工作之前的路线图列为即将到来的项目，包括服务器发起的事件、结果类型改进和代理身份，这些内容后来已经足够成熟，成为独立的优先事项。

每个领域由一组核心维护者和一个或多个工作组拥有。

代理消息原语

现代代理工作负载已不再符合这一标准请求与响应模式.循环可以运行更长时间，服务器可以推送流式结果，而且显然需要在工作过程中进行引导。

MCP不断发展以满足这些需求，推出了任务,subscriptions/listen， 和进度通知.我们不仅要提供合适的原件，还要确保它们能很好地协同工作。

这里的工作涵盖服务器发起的事件（webhook和通道，这样客户端就不用轮询结果）、在代理人、 传输 和触发因素与事件工作组，以及任务扩展的成熟化（2663年9月因此它可以进入规范。

HTTP原生传输统一与加固

与2026-07-28 发布远程MCP服务器现在与其他HTTP工作负载无异，便于在开发者和组织已用于API和服务的任何基础设施上托管和运行。该模型已被证明具有可扩展性，我们希望将其扩展到涵盖其他部署模式，包括本地服务器发声可流式HTTP完毕标准.统一在同一传输平台上，我们可以进一步简化MCP服务器和客户端的开发。

代理身份与企业级安全

MCP授权如今，人们只需在浏览器中批准访问权限。这对互动客户端效果不错，但越来越多的来电者是作为云工作负载运行的代理，拥有自己的身份，代表不在场的用户，或将更狭窄的权限委托给子代理。

我们希望MCP服务器能够有一种标准化的方式来识别和信任这些代理身份，这种方式建立在现有标准之上，而不是粘贴API密钥和长期令牌。

这里的工作内容包括最终定稿展示占有权的证据（DPoP）并推动其采纳，并定义了代理身份和委托的主观路径工作负载身份联合背后是ID-JAG的资助企业管理授权以及标准代币兑换。

我们还将继续加强与OAuth标准机构的合作，包括IETF OAuth和温姆斯工作组，帮助底层标准与代理身份所需的构建模块一起演进。

改进原语

工具调用是MCP中大多数开发者首先接触的部分，并且在协议生命周期内表现良好。不过，它稍显不足的是操控效果。Atools/call响应可以以多种形式承载相同的输出，而如今的服务器开发者无法知道客户端会在模型前放置哪种形式。

我们旨在通过统一统一一个明确的合同来简化此过程。

我们需要解决原始使用时的另一个挑战是它们不断扩大的规模。连接到一个有一百个工具的服务器意味着模型在用户提出一个问题之前就已经支付了整个桌面费用，而随着工具列表的增加，工具选择往往会变得更差。

我们正在启动一个渐进式发现项目，让服务器提供一个小切入点，随着对话的缩小，逐步揭示更多目录内容。

提升SDK开发者体验

我们的SDK是开发者体验MCP的方式。我们正在投资他们的人体工学和符合规范并且让它们直观且文档详尽，覆盖我们支持的每一种平台和语言。

现在，许多开发者通过将代理指向我们的库来构建MCP客户端和服务器，通过清晰的API和准确的文档决定代码是否能以最小的摩擦工作，这一点更加重要。

提案优先级

规范增强提案属于这些优先领域的（SEP）会获得加速审核，并且有最佳的接受机会。外部提案不会自动被拒绝，但维护者审核时间有限，优先进入路线图。

如果你考虑SEP，先确定它属于哪个优先领域，并向相关部门提出工作组并与其成员合作，共同塑造你的提案。每个区域路线图并列出负责核心维护者的名字，任何有兴趣贡献的人都可以通过以下方式联系他们Discord.我们很高兴与社区合作，审查并完善支持该路线图的提案。

参与进来

上述每个优先领域背后或围绕其成立的工作组，且所有工作组都有更多贡献者的空间。参与方式有多种：

• 加入工作组或兴趣小组：参见工作与利益小组页面和社区频道.
• 提出或如何得MS：请阅读SEP指南然后打开一个或称重。
• 开始一个实验性扩展:2133年9月让任何工作组或督察组在experimental-ext-在正式SEP之前的仓库。
• 直接贡献： the贡献指南涵盖规范、SDK和工具。

我们期待共同成长和发展MCP！