The MCP (Model Context Protocol) just got the biggest glow-up. For the last year and a half, it has faced brutal criticism from experts. The latest update has resolved some of the most pressing concerns.
One of MCP’s biggest drawbacks was its stateful design. A client had to establish a session with a server, receive a session ID, and include that ID in every request that followed. Those requests often needed to return to the same server instance or rely on shared storage that all instances could access.
This created engineering overhead around sticky routing, session management, scaling, and failure recovery. If the server holding a session restarted or went offline, the client could lose its connection state and need to begin again. The same design also made MCP awkward to run on serverless and edge infrastructure, where instances regularly start, stop, and get replaced.
The MCP 2026-07-28 specification solved those problems directly.
The update removes protocol-level sessions and the initialisation handshake. Each request now carries the information a server needs to process it, allowing any available server instance to handle the request. It also introduces a stateless approach to multi-step interactions and exposes routing information through HTTP headers, making traffic easier for MCP gateways and load balancers to manage.
The release also improves caching, strengthens OAuth behaviour, and creates a proper extension framework for capabilities such as Tasks and MCP Apps.
Let’s look at what changed, how the new design works, and what developers need to consider before migrating.
The biggest change: MCP is now stateless
MCP 2026-07-28 moves the protocol from session-based communication to a stateless request-and-response model.
In the previous version, a client began with an initialize exchange. It sent its preferred protocol version, capabilities, and client information to the server. A server using protocol sessions could then return an Mcp-Session-Id, which the client included in later requests.
The flow looked like this:
Client Load balancer MCP server A
| | |
|-- initialize --------------->| |
| + protocol version |---- initialize -------->|
| + client capabilities | |
| + client information | |
| |<----- session ID --------|
|<------ session ID -----------| |
| | |
|-- tools/call + session ID -->| |
| |---- sticky route ------->|
| |<------- result ----------|
|<--------- result ------------| |
| | |
|-- next call + session ID --->|---- same instance ------>|
|<--------- result ------------|<------- result ----------|This setup was manageable when one client communicated with one server process. Load balancing added more work because later requests had to return to the instance that created the session, or every instance needed access to shared session storage.
Imagine that server A creates the session and then becomes unavailable. Server B may be healthy, though it has no record of that protocol session. The deployment must recover the shared state, recreate the session, or ask the client to connect again.
MCP 2026-07-28 removes the initialize handshake and the Mcp-Session-Id header. Each request carries its protocol version and client capabilities in _meta, along with client information when provided. Streamable HTTP requests also expose the operation through Mcp-Method and Mcp-Name headers.
The new flow looks like this:
Client Load balancer Any MCP server instance
| | |
|-- tools/call --------------->| |
| + protocol version | |
| + client capabilities | |
| + client information | |
| + method/name headers | |
| |---- tools/call -------->|
| |<------- result ----------|
|<--------- result ------------| |
| | |
|-- next tools/call ---------->|---- another instance -->|
| |<------- result ----------|
|<--------- result ------------| |Every request contains the protocol information needed to process it, so a basic round-robin load balancer can send calls to any compatible instance.
The benefit becomes especially clear when an instance goes offline. A session-based client may remain tied to the failed instance, while a stateless request can move to another healthy server. Application resources such as browser sessions, shopping baskets, and long-running workflows still need explicit handles or durable storage, but the MCP protocol no longer ties their continuity to one transport session.
The older flow stays tied to instance A. Stateless requests can continue through instances B and C when A becomes unavailable.
The new specification removes the initialize exchange and the Mcp-Session-Id header. Each request carries its own protocol version, capabilities, and client information. The server receives what it needs inside that request and can process it without looking up a protocol session created earlier.
A tool call can now look like this:
POST /mcp HTTP/1.1
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: search
Content-Type: application/json
{
"jsonrpc": "2.0",
"id": 1,
"method": "tools/call",
"params": {
"name": "search",
"arguments": {
"q": "otters"
},
"_meta": {
"io.modelcontextprotocol/clientInfo": {
"name": "my-app",
"version": "1.0"
}
}
}
}Any compatible server instance can handle this request. A basic round-robin load balancer can send one request to server A and the next one to server B without worrying about where the conversation started.
David Soria Parra, MCP co-creator and lead maintainer, summarised the change in his release post on X:
“MCP is now stateless, with semantics for multi-round-trip requests. Serving MCP just got much simpler and more scalable.”
Xiaohu used a nice delivery analogy. The old version worked like calling someone at a particular extension: that person remembered the conversation, so every follow-up had to return to them. The new version works more like a package with the required information written on it. Any available worker can pick it up and process it.
There is also a new server/discover method for clients that want to inspect a server before calling a tool. It returns the server’s supported protocol versions, capabilities, and identity. Calling it is optional, so clients can send a normal request immediately when they already know which version to use.
What teams actually gain from stateless MCP
Statelessness can sound like an internal architecture change. Its practical effects show up in hosting bills, incident recovery, deployment speed, and the amount of infrastructure a team has to maintain.
1. Scaling becomes much simpler
Every request can reach any healthy server instance. Teams can add more instances when traffic increases and remove them when demand drops without transferring MCP sessions or updating sticky-routing rules.
Imagine an MCP server running across ten instances. With session-based routing, some instances may become overloaded while others sit mostly idle because active users are pinned to particular machines. Stateless requests allow the load balancer to spread traffic more evenly across all ten.
The result is better use of the infrastructure teams are already paying for.
2. Serverless deployments become practical
Serverless platforms regularly start, stop, and replace application instances. A protocol that expects the same process to remember a client session fits poorly into that environment.
Self-contained MCP requests can be handled by whichever function or worker is available. This makes it easier to run MCP servers on edge workers, serverless functions, autoscaling containers, and other short-lived compute environments.
Teams may also scale down to zero when a server is unused, which can reduce hosting costs for integrations with irregular traffic.
3. One failed instance causes less disruption
A session tied to one server can disappear when that server crashes, restarts, or gets replaced during a deployment. The user may need to reconnect and repeat part of the workflow.
With stateless requests, the load balancer can send the next request to another healthy instance. The animation above shows this directly: instance A goes offline, and requests continue through instances B and C.
Application resources such as browsers, baskets, or workflow runs still need durable storage or explicit handles. The MCP connection itself no longer disappears with one server process.
4. Deployments become safer
Teams frequently replace server instances while releasing a new version. Session-based systems may need connection draining, careful shutdown periods, or shared session storage so active users can finish their work.
Stateless instances can be replaced more freely because another compatible instance can process the next request. Rolling deployments, autoscaling events, and regional failovers require less special handling.
This can shorten deployment times and reduce the chance that a routine release interrupts active MCP users.
5. Load balancers need less custom setup
The previous flow could require sticky sessions or a shared session store. Both add configuration and ongoing maintenance.
The new flow works with ordinary round-robin routing. Teams can use the load balancers, gateways, and container platforms they already operate without building a separate session layer for MCP.
That means fewer moving parts, fewer infrastructure bills, and fewer late-night problems caused by session data getting out of sync.
6. Traffic can move between regions more easily
A request containing the required protocol information can be sent to any compatible deployment. Global traffic managers can direct users toward a nearby healthy region or move traffic away from a region experiencing problems.
Cross-call application state still needs an appropriate storage strategy. The protocol layer no longer forces every request back to the region where the MCP connection began.
7. Capacity planning becomes more predictable
Session pinning can create uneven workloads. One instance may receive several expensive tool calls while another receives only light traffic, even when the total number of users appears balanced.
Stateless routing gives infrastructure more freedom to distribute requests based on availability, region, current load, or other operational signals. This makes resource usage easier to measure and capacity easier to plan.
8. Retries become easier to understand
A self-contained request can be sent again when a network connection breaks or a server becomes unavailable. Another instance can understand the retried request without recovering an earlier protocol session.
Developers still need to make tools with side effects safe to retry. Payments, deletions, project creation, and similar operations should use idempotency keys or deduplication records. Stateless MCP makes the retry path clearer, while the application remains responsible for preventing duplicate actions.
9. State becomes visible and easier to control
Applications can still keep state by returning explicit handles such as browser_id, basket_id, or task_id.
Those handles can have their own expiration time, ownership rules, audit history, and cleanup process. The model can also see the handle and pass it between related tool calls.
This gives developers clearer control over application state and helps them avoid storing unrelated information inside a broad transport session.
10. The development setup gets closer to a normal HTTP service
MCP developers can use familiar patterns for load balancing, tracing, caching, authorisation, retries, and deployment.
This reduces the amount of MCP-specific infrastructure a team has to create and maintain. New engineers can also understand the system more quickly because its behaviour resembles the web services they already work with.
Taken together, these gains make remote MCP servers easier to operate under real production traffic. Teams can scale them more evenly, recover from failures faster, deploy them with less ceremony, and spend more time improving their tools.
Your application can still keep state
Some tools still need to remember things between calls. A browser automation server may need to keep the same browser open. A shopping tool may need to remember a basket. A coding agent may create a sandbox and continue using it through several steps.
The new specification supports these cases through explicit handles.
For example, a tool that starts a browser could return:
{
"browser_id": "browser_7f32"
}The client or model can include that identifier in the next call:
{
"name": "open_url",
"arguments": {
"browser_id": "browser_7f32",
"url": "https://example.com"
}
}The server can use browser_id to find the right browser instance, even if the request arrives at a different MCP server.
This moves state into the application layer, where developers can manage it directly. They can decide how long a handle should remain valid, which user owns it, where its data is stored, and when the underlying resource should be cleaned up.
It also makes the state visible to the model. The model can keep a handle, pass it to another tool, or choose between several active resources. A hidden transport session offered fewer options because the model could not see or reason about it.
These handles need proper security controls. A server should bind them to the correct user and organization, validate them on every call, give them reasonable expiration times, and prevent clients from guessing or changing them. Expensive resources such as browsers and sandboxes also need cleanup rules so abandoned handles do not leave processes running forever.
The protocol now stays out of the way while the application manages the state it actually needs.
Multi-Round-Trip Requests keep interactive tools working
Removing sessions is straightforward when an operation has one request and one response. Agent tools often need an extra answer halfway through their work.
A tool might need confirmation before deleting files, a missing account ID, approval for a payment, or a choice between several projects. Earlier MCP versions could handle these situations through server-initiated requests over a bidirectional stream.
The new specification introduces Multi Round-Trip Requests, usually shortened to MRTR.
Suppose an agent asks a tool to delete three files. The server can pause the operation and return:
{
"resultType": "input_required",
"inputRequests": {
"confirmation": {
"type": "elicitation",
"message": "Delete these three files?",
"schema": {
"type": "boolean"
}
}
},
"requestState": "opaque-server-generated-state"
}The client gathers the answer from the user and retries the original operation:
{
"jsonrpc": "2.0",
"id": 2,
"method": "tools/call",
"params": {
"name": "delete_files",
"arguments": {
"paths": ["a.txt", "b.txt", "c.txt"]
},
"inputResponses": {
"confirmation": true
},
"requestState": "opaque-server-generated-state"
}
}That retry can reach another server instance because the request includes the user’s answer and the server’s opaque continuation state.
MRTR replaces the earlier server-initiated flow used for operations such as elicitation/create, sampling/createMessage, and roots/list. Ordinary results now include resultType: "complete", while an intermediate result uses resultType: "input_required". Clients must treat results from older servers that omit resultType as complete. The official changelog explains the complete MRTR result model.
The pattern also creates a useful safety boundary. A server asks for user input while processing an operation the user or agent already started. Prompts stay tied to a visible request, which reduces unexpected interruptions from a separate channel.
Servers still need to decide how long requestState stays valid and how retries interact with side effects. Clients need to keep the original arguments and match each answer to the correct input request. The basic flow is easier to run across unreliable networks and interchangeable servers.
Gateways can understand MCP traffic from HTTP headers
Before SEP-2243, the method and tool name were carried in the JSON-RPC body. MCP 2026-07-28 mirrors that information into Mcp-Method and Mcp-Name headers, allowing gateways and load balancers to route traffic without parsing the request body.
Streamable HTTP requests now include:
Mcp-Method, which identifies the JSON-RPC method.Mcp-Name, which identifies the tool, prompt, or resource operation when applicable.
For example:
Mcp-Method: tools/call
Mcp-Name: delete_projectA gateway can use these headers to route traffic, apply rate limits, collect metrics, or trigger extra checks.
tools/list → cache-friendly path
tools/call:search → higher rate limit
tools/call:export_data → extra audit logging
tools/call:delete_* → stronger policy checksServers reject requests when the headers disagree with the JSON-RPC body. That check prevents a dangerous operation from being labelled as harmless and slipping past a gateway rule.
The server still authenticates the caller, validates the request, and authorises the real operation. Headers give infrastructure a quick way to classify traffic, while the server remains responsible for security.
Tool lists and resources can be cached properly
MCP clients regularly ask servers for lists of tools, prompts, resources, and resource templates. Those lists may remain unchanged for hours, yet clients can fetch them repeatedly.
Results from operations including tools/list, prompts/list, resources/list, resources/templates/list, and resources/read now carry:
ttlMs, which tells the client how long the result should remain fresh.cacheScope, which tells clients and intermediaries whether the result can be shared or must remain private.
Servers should also return tool lists in a stable order. The caching and ordering rules are documented in the official key changes.
Stable ordering matters because tool definitions are commonly included in the prompt sent to a model. If the same tools appear in a different order after every connection, the prompt changes at the byte level. That can lower prompt-cache hit rates even when the available tools stayed the same.
The tangible gains include fewer network calls, lower server load, faster connection startup, and more stable model prompts.
Caching still has to respect user and organisation boundaries. A personalised tool catalogue should use a private cache scope, so shared infrastructure does not serve it to another user.
Authorisation is stricter and closer to real enterprise setups
Authorisation has taken a large share of the work involved in building remote MCP servers. MCP clients may connect to many independently operated servers, and each server may use a different identity provider. Desktop apps and command-line tools also have redirect behaviour that differs from a normal website.
The 2026-07-28 update tightens several parts of the OAuth flow.
1. Clients validate the authorisation issuer
Authorisation servers should now return a iss value as described by RFC 9207. When it is present, the client must check that it matches the expected issuer before exchanging the authorisation code.
This protects against authorisation-server mix-up attacks. A client might start a flow with identity provider A and receive a response associated with identity provider B. Issuer validation catches that mismatch before the client sends a code or associates credentials with the wrong system.
The risk is especially relevant to MCP because one client can connect to many servers and authorisation systems.
2. Credentials stay tied to the issuer that created them
Clients must store registered credentials together with the authorisation server’s issuer identity. Credentials created by one issuer cannot be reused with another.
If an MCP resource moves to a different authorisation server, the client needs to register again. This keeps credentials from crossing security boundaries simply because two servers appear related.
3. Desktop and CLI clients identify their application type
Clients now set the appropriate OpenID Connect application_type during Dynamic Client Registration.
Without this value, an authorisation server may assume that a desktop or CLI client is a web application and reject its localhost redirect URI. Developers who have encountered confusing redirect_uri errors during MCP OAuth may have run into this exact mismatch.
4. Dynamic Client Registration is being phased out
Dynamic Client Registration, or DCR, is now deprecated in favour of Client ID Metadata Documents, commonly called CIMD.
DCR allows a client to create a new registration at an authorisation server during runtime. In a large ecosystem, that can create duplicated registrations, abandoned credentials, inconsistent policies, and a great deal of state for authorisation servers to maintain.
With CIMD, a client uses an HTTPS URL as its identifier and publishes its metadata at that location. An authorisation server can retrieve a stable description of the client and avoid creating a fresh identity every time.
DCR remains available for compatibility, and the new deprecation policy provides at least twelve months before a deprecated capability can be removed.
5. Enterprise-managed authorisation fits into the extension model
The core authorisation changes work alongside the Enterprise Managed Authorisation extension.
Anthropic describes an enterprise setup where administrators provision MCP connectors through the company’s identity provider. An administrator authorises a connector, access follows existing identity groups, and employees receive access without configuring the connector one person at a time. Anthropic explains this model in its Claude announcement.
The core specification defines shared authorisation behaviour, extensions cover deployment models such as centrally managed access, and products decide how those controls appear to administrators and users.
Teams still need secure token storage, good scope design, tenant isolation, refresh handling, revocation, and clear consent screens. The updated specification gives those systems safer boundaries and better alignment with OAuth and OpenID Connect.
Extensions now have a proper home
Interactive interfaces, long-running jobs, and enterprise identity features do not need to become mandatory parts of every MCP implementation.
The new extensions framework gives these capabilities a formal way to develop alongside the core protocol.
Extensions:
Use reverse-domain-style identifiers.
Are advertised by clients and servers.
Require support from both sides.
Can be versioned independently.
Can evolve in their own repositories.
Have a path from experimentation to official support.
This keeps the core smaller and gives the community room to develop specialised features.
MCP Apps
MCP Apps allow a server to provide an interactive interface that a compatible host can render inside a conversation.
A tool can show a chart, form, media player, project editor, or another focused interface. The host renders it in a sandbox, and the interface communicates through MCP’s JSON-RPC foundation.
Users can review structured information, provide input, and interact with generated results without moving between several browser tabs. Hosts also get a clearer place to show consent and tool activity.
Tasks
Long-running operations now live in the official io.modelcontextprotocol/tasks extension.
A server can return a task handle, and the client can manage it with operations such as:
tasks/gettasks/updatetasks/cancel
Polling through tasks/get replaces the older blocking result flow. tasks/update Lets a client provide additional input while work is underway.
MRTR and Tasks cover different needs. MRTR handles extra input required to continue the current operation, while Tasks handle durable work that may continue long after the original request ends.
Notifications have a clearer role
Stateless MCP still supports streaming where it helps.
The old HTTP GET endpoint and the resource-specific subscribe and unsubscribe methods have been replaced by subscriptions/listen. A client opens one stream and selects the types of changes it wants to receive, such as updates to tools, prompts, or resources.
Progress updates related to an active request can continue on that request’s response stream.
This creates a cleaner split:
Ordinary operations use self-contained requests.
Progress stays attached to the request that created it.
General change notifications use an explicitly opened subscription stream.
SSE resumability and message redelivery have been removed from Streamable HTTP. If an in-flight response stream breaks, the client sends a new request with a new request ID.
That makes idempotency important. A repeated request must not accidentally create two payments, launch duplicate jobs, or perform the same destructive action twice. Tools with side effects should use idempotency keys or another deduplication strategy.
Roots, Sampling, Logging, and legacy HTTP+SSE are deprecated
The release also begins retiring several features:
Roots: Pass file or directory information through tool parameters, resource URIs, or server configuration.
Sampling: Connect directly to the relevant model provider when a server needs model inference.
Logging: Use standard error for local stdio servers and OpenTelemetry for structured production observability.
Legacy HTTP+SSE: Move to Streamable HTTP.
These capabilities still work during the deprecation period. New implementations are encouraged to use the recommended replacements. The specification maintains a formal deprecated-features list.
MCP now has Active, Deprecated, and Removed lifecycle stages, along with a minimum twelve-month deprecation window. Developers get time to plan an upgrade, and removing a feature requires an explicit specification proposal.
Tool schemas are more expressive
Tool input and output schemas now support the full JSON Schema 2020-12 vocabulary.
Developers can use:
$refand$defsoneOf,anyOf, andallOfConditional validation
Richer nested structures
Non-object output values
Tool inputs still use an object at the root. Outputs and structuredContent can represent a wider range of JSON values.
Implementers should place limits on schema depth, validation time, and reference handling. Automatically retrieving external $ref URLs can introduce security and performance problems. A simpler schema may also work better for models and client interfaces even when the specification allows a more complicated one.
Observability gets a shared language
The specification documents W3C Trace Context propagation through _meta fields such as:
traceparenttracestatebaggage
A trace can begin inside an AI host, follow a tool call through the MCP client and server, continue into downstream APIs, and appear as one connected trace in an OpenTelemetry-compatible system.
Combined with the new method and name headers, teams can answer practical questions:
Which tools are called most often?
Which tools are slow?
Where did a request fail?
Which downstream dependency caused the delay?
Did validation or authorization reject the call?
How did one agent workflow move across several services?
This becomes essential when MCP tools can read private data, update business systems, or trigger financial actions.
What server developers need to change
Maintainers of remote MCP servers should review the following areas:
Replace protocol-session state. Use explicit application handles for state that must survive across calls.
Read per-request metadata. Handle protocol version, client capabilities, client information, and log preferences on each request.
Implement
server/discover. Advertise supported versions, capabilities, extensions, and server identity.Validate routing headers. Check
Mcp-MethodandMcp-Nameagainst the JSON-RPC body.Make side effects retry-safe. Use idempotency keys, transaction IDs, task handles, or deduplication records.
Adopt MRTR. Return
input_requiredwhen the server needs confirmation or additional input.Add cache metadata. Return suitable
ttlMsandcacheScopevalues and keep list ordering stable.Update authorization. Validate issuers, isolate credentials by issuer, use the right application type, and prepare for CIMD.
Propagate traces. Carry W3C trace context and use OpenTelemetry for production visibility.
Negotiate extensions. Check support before using Tasks, MCP Apps, or enterprise authorization features.
Plan deprecation migrations. Move away from Roots, Sampling, Logging, and legacy HTTP+SSE.
Test mixed versions. Clients and servers will upgrade at different times, so compatibility needs dedicated coverage.
The TypeScript, Python, Go, and C# Tier 1 SDKs support the new specification, while Rust support was available in beta when the release shipped. Developers should still read the migration guide for their SDK.
For example, the TypeScript SDK uses explicit version-negotiation options in relevant entry points. Existing applications keep their current wire behaviour until developers configure the newer version. Its 2026 migration guide explains the behavior.
What clients and AI hosts need to change
Client and host developers also have work to do:
Preserve the original request across an MRTR retry.
Present confirmation and elicitation requests clearly.
Treat tool descriptions and annotations as untrusted input.
Read a missing
resultTypefrom an older server as a completed result.Respect
ttlMsandcacheScopewhen caching.Validate OAuth issuers before exchanging authorisation codes.
Store client registrations separately for each issuer.
Handle unsupported protocol versions cleanly.
Reissue interrupted calls with new request IDs.
Check extension support before using an extension.
Show users which information and authority are being given to a server.
Hosts also need clear consent rules. A product should decide which calls require confirmation and whether approval applies to one action, one task, one server, or a wider workflow.
MRTR and MCP Apps provide better building blocks for that experience. Product teams still have to turn those building blocks into controls that users can understand.
What the release means for Claude
Anthropic says support for MCP 2026-07-28 is rolling out across Claude products.
Claude’s connector directory lists more than 950 MCP servers, according to the company. Anthropic’s wider MCP work includes interactive MCP Apps, enterprise-managed authorisation, connector observability, and private-network tunnels. The company outlines these features in its release post.
MCP tunnels allow Claude to reach a server inside a private network without requiring a public inbound endpoint, new inbound firewall rules, or IP allowlisting at the origin.
Together, these pieces create a practical production setup:
Internal or public application
|
MCP server
|
Stateless HTTP requests
|
Enterprise authorization
|
Claude host
|
Tools, apps, and tasksThe open specification supplies the shared protocol. Claude adds the connector directory, administration, network access, monitoring, and user experience around it.
A community release shaped by real deployments
MCP began at Anthropic, and Anthropic remains an active contributor. The protocol is now developed as an open community project with work from several companies and individual contributors.
David Soria Parra described this release as the result of roughly 18 months of lessons from real implementations. He also highlighted contributions from Anthropic, Google, Microsoft, OpenAI, and many others in his announcement thread.
That breadth matters because a protocol connecting AI hosts to outside applications has to work across different products, clouds, identity systems, and deployment styles.
The official release announcement reports close to half a billion monthly downloads across Tier 1 SDKs, with the TypeScript and Python SDKs each passing one billion cumulative downloads. Package-download totals include automated activity, so they provide a broad signal of ecosystem activity. The number of unique developers will be smaller, though the totals still show how widely compatibility decisions can travel. The MCP project published those figures with the release.
Antonio Leiva captured the wider reaction in his post about the update: MCP had been declared dead several times, yet the protocol kept gaining adoption and now has a design that can be deployed much more widely.
Important limits to keep in mind
The update removes a large amount of protocol-level friction, and several responsibilities still remain with application developers.
Application state still needs storage
Browser sessions, transactions, carts, sandboxes, and workflow runs need durable state. Explicit handles make that state easier to see and manage, while the application chooses where to store it.
Side effects still need retry protection
When a connection breaks, a client may repeat a request. Payments, deletions, and job creation need idempotency or deduplication controls.
Headers still need server-side validation
Mcp-Method and Mcp-Name help gateways classify traffic. The server must authenticate the caller, validate the body, and authorise the actual operation.
OAuth still requires careful implementation
Issuer checks and credential isolation close meaningful gaps. Teams still need secure storage, well-designed scopes, token refresh, revocation, tenant separation, and understandable consent.
Streams still have useful jobs
Subscription streams and request-specific progress updates remain available. Ordinary requests can run independently, while streaming is used for the cases that benefit from it.
The ecosystem will upgrade gradually
Clients and servers will support several protocol versions for some time. Version negotiation, compatibility tests, and careful rollout plans remain important.
Extensions will vary between hosts
MCP Apps, Tasks, and Enterprise Managed Authorisation require support from both client and server. Developers should provide a reasonable fallback when a host does not support a particular extension.
MCP is starting to fit the rest of the web
The individual changes in MCP 2026-07-28 point in the same direction.
MCP requests are becoming:
Stateless
Self-contained
Routable
Cacheable
Observable
Easier to secure with common OAuth and OpenID Connect systems
Easier to extend without making the core too large
Easier to deploy on standard HTTP infrastructure
These qualities may sound ordinary because the web has spent decades learning how to scale request-based services.
Early MCP showed that developers wanted a shared way to connect AI systems with tools and context. The 2026-07-28 update focuses on what happens after those integrations attract real users and real production traffic.
There is migration work ahead. Servers that relied on session IDs need explicit state handles. Interactive tools need MRTR. Authorisation implementations need stricter issuer handling. Task integrations have a new lifecycle, and several older features now have recommended replacements.
The gains are concrete: simpler scaling, easier serverless deployment, better failure recovery, safer rollouts, lower infrastructure overhead, clearer authorisation boundaries, useful caching, and better visibility into what agents are doing.
MCP has moved beyond proving that a common agent-tool protocol can work. This release gives teams a stronger foundation for running it reliably, securely, and at scale.
