MCP's August 2026 Roadmap: Stateless Servers, Agent Identity, and Enterprise Security

The Model Context Protocol (MCP) maintainers published an updated roadmap on August 22, 2026, outlining how the protocol is evolving to support more demanding agentic applications.

The roadmap follows the July 28 specification release, which introduced major architectural changes, including stateless operation, improved discovery, and stronger authorization mechanisms.

For developers using MCP to connect language models to enterprise systems, this is more than a protocol maintenance update.

It shows how MCP is moving toward infrastructure requirements familiar to teams building distributed applications: horizontal scaling, workload identity, access control, observability, and predictable execution.

Those concerns become unavoidable when agents move from experimental tools into systems that access customer data or perform business operations.

The biggest change: MCP is becoming stateless

Earlier MCP implementations relied on an initialization handshake and protocol-level sessions.

The July 28 specification removed those requirements from the protocol core.

Requests can now carry the information required to process them, allowing a server instance to handle a request without depending on a previous connection.

The specification also introduces the server/discover operation, which every server must implement and clients may call to learn about supported versions and server capabilities.

Why does this matter?

Consider an MCP server running in Kubernetes.

If a client depends on session state held by one server instance, a load balancer must route subsequent calls to the same instance or the application must synchronize that state elsewhere.

With stateless requests, any compatible server instance can receive the next call.

This simplifies load balancing and recovery when instances are restarted or scaled.

However, stateless transport does not mean stateless business workflows.

A multi-step process may still need to remember previous operations, pending approvals, and identifiers returned by external systems.

That state should be managed explicitly by the application rather than hidden inside a transport session.

What shipped, and what is still planned?

The distinction between the July specification and the August roadmap is worth preserving.

Capability	Status as of August 22
Stateless protocol core	Released in July 2026 specification
`server/discover`	Released
Cache hints for list responses	Released
Authorization improvements	Released
Tasks extension	Available as an extension
Standardized agent identity and delegation	Roadmap priority
Progressive tool discovery	Roadmap priority
Further improvements to server events	Roadmap priority

Sources: MCP July 28 specification and The New MCP Roadmap, August 22.

The second half of that table is a direction, not a delivery schedule.

The maintainers describe the roadmap as their current thinking rather than a firm commitment, and they say some items may change or be deferred.

I would build against what shipped in July and treat the rest as a reason to keep those parts of the design replaceable.

A stateless server still needs a design for state

The specification's answer to cross-call state is a handle.

The server creates one, returns it, and the client passes it back later as an ordinary tool argument.

That moves state out of the connection and into the application, where it can be stored, inspected, and expired.

It also creates a new place for mistakes.

Imagine a tool that prepares a financial export and returns a handle. A later call uses that handle to approve and send the file.

If the handle is the only thing the server checks, anyone who obtains it can finish the operation.

A handle identifies work. It doesn't grant permission to continue that work.

Every call that uses one should check the caller's identity, tenant, and scope against durable records, on whichever server instance receives the request.

Retries need the same care.

The July specification removed stream resumability, so a broken response stream loses the in-flight request and the client must send it again as a new request.

That is harmless for a read operation.

For a tool that sends an email or charges a customer, the server needs idempotency, or one user action can happen twice.

Why agent identity is the priority I would watch

MCP authorization was designed around a person with a browser approving access.

The roadmap says that assumption no longer holds. The caller is increasingly a cloud workload with its own identity, an agent acting for a user who isn't present, or a sub-agent that should hold less authority than its parent.

It also acknowledges that existing servers lean on pasted API keys and long-lived refresh tokens.

Consider an agent that prepares a finance report overnight.

It calls a reporting server on behalf of a manager who is asleep, then starts a sub-agent that only needs to read one dataset.

The server needs three answers: which workload is calling, which user it represents, and how much authority this step should have.

A shared API key answers none of them.

Every call looks identical in the audit log, and revoking the key stops everything that depends on it.

The planned work builds on existing standards:

