The MCP roadmap points to long tasks and authentication

The Model Context Protocol is not yet two years old since its introduction in November 2024 and it already has its own roadmap. GIGAZINE reports that the team maintaining the specification has published a roadmap with five work areas and highlights two of them: long running processing and authentication for AI agents. Both point at the same place, which is what breaks when MCP leaves a developer laptop and walks into a company.

It is worth recalling what we are talking about. MCP is the standard that lets a model call external tools through a common contract, instead of a bespoke integration per service. It is configured in claude_desktop_config.json or from Claude Code, and in a short time it has gone from an Anthropic proposal to a piece implemented by very different vendors. A roadmap built around these two axes marks the point where a protocol stops growing sideways and starts fixing what hurts.

Long tasks against the request and response model

A tool call in MCP looks like an HTTP request: you ask for something and wait for the answer. That fits querying a database and fits badly with rendering a video, launching a migration, crawling an entire site or waiting for a twenty minute build. The usual workaround is to return a job identifier and have the agent ask every few seconds whether it is ready, which spends context and tokens on doing nothing.

The specification does cover progress notifications and cancellation, but that is not the same as a job able to survive the client disconnecting and to deliver its result later. The fact that this made the roadmap suggests the solution will end up living in the protocol, rather than being rewritten by hand inside every server.

Identity: who is the agent making the call

The second axis is the touchier one. When a remote MCP server requires authentication today, the usual pattern goes through OAuth: the person authorises and the server receives a token representing them. The agent then acts by impersonating the human and inherits all of their permissions. That works on a desktop and falls apart as soon as you have several agents, two environments and someone asking for an audit.

What is missing is the ability to tell the agent apart from the user who launched it: its own credentials, permissions scoped to what that agent needs and a trace of which agent made which call under which authorisation. Without that, revoking access for a compromised agent forces you to revoke the person as well, and any audit log ends up showing the same name every time.

What to do in the meantime

A roadmap is not a specification and does not force anyone to rewrite anything today. It is still worth preparing the ground:

1. Design idempotent tools, because retries are coming anyway.
2. For long jobs, return a stable identifier and a way to poll it now, so that migrating to whatever ships means changing the transport and not the logic.
3. Separate credentials per agent and per environment using service accounts, instead of reusing the personal token of whoever set up the integration.
4. Review the scopes each installed MCP server asks for and drop the ones that are not needed.

Our take

The interesting part of the roadmap is not the five areas but what they reveal. A protocol that starts solving identity and multi hour jobs is a protocol already being used where there is something to lose. We read it as a sign of maturity, with the usual caution: the date that will count is the one on the published specification, not the one on the announcement.