Co-creator David Soria Parra is steering the protocol toward long-running, delegated work across enterprise systems.
By RuntimeWire Staff · Published
Primary source: Model Context Protocol Blog
Why it matters #
MCP is moving from a connector standard into infrastructure for unattended agents. Its identity, messaging and discovery choices will shape how AI systems reach enterprise data and tools.
David Soria Parra, co-creator of the Model Context Protocol, and Den Delimarsky published an updated MCP roadmap on August 22nd that prioritizes long-running agent work, machine identity, transport consolidation and a less wasteful way to expose large tool catalogs to models.
The roadmap covers the next specification release and the following six to twelve months. It offers direction rather than firm delivery dates. Specification Enhancement Proposals aligned with its five priorities will receive expedited review, while proposals outside them face a longer queue and a higher bar. For an open protocol with finite maintainer attention, that makes the document a resource-allocation decision as much as a technical plan.
Soria Parra's original problem was smaller. While working at Anthropic, he grew frustrated copying information between Claude Desktop, which could render useful artifacts, and his development environment, which could access his code. He saw the familiar M-by-N integration problem: every AI client would otherwise need a custom connection to every external system.
Soria Parra brought the protocol idea to Justin Spahr-Summers, who helped prototype the first implementation and integrate it into an Anthropic product. Anthropic released MCP as an open-source standard on November 25th, 2024. Less than two years later, Soria Parra is helping redesign it around agents that may run for minutes or hours, delegate authority and continue operating without a person sitting in front of a consent screen.
Tool connections are becoming agent infrastructure
MCP standardized how AI applications connect to tools, data and workflows. Its current documentation lists support across clients including Claude, ChatGPT, Visual Studio Code and Cursor. That reach has raised a harder set of engineering questions than the initial protocol needed to answer.
A basic request-response exchange works when a model calls a calculator or retrieves a document. It breaks down when an agent starts a job that runs for an extended period, needs new instructions halfway through or must receive a server-generated result after the original exchange has ended.
The roadmap's first priority brings MCP's existing Tasks, subscriptions and progress notifications into a more coherent lifecycle. Maintainers plan to work on server-initiated events, including webhooks and channels, so clients can receive results without repeatedly polling. They also want the Tasks extension to mature toward inclusion in the core specification.
That pushes MCP into territory adjacent to agent communication protocols. Google describes its Agent2Agent protocol as complementary to MCP: A2A handles collaboration between agents, while MCP connects agents to tools and context. The boundary remains useful, though MCP now needs many of the same operational properties, including long-running tasks, streaming updates and asynchronous state changes.
Transport unification has an awkward local case
The transport plan continues the work MCP shipped in its July 28th specification. As RuntimeWire reported at the time, that revision removed protocol-level sessions and made remote MCP servers behave more like ordinary stateless HTTP services.
The roadmap says MCP wants to extend its HTTP-native model to other deployment modes, including local servers speaking Streamable HTTP over stdio. Unifying on one transport would simplify MCP server and client development and give developers fewer behaviors to implement and test.
MCP's maintainers are trying to make servers operationally boring enough to fit into existing application stacks. That matters as the protocol moves from interactive tool calls toward unattended workloads that need predictable connections and durable state changes.
Agents need credentials that belong to agents
MCP's existing authorization flow assumes a person is available to approve access in a browser. Cloud agents may run without an active user, act on a user's behalf or create sub-agents that should receive narrower permissions than the parent process.
Delimarsky, who worked on security and authorization at Microsoft before joining Anthropic, is one of the maintainers assigned to this area. The roadmap calls for standardized agent identity and delegation using existing security mechanisms, including Demonstrating Proof of Possession, Workload Identity Federation, the Identity Assertion JWT Authorization Grant and standard token exchange.
The goal is to replace pasted API keys and long-lived tokens with credentials that a server can bind to a workload and verify. Delegation matters just as much as authentication. An agent that can spawn another agent needs a way to pass limited authority without handing over every permission it holds.
Identity work will not remove the protocol's wider trust problems. OWASP's MCP security guidance describes how malicious tool responses can inject instructions into a model's context and trigger data access or unauthorized actions. Workload credentials can identify the caller and constrain its permissions, while clients still need tool validation, isolation and least-privilege enforcement.
MCP has a tool-catalog tax
The roadmap also confronts a cost built into MCP's current discovery model. When a server advertises 100 tools, the client may place that entire catalog in front of the model before the user asks a question. That consumes context and can make tool selection less reliable.
Maintainers plan to develop progressive discovery, allowing a server to present a smaller entry point and reveal additional tools or resources as the conversation narrows. The same section proposes a clearer tools/call
result contract. MCP currently permits overlapping structured and unstructured outputs, leaving server developers unsure which representation a client will show the model.
A final priority focuses on SDK consistency. The roadmap says maintainers are investing in SDK ergonomics, documentation and conformance with the specification across supported platforms and languages.
MCP's governance gives Soria Parra and Delimarsky unusual authority over how those tradeoffs are settled. Under the protocol's governance model, lead maintainers hold final technical decision authority, while membership belongs to individuals rather than their employers. MCP has operated under Linux Foundation stewardship since its December 9th, 2025 donation to the Agentic AI Foundation, but its maintainers retain control over day-to-day technical direction.
The roadmap uses that control to narrow MCP's next phase. Soria Parra began with a protocol for escaping copy and paste between two applications. The next specification work assumes those applications can launch autonomous jobs, exchange streamed updates and authorize other machines to act. MCP's usefulness now depends on making those behaviors predictable before developers build another generation of one-off fixes around them.