DPoP, which ties a token to the client presenting it.
Workload Identity Federation, so an agent can authenticate as a workload.
The Identity Assertion JWT Authorization Grant used by Enterprise-Managed Authorization.
RFC 8693 token exchange, for delegated access.

The Agent Identity Working Group was still forming when the roadmap was published, so none of this is something to depend on yet.

Until it lands, I would issue short-lived credentials, scope each one to a single server and tenant, and have the server decide what each identity can do.

Smaller tool catalogs don't need to wait for the roadmap

Progressive discovery aims to let clients learn a server's tools as they need them, rather than loading the full catalog up front.

That matters when a gateway exposes hundreds of tools. The definitions consume context, and the model has more ways to choose the wrong one.

The maintainers describe this effort as just starting, with the goal of defining an experimental mechanism, so I wouldn't plan a release around it.

A simpler control is available today: give each user and each agent a smaller catalog.

The July specification has a detail that matters here.

List results now carry ttlMs and cacheScope. A private scope tells shared caches not to serve the response to a different user.

If a tool list depends on who is asking, it should be marked private. Otherwise, a shared gateway can show one user's tools to another.

Long-running work needs one owner

The Tasks extension polls for results through tasks/get, and the roadmap adds server-initiated events, including webhooks, so clients don't have to rely on polling.

The maintainers also name a risk in their own design: Tasks, subscriptions, and progress notifications could become separate answers to "the server isn't done yet", without a shared lifecycle, cancellation model, or error surface.

Until those pieces compose, I would keep long-running work in the application's own job records.

MCP can report on a job. It shouldn't be the only place that job's status exists.

Where the protocol stops and the application starts

I applied a related separation while building a verifiable AI analyst for a Saudi digital-services company. Its stack includes MCP and IBM ContextForge.

The model-facing surface is a catalog of typed operations with a per-user permissioned manifest. A capability the user isn't entitled to doesn't exist for that turn.

Those operations run under PostgreSQL row-level security and column masking, through a read-only role that can't bypass either. There is no raw-SQL tool.

This design was not built around the August roadmap.

The connection is the boundary it draws. The protocol carries the request, and the application decides what the request is allowed to do.

Standard agent identity would make it easier to establish who is calling. It wouldn't remove the need to enforce permissions at the data layer.

How I would prepare an MCP deployment now

I would start with what has already shipped.

Find anything that depends on Mcp-Session-Id, the initialize handshake, or state held in one server's memory.
Replace that state with explicit handles backed by durable storage, and authorize every use.
Run several server instances behind a load balancer and restart one during a multi-step workflow.
Make tools with side effects idempotent, then test a dropped stream and a retried request.
Move away from pasted API keys wherever the identity provider allows it.
Set cacheScope deliberately on every list that varies by user.
Record the user, agent, tool, arguments, decision, and result for each consequential call.

I would also review the deprecations. Roots, Sampling, Logging, the HTTP+SSE transport, and Dynamic Client Registration are all marked deprecated in the July release, under a policy with a minimum twelve-month window.

Finally, I would check every client, gateway, and SDK between the model and the tool. At the July release, the TypeScript, Python, Go, and C# SDKs supported the new revision, with Rust in beta.

A deployment only gets these benefits once each component in that path supports it.

Should enterprises move to the new MCP now?

For new remote servers, I would build on the July specification. Stateless requests remove a real operational burden, and there is little reason to start on a model the protocol is leaving behind.

For existing servers, I would plan the migration around the clients and gateways already in use, because removing sessions is a breaking change.

I wouldn't wait for the roadmap before securing a deployment, and I wouldn't design around items that have no committed delivery date.

MCP is starting to look like ordinary distributed infrastructure, which is good news for enterprise teams because they already know how to operate it.

The protocol can carry identity, scale more easily, and report progress.

Deciding what an agent is allowed to do remains the job of the application.

Sources

Written by Eslam Hamed, a Technical Lead and AI Solutions Architect working on agentic systems, enterprise integration, and governed data access.