The Model Context Protocol has received its largest architectural revision since launch. MCP was originally introduced as a common way for A...
The Model Context Protocol has received its largest architectural revision since launch.
MCP was originally introduced as a common way for AI applications to connect models with tools, APIs, data sources, files, and external systems. In less than two years, it has grown from an Anthropic-led integration project into a broader open protocol with its own governance process, SDK ecosystem, working groups, extensions, and implementations across many AI products.
The 2026-07-28 revision focuses on the problems that appear when MCP leaves a developer laptop and moves into large production environments.
The headline change is simple:
MCP is becoming stateless at the protocol layer.
That change removes the protocol-level session and initialization handshake from the new wire format, making remote MCP servers much easier to place behind ordinary load balancers, serverless infrastructure, edge workers, and horizontally scaled deployments.
But stateless transport is only one part of the update.
The revision also formalizes an extension framework, reshapes long-running Tasks, introduces Multi Round-Trip Requests, adds routable HTTP headers and caching hints, strengthens authorization, expands JSON Schema support, and creates a formal feature-deprecation policy.
Around the protocol itself, the MCP ecosystem is also adding interactive apps, enterprise-managed authorization, private-network tunnels, and stronger developer tooling.
This is the point where MCP begins to look less like a convenient agent connector and more like production infrastructure.
The source report highlights the speed at which MCP usage has grown.
According to the Claude Developers launch communication cited by the source article:
These exact late-July figures are launch-communication metrics rather than figures published in the core specification.
An earlier official Anthropic announcement provides a useful reference point: in January 2026, Anthropic said MCP had reached 100 million monthly downloads.
That means the ecosystem was already large before the July protocol redesign.
The significance of the current update is therefore not that MCP is trying to become useful someday. It is that maintainers are redesigning the protocol around problems already visible at production scale.
Those problems include:
Earlier remote MCP deployments could maintain protocol-level session state.
A client typically initialized a connection and received a session identifier. Future requests then needed to remain associated with that session.
A simplified 2025-11-25 flow looked like this:
POST /mcp HTTP/1.1
Content-Type: application/json
{
"jsonrpc": "2.0",
"id": 1,
"method": "initialize",
"params": {
"protocolVersion": "2025-11-25",
"capabilities": {},
"clientInfo": {
"name": "my-app",
"version": "1.0"
}
}
}
After initialization, later calls could carry:
Mcp-Session-Id: 1868a90c-3a3f-4f5b
That approach is workable for many applications, but it creates infrastructure requirements.
A production deployment may need:
The MCP maintainers concluded that these requirements were too deeply embedded in the protocol itself.
The new revision removes that assumption.
In the 2026-07-28 protocol design, each request carries the information required for the server to interpret it.
The official example looks 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"
}
}
}
}
There is no protocol-level Mcp-Session-Id.
There is no mandatory connection session tying the request to one server instance.
Any compatible server instance can process the request.
This is a major improvement for cloud deployment.
A remote MCP server can now fit a conventional architecture:
Client
↓
API Gateway / Load Balancer
↓
MCP Server Instance A
MCP Server Instance B
MCP Server Instance C
Requests do not need to return to the same instance simply because an earlier request landed there.
initialize Handshake Is Removed from the New Wire FormatThe stateless redesign also removes the old initialize / initialized lifecycle from the 2026-07-28 wire format.
Information that previously traveled once during initialization now travels with requests through metadata.
A new method, server/discover, can be used when a client wants to discover server capabilities in advance.
This does not mean older clients immediately stop working.
Current SDK documentation includes compatibility behavior for earlier protocol revisions. For example, the C# SDK can support the new stateless path while continuing to negotiate older session-based behavior with clients speaking 2025-11-25.
The important migration distinction is:
2026-07-28:
Stateless request model, no protocol session.
Older revisions:
Initialize handshake and session-aware behavior may still be supported
through version negotiation and SDK compatibility paths.
Developers should test both sides of an integration instead of upgrading only the server and assuming every client speaks the new revision.
One of the easiest mistakes is to interpret the change as:
MCP applications are no longer allowed to keep state.
That is not what the specification means.
The protocol layer is stateless.
An application can still maintain state where state is useful.
Suppose a shopping tool creates a basket.
The server can return:
{
"basket_id": "basket_8472"
}
The model can then pass that value into later calls:
{
"basket_id": "basket_8472",
"item_id": "item_123"
}
This keeps the application state visible as ordinary tool data instead of hiding it inside transport metadata.
The same pattern can be used for browser sessions, report jobs, shopping carts, workflow IDs, deployment IDs, document-editing state, and long-running analysis jobs.
A visible handle has several advantages.
The model can:
The server can:
Stateless MCP therefore moves state management out of the transport and into explicit application design.
The source article emphasizes serverless deployment, and this is one of the most practical consequences of the new protocol.
When requests are self-contained, an MCP server can be easier to run in environments such as:
This does not mean every MCP workload automatically works on every serverless platform.
Developers still need to consider execution duration, streaming support, cold starts, persistent application state, secrets, outbound networking, long-running Tasks, file-system requirements, and database connections.
The protocol no longer forces a session architecture, which removes one major obstacle.
A horizontally scaled server no longer needs to pin one client to one instance at the protocol layer.
That means a simple round-robin load balancer can distribute requests across instances.
This improves:
It also changes how server authors should think about hidden in-memory state.
If a tool works only because a previous request populated a dictionary inside one process, that implementation may fail when the next request reaches another instance.
A good migration test is:
Can the same workflow continue if every tool call lands on a different server process?
If the answer is no, the server contains an application-state dependency that needs to become explicit or move into durable shared storage.
A stateless design still needs a way for a server to ask the client for more information.
Examples include user confirmation, additional parameters, elicitation, a model-generated response, or a workspace-related value.
The new mechanism is Multi Round-Trip Requests, or MRTR.
A tool may return an incomplete result:
{
"resultType": "input_required",
"inputRequests": {
"confirm": {
"type": "elicitation",
"message": "Delete 3 files?",
"schema": {
"type": "boolean"
}
}
},
"requestState": "eyJzdGVwIjoxLCJmaWxlcyI6WyJhIiwiYiIsImMiXX0="
}
The client collects the required answer.
It then repeats the original call with inputResponses and the returned requestState.
Because the state is carried in the request flow, another server instance can process the next round.
This fits the stateless architecture much better than requiring a long-lived server-to-client connection.
The new Streamable HTTP format adds operation metadata directly to HTTP headers.
Important headers include:
Mcp-Method: tools/call
Mcp-Name: search
This matters for production infrastructure.
An API gateway, Web Application Firewall, rate limiter, or observability layer can identify the operation without parsing the JSON body.
Possible uses include:
The protocol specification also requires consistency between the headers and the JSON-RPC body.
Servers should reject requests where they disagree.
MCP clients often request relatively stable metadata such as tool lists, resources, prompt lists, and resource reads.
Fetching the same information repeatedly wastes network traffic and server capacity.
The new revision introduces cache metadata such as:
ttlMs
cacheScope
The values let a server indicate how long a result should remain fresh and whether it can be shared across users or contexts.
This is similar in spirit to ordinary HTTP caching.
For tool-heavy agents, it can reduce repeated metadata loading.
The revision also documents W3C Trace Context propagation.
Keys such as:
traceparenttracestatebaggagecan travel through MCP metadata.
This allows one distributed trace to follow work across:
Host application
→ MCP client
→ MCP gateway
→ MCP server
→ downstream API
→ database
For enterprise deployments, this is important because a slow tool call is much easier to debug when teams can see where the latency actually occurred.
The protocol is also changing how optional functionality evolves.
The current framework gives extensions:
This matters because the core protocol does not need to absorb every new idea.
A feature can mature as an extension first, and proven capabilities can later move closer to the core.
One of the most visible MCP extensions is MCP Apps.
MCP tools traditionally return text, structured JSON, or resources.
Some tasks need an interface.
Examples include dashboards, charts, maps, forms, task boards, configuration panels, design canvases, and video players.
MCP Apps allows a server to declare a UI resource that the host renders in a sandboxed iframe.
A simplified flow is:
MCP Apps is already supported by multiple compatible hosts, including Claude and other MCP-aware development products.
The official extension package can be installed with:
npm install -S @modelcontextprotocol/ext-apps
The official examples repository can be run locally with:
git clone https://github.com/modelcontextprotocol/ext-apps.git
cd ext-apps
npm install
npm start
These commands come from the official MCP Apps documentation and may change as the extension evolves.
Agent tools increasingly launch work that cannot finish during one ordinary HTTP request.
Examples include CI pipelines, large data processing jobs, cloud deployments, long research tasks, video rendering, and human approval workflows.
The MCP Tasks extension allows the server to return a durable task handle instead of blocking until the operation finishes.
The official extension defines methods including:
tasks/get
tasks/update
tasks/cancel
A task can move through states such as:
working
input_required
completed
cancelled
failed
The client can poll tasks/get.
If the server requires user input, the task can move to input_required.
The client can submit input through tasks/update.
This design works across disconnects and does not require one long-lived connection.
Tasks existed experimentally in the 2025-11-25 core specification.
The new Tasks extension is not simply a renamed copy of that old API.
Official SDK documentation warns that the newer Tasks extension is not wire-compatible with the earlier experimental implementation.
Applications that used the old Tasks feature should migrate rather than assuming automatic compatibility.
Enterprise deployments have a different authorization problem from consumer integrations.
A company may have thousands of employees and dozens of approved MCP servers.
It does not want every employee independently authorizing every connector.
The Enterprise-Managed Authorization extension allows organizations to centralize access control through an identity provider.
Supported enterprise IdP patterns may involve products such as Microsoft Entra ID, Okta, and corporate SSO systems.
The organization can decide which employees can access which MCP servers and when access should be revoked.
Employees authenticate using their corporate identity instead of separately completing an OAuth approval for every MCP server.
Official MCP documentation describes Enterprise-Managed Authorization as an extension rather than a feature active for every client by default.
Describe your idea once, and We0 AI can generate a showcase site, pages, and CMS, then help you attract customers and traffic after launch.
One complete project generation for free registration
Best for trying one complete generation flow and seeing a first project draft quickly.
Both the client and the organization’s identity infrastructure need to support it.
The core authorization work also receives several security improvements.
Authorization responses can include the iss issuer parameter.
Clients validate the issuer before redeeming an authorization code.
This helps protect against authorization-server mix-up attacks.
Registered client credentials should not be reused across unrelated authorization servers.
When the resource moves to another issuer, clients should register appropriately for that issuer.
The revision clarifies application_type behavior during Dynamic Client Registration.
This helps avoid cases where an authorization server treats a native CLI or desktop application as a web client and rejects local redirect URIs.
The MCP authorization project has been moving toward Client ID Metadata Documents, or CIMD, for new implementations while retaining DCR compatibility where required.
The practical recommendation is to follow the current authorization documentation rather than implementing client registration from an older MCP tutorial.
Tool schemas also become more expressive.
inputSchema and outputSchema support full JSON Schema 2020-12 features.
Input schemas can use:
oneOf
anyOf
allOf
$ref
$defs
conditionals
Output schemas are no longer restricted to one narrow object shape.
structuredContent can represent any JSON value supported by the schema.
This makes MCP tools easier to describe accurately when an API has union types, conditional fields, nested reusable definitions, multiple output shapes, arrays, or scalar results.
Three older core capabilities are formally deprecated:
| Feature | Recommended direction |
|---|---|
| Roots | Tool parameters, resource URIs, or server configuration |
| Sampling | Direct LLM-provider integration |
| Logging | stderr for stdio; OpenTelemetry for structured observability |
Deprecated does not mean removed immediately.
The new lifecycle policy provides at least a twelve-month window before a deprecated feature can become eligible for removal.
Current SDKs may continue supporting these capabilities for compatibility.
The stateless redesign contains breaking changes.
The maintainers have said they do not want that level of disruption to become normal.
The new feature lifecycle defines stages such as:
Active
Deprecated
Removed
A deprecated feature receives a minimum support window before removal.
Extensions can also evolve separately from the core.
This gives teams more predictable migration planning.
The protocol revision makes public remote MCP servers easier to scale.
Enterprises often have the opposite problem: they do not want the server to be public at all.
Anthropic’s MCP tunnels feature addresses that use case for Claude Managed Agents and supported Claude Platform workflows.
A lightweight gateway runs inside the enterprise network and makes an outbound connection.
Anthropic describes the model as:
Internal databases, ERP systems, private APIs, knowledge bases, and ticketing systems can remain behind the enterprise network boundary.
MCP tunnels remains a Claude product feature, not a core MCP protocol requirement.
Anthropic currently describes it as a research preview.
Both features improve production MCP, but they solve different problems.
| Feature | Problem solved |
|---|---|
| MCP Apps | Rich interactive interfaces inside MCP hosts |
| Tasks | Durable long-running tool operations |
| Enterprise-Managed Authorization | Centralized company access policy |
| MCP Tunnels | Access to private MCP servers without public exposure |
| Stateless MCP core | Scalable protocol transport |
| MRTR | Mid-call client input without long-lived protocol sessions |
A server may use one, several, or none of these features.
If a server already works with older MCP clients, developers do not necessarily need to rewrite everything immediately.
They should perform a structured migration.
Search for code that relies on:
Mcp-Session-IdAsk whether each dependency is protocol state, application state, authentication state, or temporary execution state.
Move application state into explicit handles or durable storage where appropriate.
Use an SDK version that supports the 2026-07-28 revision.
Then test with several server instances.
A useful test setup is:
Client
↓
Round-robin load balancer
↓
Server A / Server B / Server C
Send one multi-step workflow and confirm that consecutive requests can reach different instances without breaking the task.
For workflows that need state, return a stable identifier:
{
"job_id": "job_7f18c9"
}
Require later calls to include it:
{
"job_id": "job_7f18c9",
"action": "continue"
}
Validate every handle server-side.
Good handles should have strong entropy, tenant binding, authorization checks, expiration, revocation, and clear error handling.
If using Streamable HTTP, take advantage of headers such as:
Mcp-Method
Mcp-Name
Add routing, rate limits, metrics, WAF policies, and access logging.
Honor or generate:
ttlMs
cacheScope
for appropriate list and read responses.
Do not share user-specific sensitive cached data across users.
If the application used the experimental 2025-11-25 Tasks API, update it to the extension lifecycle.
Test:
tasks/get
tasks/update
tasks/cancel
and the input_required state.
Search for Roots, Sampling, and MCP Logging.
Plan migration toward explicit tool parameters or resource URIs, direct model-provider calls, and stderr or OpenTelemetry.
Verify issuer validation, redirect URIs, client registration, refresh tokens, scope handling, and identity-provider compatibility.
Enterprise deployments should evaluate whether EMA is appropriate.
Backward compatibility is an ecosystem issue, not just a server issue.
Keep a test matrix:
| Client | Protocol revision | Result |
|---|---|---|
| Current client | 2026-07-28 | Expected stateless path |
| Older client | 2025-11-25 | Compatibility path |
| Unsupported client | older/unknown | Clear negotiation failure |
Do not silently assume that every client upgrades at the same time.
Measure at minimum:
A stateless system is easier to scale, but distributed systems still need good observability.
A server stores a report object in memory:
sessions[session_id]["report"] = report
The next tool call expects to reach the same process.
The server stores durable state:
report_id = save_report(report)
return {"report_id": report_id}
The next tool receives:
{
"report_id": "report_123"
}
Any server instance can load the report.
The important change is architectural:
Hidden transport session state
→ explicit application state
Potentially, but not automatically.
Stateless deployment can reduce infrastructure complexity:
Caching can also reduce repeated metadata calls.
However, application state still has a cost.
If a workflow requires durable state, developers may still need Redis, a SQL database, object storage, a job queue, or a workflow engine.
The new design lets developers choose the storage architecture instead of having a protocol session force one.
The source article uses this analogy.
It is useful, but it should not be taken literally.
HTTP is a foundational web transport standard used across nearly every internet system.
MCP is a specialized protocol for connecting AI clients and agents to tools, resources, prompts, interfaces, and external services.
What the analogy captures is the direction of travel:
The 2026-07-28 redesign strengthens that analogy because MCP traffic now fits conventional stateless HTTP infrastructure more naturally.
Whether MCP reaches HTTP-like ubiquity is still an open question.
MCP originated at Anthropic, but it is now governed as a broader open-source protocol project.
The ecosystem includes independent maintainers, working groups, Specification Enhancement Proposals, SDKs in multiple languages, MCP Apps, Tasks, enterprise authorization extensions, a registry, and implementations in multiple AI products.
MCP Apps, for example, was developed with contributors from the MCP community and participants from Anthropic, OpenAI, and MCP-UI.
This matters because a protocol becomes more valuable when both clients and servers can implement it without depending on one vendor.
The official MCP project maintains or recognizes SDK implementations across several languages.
Key repositories include TypeScript, Python, Go, C#, and other ecosystem SDKs.
The June 2026 release-candidate announcement specifically highlighted beta support for four Tier 1 SDKs:
By late July, current SDK documentation already includes 2026-07-28 behaviors.
Because SDK adoption happens independently, always check the release notes for the exact language and version you use.
For production systems, avoid a “flag day” migration.
A safer process is:
2026-07-28 clients.This is especially important because the new revision intentionally changes core lifecycle behavior.
The protocol supports serverless deployment more naturally.
Your application may still require a database, durable job runner, file storage, or long execution time.
Only protocol-level session state is removed from the new wire model.
Application state remains an application concern.
Extensions are negotiated and host support varies.
The current Tasks extension differs from the experimental earlier implementation.
Roots, Sampling, and Logging remain available during their deprecation window.
2026-07-28SDK and product adoption proceeds at different speeds.
MCP can execute powerful tools.
Authorization, user consent, sandboxing, tool design, secrets management, and auditing still matter.
MCP 2026-07-28 is the largest architectural revision of the Model Context Protocol since launch. Its main changes include a stateless protocol core, removal of the new-wire-format session handshake, first-class extensions, MCP Apps, redesigned Tasks, MRTR, stronger authorization, cache metadata, and a formal deprecation policy.
The 2026-07-28 protocol layer is designed to be stateless. Applications can still keep state through explicit handles, databases, workflow systems, or other durable storage.
Mcp-Session-Id?The 2026-07-28 wire format removes the protocol-level Mcp-Session-Id mechanism. Current SDKs may still support session-based behavior when negotiating older protocol revisions for backward compatibility.
The stateless protocol makes serverless and edge deployment much easier because requests no longer require protocol-level session affinity. Your server still needs to fit the runtime’s execution, networking, storage, and duration constraints.
MCP Apps is an official extension that lets tools return interactive interfaces such as dashboards, forms, charts, and other HTML experiences rendered inside compatible MCP hosts. The UI runs in a sandboxed iframe and communicates through the MCP host.
Tasks let a server return a durable asynchronous task handle for long-running work. Clients can poll status with tasks/get, provide required input through tasks/update, or cancel the operation with tasks/cancel.
Enterprise-Managed Authorization is an MCP extension for centralized access control through an organization’s identity provider. It allows IT administrators to manage MCP server access through corporate identity policy rather than requiring each user to authorize every server separately.
Not necessarily. SDKs can support older protocol revisions through version negotiation, and deprecated features receive a defined support window. Production teams should still begin testing because the stateless design changes assumptions around sessions, long-running operations, and infrastructure.
The MCP 2026-07-28 revision moves the protocol toward the infrastructure patterns already common in large web systems. Requests become self-contained, the protocol-level session disappears from the new wire format, gateway routing becomes easier, and ordinary horizontal scaling no longer requires sticky MCP sessions.
At the same time, the ecosystem is growing upward. MCP Apps adds interactive UI, Tasks supports durable asynchronous work, Enterprise-Managed Authorization centralizes enterprise access, and MCP tunnels give Claude Platform users a path to private internal servers.
The migration is not simply “delete session IDs.” Teams need to identify hidden state dependencies, move application state into explicit handles or durable storage, test MRTR and Tasks, update authorization, preserve compatibility with older clients, and add proper observability.
The most important change is architectural: MCP is moving from a connection-oriented agent integration pattern toward a stateless, extensible protocol that fits modern cloud infrastructure much more naturally.
Start from one sentence and have a complete website in minutes.
