New MCP 2026-07-28: Stateless Core Brings MCP Closer to Internet-Scale Infrastructure

On July 28, 2026, MCP released one of its most significant updates since the protocol was introduced. The main changes include a Stateless Protocol Core, a standardized Extensions framework, Tasks, MCP Apps, stronger OAuth/OIDC authorization, and a formal deprecation policy.

What Does Stateless Core Change?

In earlier MCP versions, a client had to perform an initialize/initialized handshake. The server then issued an Mcp-Session-Id, which had to be included in subsequent requests.

As a result, running an MCP server at scale often required:

• Sticky sessions at the load balancer
• A shared session store across server instances
• Session recovery logic when connections were interrupted
• Gateways that inspected JSON-RPC request bodies for routing

MCP 2026-07-28 removes the mandatory handshake and protocol-level sessions. Each request now carries the required protocol version, client information, and capabilities. Clients can also call server/discover to determine which protocol versions and features a server supports.

Previous MCP model

Client
  │
  │ initialize
  ▼
Server A ── creates Mcp-Session-Id
  ▲
  │
  │ Subsequent requests
  │ must return to Server A
  │
Sticky Session or Shared Session Store

With MCP 2026-07-28, each request can contain enough information to be handled by any compatible server instance.

MCP 2026-07-28

                         ┌── Server A
Client ── Load Balancer ─┼── Server B
                         └── Server C

Each request is independent.
The client is not tied to one instance.

HTTP headers such as MCP-Protocol-Version, Mcp-Method, and Mcp-Name also allow API gateways to route requests, enforce access policies, and observe traffic without parsing the full JSON-RPC body. List responses such as tools/list may also include ttlMs, allowing clients to cache them for an appropriate period.

Does Stateless Core make MCP suitable for serverless deployment?

Yes. Stateless Core opens the door for remote MCP servers to run more naturally on serverless, FaaS, and edge platforms.

Because every request is independent, an MCP server can be deployed on:

• Serverless functions
• Function-as-a-Service platforms
• Automatically scaling containers
• Edge runtimes
• Kubernetes without session affinity
• Multi-region backends behind a load balancer

Anthropic describes MCP 2026-07-28 as a move from a bidirectional, stateful protocol to a request-and-response model, making it easier to deploy MCP servers on serverless and edge infrastructure.

A reasonable conclusion is:

Stateless Core opens the door for remote MCP deployments on serverless and FaaS platforms while moving MCP closer to a production-grade HTTP workload that can scale globally like traditional Internet APIs.

However, MCP does not become a REST API. It still uses JSON-RPC and retains MCP-specific concepts such as tools, resources, prompts, Tasks, MCP Apps, and extension negotiation.

Stateless Core also does not automatically solve every serverless limitation. Long-running work can still be affected by:

• Function execution timeouts
• Cold starts
• Streaming limitations
• Connection limits
• Progress-tracking complexity
• Retries that generate duplicate operations

Long-running operations should therefore be moved to the Tasks extension, a queue, or a separate worker rather than keeping a function invocation open until the operation finishes.

Other Important Changes:

Multi-Round-Trip Requests

Some operations cannot be completed in a single request. A server may need additional information from the client or require the user to complete an intermediate step.

MCP 2026-07-28 supports Multi-Round-Trip Requests, or MRTR. A result can indicate:

• complete: the operation has finished
• input_required: the server needs additional input from the client

Client ── Request ─────────────> Server
Client <── input_required ───── Server

Client ── Additional input ───> Server
Client <── complete ─────────── Server

This reduces the need to maintain a long-lived connection or keep the same server instance active throughout a multi-step operation. It is therefore better suited to distributed and serverless infrastructure.

Header-Based Routing

In older setups, to figure out which tool the client wanted to call, the server or load balancer had to parse the full JSON body of every HTTP request. This wasted CPU cycles and slowed down systems at high volume.

With the new spec, key details are placed right in the HTTP headers: Mcp-Method (e.g., call_tool) and Mcp-Name (e.g., query_database).

• Real-world benefit: Infrastructure like AWS API Gateway, Nginx, or Cloudflare WAF can route traffic on the fly just by looking at the headers. You can easily route heavy image generation requests to GPU servers while sending standard queries elsewhere, all while handling rate limiting effortlessly at the network layer.

List Results Are Cacheable

Because the protocol is now stateless, clients no longer keep a persistent connection open to ask for available tools or prompts repeatedly.

To prevent redundant calls, list responses (tools/list, prompts/list, resources/list, and resources/read) now include two standard caching parameters:

• ttlMs (Time-to-Live): Tells the client how long (in milliseconds) the list will remain unchanged so it can be safely reused.
• cacheScope: Defines whether the cache applies globally across all users or strictly to a specific user. This helps IDEs and AI Agents launch and respond much faster.

Authorization Hardening

To support production-grade internet environments, security has been tightened up:

• Mix-Up Attack Prevention (RFC 9207): Requires strict iss (Issuer) validation, ensuring the client connects only to the legitimate Authorization Server.
• Switching from DCR to CIMD: Instead of allowing clients to register dynamically (Dynamic Client Registration), MCP now uses CIMD (Client ID Metadata Documents). Clients must use static, pre-approved metadata with fixed Client Credentials per issuer, reducing database overhead and giving admins full visibility over incoming calls.

Tasks (Asynchronous Task Handling)

In a Serverless/Stateless setup, HTTP requests often have strict timeouts. If an AI agent needs to process a massive dataset that takes 30 minutes, a standard HTTP request would time out.

The Tasks extension (io.modelcontextprotocol/tasks) solves this:

