New MCP Roadmap / MCP 新路线图

Today we’re excited to publish an updated roadmap for the Model Context Protocol (MCP), covering the next specification release and beyond. It sets the direction for protocol work over the coming months and was developed by the Core Maintainers together with our community of maintainers and Working Groups.

今天，我们很高兴发布模型上下文协议 (MCP) 的更新路线图，涵盖下一个规范版本及未来规划。该路线图设定了未来几个月协议工作的方向，由核心维护者与我们的维护者社区及工作组共同制定。

Priority areas / 优先领域

The roadmap is organized into five priority areas. Several of them pick up work that the previous roadmap listed as on the horizon, including server-initiated events, result type improvements, and agent identity, which have since matured enough to become priorities in their own right. Each area has a set of Core Maintainers responsible for it and one or more Working Groups.

该路线图分为五个优先领域。其中几项工作延续了上一版路线图中提到的“即将开展”项目，包括服务器发起事件、结果类型改进以及智能体身份认证，这些项目现已成熟，足以成为独立的优先事项。每个领域都有一组负责的核心维护者以及一个或多个工作组。

Agentic messaging primitives / 智能体消息原语

Modern agentic workloads no longer fit the standard request-and-response pattern. Loops can run for longer, servers can push streamed results, and there is a clear need to steer work mid-flight. MCP has been growing to meet these requirements, introducing Tasks, subscriptions/listen, and progress notifications. We want to make sure that we not only offer the right primitives for the job, but also that they work well together. The work here spans server-initiated events (webhooks and channels, so clients aren’t left polling for results), a composition review across the Agents, Transports, and Triggers & Events Working Groups, and maturing the Tasks extension (SEP-2663) so it can move into the specification.

现代智能体工作负载已不再局限于标准的请求-响应模式。循环运行时间更长，服务器可以推送流式结果，且在任务执行过程中进行干预的需求日益明确。MCP 一直在发展以满足这些需求，引入了任务 (Tasks)、订阅/监听 (subscriptions/listen) 和进度通知。我们不仅要确保提供合适的原语，还要确保它们之间能够良好协作。相关工作涵盖服务器发起事件（通过 Webhook 和通道，避免客户端轮询结果）、跨智能体、传输以及触发器与事件工作组的组合审查，并推动任务扩展 (SEP-2663) 的成熟，以便将其纳入规范。

HTTP-native transport unification and hardening / HTTP 原生传输的统一与加固

With the 2026-07-28 release, a remote MCP server is now no different from any other HTTP workload, making it easy to host and operate one on any infrastructure that developers and organizations already use for their APIs and services. This approach has proven to scale, and we want to stretch it to cover other deployment modes as well, including local servers speaking Streamable HTTP over stdio. Unifying on one transport lets us simplify MCP server and client development even further.

随着 2026-07-28 版本的发布，远程 MCP 服务器现在与其他 HTTP 工作负载无异，开发者和组织可以轻松地在现有的 API 和服务基础设施上托管和运行 MCP 服务器。这种方法已被证明具有良好的扩展性，我们希望将其扩展到其他部署模式，包括通过 stdio 进行流式 HTTP 通信的本地服务器。统一传输方式将进一步简化 MCP 服务器和客户端的开发。

Agent identity and enterprise-ready security / 智能体身份与企业级安全

MCP authorization today is built around a person approving access in a browser. That works well for interactive clients, but more and more of the callers are agents running as cloud workloads with their own identity, acting on behalf of a user who isn’t present, or delegating narrower authority to sub-agents. We want MCP servers to have a standardized way to recognize and trust those agent identities, built on existing standards rather than pasted API keys and long-lived tokens. The work here covers finalizing Demonstrating Proof of Possession (DPoP) and driving its adoption, and defining an opinionated path for agent identity and delegation through Workload Identity Federation, the ID-JAG grant behind Enterprise-Managed Authorization, and standard token exchange. We will also continue to grow our engagement with the OAuth standards bodies, including the IETF OAuth and WIMSE working groups, to help the underlying standards evolve with the building blocks that agent identity needs.

目前的 MCP 授权机制基于用户在浏览器中批准访问。这对于交互式客户端效果良好，但越来越多的调用者是作为云工作负载运行的智能体，它们拥有自己的身份，代表不在场的用户行事，或将更窄的权限委托给子智能体。我们希望 MCP 服务器拥有一种标准化的方式来识别和信任这些智能体身份，并基于现有标准而非硬编码的 API 密钥或长期令牌。相关工作包括最终确定“持有证明”(DPoP) 并推动其采用，以及通过工作负载身份联邦 (Workload Identity Federation)、企业管理授权背后的 ID-JAG 授权以及标准令牌交换，为智能体身份和委托定义明确的路径。我们还将继续加强与 OAuth 标准机构（包括 IETF OAuth 和 WIMSE 工作组）的合作，帮助底层标准随着智能体身份所需的基础模块而演进。

