MCP 2026-07-28 Explained: Stateless Servers, MCP Apps, Tasks, Enterprise Auth, and the New Agent Infrastructure

Introduction

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.

MCP Adoption Has Accelerated Rapidly

The source report highlights the speed at which MCP usage has grown.

According to the Claude Developers launch communication cited by the source article:

• Monthly MCP SDK downloads exceeded 400 million.
• Monthly SDK usage had grown roughly fourfold during the year.
• TypeScript and Python SDK cumulative downloads had each crossed very large milestones.
• Hundreds of MCP integrations were already available through Claude’s connector ecosystem.

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:

• Sticky sessions.
• Shared session stores.
• Horizontal scaling.
• Serverless deployment.
• Gateway routing.
• Authentication complexity.
• Long-running agent operations.
• Interactive interfaces.
• Backward compatibility.
• Protocol evolution.

Why the Previous Stateful Design Became a Scaling Problem

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:

• Sticky load-balancer routing.
• A shared session store.
• Session replication.
• Session expiration logic.
• Failover handling.
• Connection-aware observability.
• Special treatment for server restarts.

The MCP maintainers concluded that these requirements were too deeply embedded in the protocol itself.

The new revision removes that assumption.

MCP Is Now Stateless at the Protocol Layer

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.

The initialize Handshake Is Removed from the New Wire Format

The 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.

Stateless Protocol Does Not Mean Stateless Applications

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.

Why Explicit Handles Can Be Better

A visible handle has several advantages.

The model can:

• Pass it between related tools.
• Reason about which handle belongs to which task.
• Include it in logs.
• Restore it after a retry.
• Give it to another workflow step.

The server can:

• Validate the handle.
• Expire it.
• Bind it to a user or tenant.
• Reject stale state.
• Store the actual state in a database.

Stateless MCP therefore moves state management out of the transport and into explicit application design.

Serverless and Horizontal Scaling Become Much Easier

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:

• AWS Lambda.
• Cloudflare Workers.
• Vercel.
• Other serverless functions.
• Container autoscaling platforms.
• Ordinary stateless Kubernetes deployments.
• Edge environments.

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.

Round-Robin Load Balancing Becomes a Natural Default

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:

• Autoscaling.
• Instance replacement.
• Failure recovery.
• Rolling deployments.
• Multi-region routing.
• Infrastructure simplicity.

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.

Multi Round-Trip Requests Replace Persistent Mid-Call Connections

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.

Header-Based Routing Makes MCP Friendlier to Gateways

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:

• Route all search tools to one pool.
• Apply stricter limits to destructive operations.
• Record latency by tool name.
• Charge usage by method.
• Block disallowed tools at the gateway.
• Create separate reliability policies.

The protocol specification also requires consistency between the headers and the JSON-RPC body.

Servers should reject requests where they disagree.

List and Read Results Become Cache-Aware

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.

Distributed Tracing Is Standardized

The revision also documents W3C Trace Context propagation.

Keys such as:

• traceparent
• tracestate
• baggage

can 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.

Extensions Become First-Class Protocol Features

The protocol is also changing how optional functionality evolves.

The current framework gives extensions:

• Reverse-DNS identifiers.
• Capability negotiation.
• Independent versioning.
• Dedicated repositories.
• Delegated maintainers.
• A formal Extensions Track in the SEP process.

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.

MCP Apps: Interactive UI Inside the Conversation

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:

1. The tool declares a UI resource.
2. The model invokes the tool.
3. The host loads the UI in a sandbox.
4. Tool data is passed into the interface.
5. The user interacts with the app.
6. The app can request additional tool calls through the host.
7. The host keeps permission and audit controls around those actions.

MCP Apps is already supported by multiple compatible hosts, including Claude and other MCP-aware development products.

Basic MCP Apps Installation

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.

Tasks: Long-Running Work Without Blocking the Connection

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.

Important Compatibility Detail

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-Managed Authorization

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.

Both the client and the organization’s identity infrastructure need to support it.

Authorization Is Being Hardened More Broadly

The core authorization work also receives several security improvements.

RFC 9207 Issuer Validation

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.

Client Credentials Stay Bound to Their Issuer

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.

Better Desktop and CLI Registration

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.

CIMD Is the Direction for New Client Registration

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.

Full JSON Schema 2020-12 for Tools

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.

Roots, Sampling, and Logging Are Deprecated

Three older core capabilities are formally deprecated:

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.

A Formal Deprecation Policy Changes MCP Upgrade Risk

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.

MCP Tunnels Solve a Different Enterprise Problem

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:

• No public MCP endpoint.
• No inbound firewall rule.
• No public IP requirement.
• End-to-end encrypted traffic.

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.

MCP Apps and Tunnels Should Not Be Confused

Both features improve production MCP, but they solve different problems.

A server may use one, several, or none of these features.

What Changes for Existing MCP Server Developers?

If a server already works with older MCP clients, developers do not necessarily need to rewrite everything immediately.

They should perform a structured migration.

Step 1: Inventory Hidden Session Dependencies

Search for code that relies on:

• Mcp-Session-Id
• in-memory per-session dictionaries
• sticky routing
• connection-local client state
• initialization-only capability storage
• server-instance affinity

Ask 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.

Step 2: Test Stateless Request Handling

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.

Step 3: Add Explicit State Handles

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.

Step 4: Update Gateway Rules