• How it works: When receiving a long-running job, the server responds immediately with a Task ID instead of making the client wait.
• Progress tracking: The client can check in periodically using tasks/get (Polling) or listen for passive updates via subscriptions/listen. Once finished, the result is delivered smoothly, decoupling API response times from actual background processing time.

Deprecated Features

Deprecated does not mean immediately removed. A deprecated feature remains part of the specification, but new implementations should not adopt it, and existing implementations should prepare to migrate away from it.

Important deprecations include:

• Roots: Pass files or directories through tool parameters, resource URIs, or server configuration instead.
• Sampling: Servers should integrate directly with LLM provider APIs rather than asking the MCP client to generate completions.
• Logging: Use stderr for stdio-based servers and OpenTelemetry for production observability.
• Dynamic Client Registration: Migrate to Client ID Metadata Documents.
• Some older Sampling includeContext values are also deprecated
• The legacy HTTP+SSE transport is also considered to be officially deprecated, with a year-long offramp.

Legacy HTTP+SSE is being replaced

This is one of the easiest areas to misunderstand.

MCP previously used an older remote transport commonly referred to as HTTP+SSE. It relied on two endpoints and a long-lived SSE connection.

Legacy HTTP+SSE

Client ── GET /sse ───────────────> Server
Client <── SSE connection ───────── Server
Client ── POST /messages?... ─────> Server
Client <── Response over SSE ────── Server

The legacy HTTP+SSE transport from protocol version 2024-11-05 was replaced by Streamable HTTP in version 2025-03-26.

These are different transports. Streamable HTTP may still return an SSE stream for an individual request, but that does not mean it uses the old HTTP+SSE transport mode

Legacy HTTP+SSE

GET /sse
Long-lived SSE connection
Messages sent through a separate POST endpoint

                 ↓ migration

Streamable HTTP 2026-07-28

POST /mcp
Each JSON-RPC message is a separate HTTP request
The response may be JSON or request-scoped SSE
No GET stream endpoint
No MCP protocol-level session

It was replaced by Streamable HTTP starting with MCP 2025-03-26. MCP 2026-07-28 continues this transition by making the protocol core stateless.

What Should Existing MCP Servers Prepare?

Production systems should not be upgraded all at once. A safer approach is to support both the old and new protocol eras during the migration period.

1. Identify State Hidden Inside Sessions

Review any data associated with:

• Mcp-Session-Id
• In-memory sessions
• Sticky routing
• Persistent connections or SSE streams
• Authentication context initialized only once
• Workspaces, transactions, or jobs tied to one server instance

Any business state that must survive across requests should move to external storage or be represented by an explicit handle.

2. Support Old and New Protocol Versions Simultaneously

During migration, servers should:

• Keep the 2025-11-25 flow available for older clients
• Add support for 2026-07-28
• Return supported versions when receiving an incompatible protocol version
• Implement server/discover
• Track request traffic by protocol version

The specification allows clients and servers to support multiple protocol versions at the same time.

3. Use Canary Rollouts Rather Than Business-Oriented A/B Testing

For a protocol migration, the goal is compatibility validation rather than comparing user behavior.

A safer rollout sequence is:

1. Internal traffic and integration testing
2. A small canary group of clients or tenants
3. A limited percentage of production traffic
4. Gradual expansion if error rates, latency, and retries remain stable
5. Removal of the old protocol only after legacy client usage becomes sufficiently low

Avoid randomly switching the same client between two protocol versions within one workflow. This could create inconsistent state or unpredictable behavior.

4. Migrate the Transport

• Keep legacy HTTP+SSE temporarily if older clients still depend on it.
• Publish a Streamable HTTP endpoint.
• Measure how many connections still use the old /sse endpoint.
• Announce a clear retirement date.
• Validate Origin headers, authentication, request timeouts, and security policies for every POST request.

5. Review Retries and Idempotency

When an MCP server runs behind a load balancer or on FaaS infrastructure, a request may be retried and handled by a different instance.

Tools that create side effects should support an idempotency key or another mechanism that prevents the same operation from being executed more than once.

What Must MCP Clients, IDEs, and CLIs Change?

Most end users may only need to update their IDE, CLI, or agent tool to a version that supports MCP 2026-07-28.

Client implementations, however, need to handle several changes:

• Support server/discover and protocol version negotiation
• Attach the protocol version, client information, and capabilities to each request
• Stop depending on Mcp-Session-Id
• Support MRTR and requestState
• Support the updated Streamable HTTP behavior
• Detect Tasks and Extensions through capability negotiation
• Cache list results according to the server-provided TTL
• Fall back to the legacy handshake when connecting to an older server

For example, the TypeScript SDK v2 can probe a server through server/discover and fall back to the 2025 handshake if the server does not support the new protocol.

Upgrading an SDK also does not always change the protocol used on the wire automatically. Some SDKs require explicit opt-in before they begin sending requests using the 2026 protocol.

Endpoint configuration only needs to change if the client currently uses:

• The legacy /sse endpoint
• The old HTTP+SSE transport
• A new endpoint URL published by the MCP server provider

For local tools using stdio, the impact is generally smaller. However, protocol negotiation, deprecated capabilities, and SDK compatibility should still be tested.

What Should Agents and Agent Skills Prepare?

If an Agent or Agent Skill invokes tools through a standard MCP client SDK, most of the protocol migration should be handled by the SDK and host application.

However, workflows should be reviewed if they:

• Depend on implicit session state across multiple tool calls
• Use Roots to receive workspace information
• Depend on client-side Sampling
• Expect a long-lived SSE connection
• Assume a long-running tool call will return synchronously
• Store Mcp-Session-Id or manually manage the initialization handshake

Agent Skills should pass state explicitly through tool arguments, handle taskId, support resume and retry behavior, and avoid assuming that the next request will reach the same server instance.