Improved primitives / 改进原语

Tool calling is the part of MCP most developers touch first, and it has held up well over the lifetime of the protocol. Where it falls a bit short, however, is in the result handling. A tools/call response can carry the same output in more than one form, and a server developer today has no way to know which form a given client will put in front of the model. We aim to make this easier by standardizing on one clear contract. The other challenge we need to address for primitives is their ever-growing scale. Connecting to a server with a hundred tools means the model pays for that entire surface before the user has asked a single question, and tool selection tends to get worse as the list grows. We’re starting a progressive discovery effort so a server can offer a small entry point and reveal more of its catalog as the conversation narrows.

工具调用是大多数开发者接触 MCP 的第一部分，在协议的整个生命周期中表现良好。然而，它在结果处理方面略显不足。一个 tools/call 响应可以以多种形式携带相同的输出，而目前的服务器开发者无法得知客户端会将哪种形式呈现给模型。我们旨在通过标准化单一明确的契约来简化这一过程。我们需要解决的另一个原语挑战是其不断增长的规模。连接到一个拥有上百个工具的服务器意味着模型在用户提出问题之前就必须处理整个工具集，且随着列表增长，工具选择的准确性往往会下降。我们正在启动一项渐进式发现工作，使服务器能够提供一个小的入口点，并随着对话的深入逐步展示其更多目录。

Improved SDK developer experience / 改进 SDK 开发者体验

Our SDKs are how developers experience MCP. We are investing in their ergonomics and their conformance with the specification, and in making them intuitive and well-documented across every platform and language we support. This is even more important now that many developers build MCP clients and servers by pointing an agent at our libraries, where clear APIs and accurate docs decide whether the code will work with minimal friction.

SDK 是开发者体验 MCP 的主要方式。我们正致力于提升其易用性及对规范的符合度，并确保在我们支持的所有平台和语言中，它们都直观且文档齐全。这一点现在尤为重要，因为许多开发者通过让智能体调用我们的库来构建 MCP 客户端和服务器，清晰的 API 和准确的文档决定了代码能否以最小的阻力运行。

Proposal prioritization / 提案优先级

Specification Enhancement Proposals (SEPs) that fall within these priority areas get expedited review and have the best chance of acceptance. Proposals outside them aren’t rejected automatically, but maintainer review time is scarce and goes to these areas first. If you’re considering a SEP, identify the priority area it belongs to, raise it with the relevant Working Group, and work with its members to shape your proposal. Each area on the roadmap names the Core Maintainers responsible for it, and anyone interested in contributing can reach them on Discord. We’re excited to work with the community to review and build on the proposals that support this roadmap.

属于上述优先领域的规范增强提案 (SEP) 将获得快速审查，并有最大的机会被采纳。范围之外的提案不会被自动拒绝，但维护者的审查时间有限，会优先处理这些领域。如果您正在考虑提交 SEP，请确定其所属的优先领域，向相关工作组提出，并与成员合作完善您的提案。路线图中的每个领域都列出了负责的核心维护者，任何有兴趣贡献的人都可以在 Discord 上联系他们。我们很高兴能与社区合作，审查并构建支持此路线图的提案。

Get involved / 参与其中

Every priority area above has a Working Group behind it or forming around it, and all of them have room for more contributors. There are several ways to participate:

• Join a Working Group or Interest Group: see the Working and Interest Groups page and the community channels.
• Propose or comment on a SEP: read the SEP guidelines, then open one or weigh in.
• Start an experimental extension: SEP-2133 lets any WG or IG experiment in an experimental-ext- repository before a formal SEP.
• Contribute directly: the contributing guide covers the specification, SDKs, and tooling.

We look forward to growing and evolving MCP together!

上述每个优先领域背后都有一个工作组，或者正在形成中，它们都需要更多的贡献者。参与方式如下：

• 加入工作组或兴趣小组：查看“工作组与兴趣小组”页面及社区频道。
• 提出或评论 SEP：阅读 SEP 指南，然后提交提案或发表意见。
• 启动实验性扩展：SEP-2133 允许任何工作组或兴趣小组在正式提交 SEP 之前，在 experimental-ext- 仓库中进行实验。
• 直接贡献：贡献指南涵盖了规范、SDK 和工具。

我们期待与大家共同成长并推动 MCP 的演进！