If using Streamable HTTP, take advantage of headers such as:

Mcp-Method
Mcp-Name

Add routing, rate limits, metrics, WAF policies, and access logging.

Step 5: Add Cache Support

Honor or generate:

ttlMs
cacheScope

for appropriate list and read responses.

Do not share user-specific sensitive cached data across users.

Step 6: Migrate Old Tasks

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.

Step 7: Review Deprecated Features

Search for Roots, Sampling, and MCP Logging.

Plan migration toward explicit tool parameters or resource URIs, direct model-provider calls, and stderr or OpenTelemetry.

Step 8: Retest Authorization

Verify issuer validation, redirect URIs, client registration, refresh tokens, scope handling, and identity-provider compatibility.

Enterprise deployments should evaluate whether EMA is appropriate.

Step 9: Test Older Clients

Backward compatibility is an ecosystem issue, not just a server issue.

Keep a test matrix:

Do not silently assume that every client upgrades at the same time.

Step 10: Add Observability Before Production

Measure at minimum:

• Request count.
• Tool name.
• Latency.
• Error rate.
• Task duration.
• Input-required frequency.
• Cache hits.
• Authentication failures.
• Downstream API latency.
• Trace IDs.

A stateless system is easier to scale, but distributed systems still need good observability.

Example: Before and After Migration

Before

A server stores a report object in memory:

sessions[session_id]["report"] = report

The next tool call expects to reach the same process.

After

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

Does Stateless MCP Mean Lower Cost?

Potentially, but not automatically.

Stateless deployment can reduce infrastructure complexity:

• No shared MCP session store.
• Less sticky routing.
• Easier autoscaling.
• Easier serverless deployment.
• Simpler failover.

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.

Is MCP Becoming the “HTTP of AI”?

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:

• One standard interface.
• Many independent servers.
• Many compatible clients.
• Shared conventions.
• Infrastructure that can route and observe requests generically.

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.

The Ecosystem Is Broader Than Claude

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.

Current SDK Landscape

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:

• TypeScript.
• Python.
• Go.
• C#.

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.

A Safer Migration Strategy

For production systems, avoid a “flag day” migration.

A safer process is:

1. Upgrade a development environment.
2. Run conformance tests.
3. Test 2026-07-28 clients.
4. Test older clients.
5. Enable stateless deployment in staging.
6. Add multiple server instances.
7. Force requests across instances.
8. Test authentication.
9. Test long-running Tasks.
10. Test application-state handles.
11. Monitor latency and errors.
12. Roll out gradually.

This is especially important because the new revision intentionally changes core lifecycle behavior.

What Not to Assume

Do Not Assume Every Server Is Automatically Serverless

The protocol supports serverless deployment more naturally.

Your application may still require a database, durable job runner, file storage, or long execution time.

Do Not Assume All State Disappears

Only protocol-level session state is removed from the new wire model.

Application state remains an application concern.

Do Not Assume MCP Apps Work in Every Client

Extensions are negotiated and host support varies.

Do Not Assume Tasks Are Backward Compatible

The current Tasks extension differs from the experimental earlier implementation.

Do Not Assume Deprecated Means Broken

Roots, Sampling, and Logging remain available during their deprecation window.

Do Not Assume All Clients Already Speak 2026-07-28

SDK and product adoption proceeds at different speeds.

Do Not Assume “Open Protocol” Means “No Security Work”

MCP can execute powerful tools.

Authorization, user consent, sandboxing, tool design, secrets management, and auditing still matter.

常见问题

What is MCP 2026-07-28?

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.

Is MCP completely stateless now?

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.

What happened to 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.

Can I deploy an MCP server on AWS Lambda or Cloudflare Workers?

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.

What are MCP Apps?

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.

What are MCP Tasks?

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.

What is Enterprise-Managed Authorization?

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.

Do I have to migrate immediately from the older MCP version?

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.

相关工具

• Model Context Protocol: Official documentation for the MCP specification, architecture, SDKs, extensions, and developer guides.
• MCP TypeScript SDK: Official TypeScript implementation for MCP clients and servers.
• MCP Python SDK: Official Python SDK and examples for MCP development.
• MCP Go SDK: Official Go implementation with current support for the stateless protocol path.
• MCP C# SDK: Official .NET SDK with detailed documentation for stateless mode, Tasks, and compatibility.
• MCP Apps: Official extension documentation and SDK for interactive interfaces inside MCP hosts.
• MCP Tasks: Official documentation for long-running asynchronous MCP operations.
• MCP Registry: Official registry infrastructure for discovering published MCP servers.

Related Links

• MCP 2026-07-28 Release Candidate Overview: Official maintainer explanation of the stateless redesign, extensions, auth changes, caching, and deprecations.
• MCP Specification Repository Releases: Official GitHub release history for protocol revisions.
• MCP 2026 Roadmap: Official roadmap covering transport scalability, agent communication, governance, and enterprise readiness.
• MCP Apps Official Documentation: Specification, SDK, examples, and developer guides for interactive MCP applications.
• MCP Tasks Extension: Official Tasks specification, lifecycle, security model, and supported methods.
• Enterprise-Managed Authorization: Official documentation for centralized identity-provider-based MCP access.
• Anthropic MCP Tunnels: Anthropic’s documentation for private-network MCP connectivity in Claude Managed Agents.

Summary

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.