MCP in 2026: What session-free HTTP Means for AI Agent Integrations

On July 28, 2026, the Model Context Protocol released its 2026-07-28 specification, removing the initialize handshake and Mcp-Session-Id header from the modern protocol flow. This makes requests separate from a protocol-based session tied to a specific server instance.

This change allows MCP servers to run behind standard round-robin load balancing without requiring protocol-based session storage or sticky routing.

For teams running AI agent integrations in production, it turns MCP system setup into a scaling problem you already know how to solve because it's the same problem as scaling any stateless HTTP API.

---

Key Highlights

• The initialize/initialized handshake and Mcp-Session-Id are removed from the modern protocol flow. Requests now carry the information needed to process them without relying on a protocol-based session.
• A new server/discover RPC replaces the handshake for capability exchange, callable once up front or used as a fallback probe.
• Multi-Round-Trip Requests (MRTR) replace server-initiated calls like elicitation/create; servers return an input_required result instead of holding an open stream and a blocked worker.
• Tasks moved out of core into a formal extension, using polling (tasks/get) instead of a blocking result call.
• Adoption is already large. Combined Tier 1 SDK downloads are running near half a billion a month, and version negotiation means old stateful clients keep working unchanged.

---

Why This Matters Right Now

Before the 2026-07-28 release, Streamable HTTP connections used an initialization handshake. The client and server negotiated capabilities, the server established a session, and subsequent requests used the resulting session identifier.

This is a decent approach in the context of a single long-running desktop client connected to one local server, but a poor fit for fleets of AI agents connecting to a shared MCP server via a load balancer, since the session ID binds each client to the instance of MCP that issued it.

This session model was a major obstacle to horizontal scaling; if an instance issuing a particular session ever restarted, got moved out of the pool, or terminated during a deploy, in-flight agent calls using that session would fail.

Teams could address these limits with sticky routing, a shared session store such as Redis, or other session-aware deployment patterns. These approaches add infrastructure and management complexity to scaled across more servers MCP deployments.

What Actually Changed: MCP 2025-11-25 vs. MCP 2026-07-28

The new specification does not prohibit application state; it removes protocol-based session state. If an MCP server needs to keep state across calls, that state should be represented explicitly through application-level identifiers or handles rather than relying on the transport to remember it.

---

Stateful MCP vs. Stateless MCP: The Decision Your Team Actually Faces

Most teams aren't choosing the wire protocol version directly; they're choosing an infrastructure pattern, and the protocol change is what makes the new pattern viable. Getting this decision right is often less about the protocol itself and more about a deliberate AI strategy consulting exercise around how your agents will actually be deployed.

Neither pattern is in every case right. A desktop coding assistant talking to a single local MCP server over stdio has no scaling problem to solve, and the deprecation window means nothing forces that server to change today.

The decision is between whether you have your MCP servers behind a load balancer serving many concurrent agents (in which case the stateless core is the pattern the ecosystem is moving towards).

---

Six Signs Your MCP Deployment Needs This Migration

Not every MCP deployment needs an immediate migration. However, certain infrastructure patterns can indicate that your current setup is carrying unnecessary state and operational complexity.

Here are six signs that your MCP deployment may benefit from reviewing its session and state-management architecture.

1. You're Running Sticky Sessions at the Load Balancer

If your infrastructure team has created special routing rules specifically for MCP traffic, your deployment is likely relying on session affinity.

Sticky sessions force requests from the same client to reach the same server. A stateless MCP architecture can remove this dependency, allowing requests to be distributed across available servers without keeping client-to-instance mappings.

2. You Keep a Separate Session Store for MCP

Some deployments use Redis or another shared store solely to keep Mcp-Session-Id mappings.

While this works, it adds another infrastructure component to operate, monitor, secure, and scale. If MCP session state can be removed from the protocol layer, this dedicated storage layer may no longer be necessary.

3. Autoscaling Your MCP Servers Is Difficult

Stateful sessions can complicate autoscaling.

An instance cannot always be terminated or replaced safely when it is holding active session state. This can limit how quickly your platform scales MCP servers, which is exactly the kind of bottleneck DevOps consulting work is built to untangle.

A stateless design lets you add or remove instances more freely as traffic changes.

4. You Want to Run MCP on Serverless or Edge Infrastructure

Serverless and edge platforms work best when applications do not depend on long-lived, instance-specific state.

A stateless MCP architecture fits more naturally with standard HTTP load balancing and platforms such as Function-as-a-Service (FaaS). This can make it easier to deploy MCP servers across modern API development infrastructure in the cloud.

5. Elicitation or Sampling Calls Time Out Under Load

If elicitation or sampling flows create long-lived requests or consume server resources while waiting for client input, your architecture may benefit from the MRTR model.

MRTR is designed to address this type of bottleneck by allowing these interactions to be handled without unnecessarily blocking the server's processing capacity.

6. You Support MCP Clients With Different Protocol Expectations

Supporting both older stateful clients and newer stateless clients can create compatibility challenges.

Version negotiation through server/discover can help a gateway determine which protocol behavior a client supports. This makes it possible to gradually introduce the newer architecture without immediately breaking existing MCP clients.

The key takeaway: if several of these patterns exist in your MCP deployment, the migration is not just a protocol change. It can also simplify load balancing, scaling, infrastructure management, and client compatibility.

---

The Core Pillars of MCP 2026-07-28

The MCP 2026-07-28 revision introduces several major protocol changes and extensions. Rather than treating the update as a single "stateless MCP" change, it is more useful to understand each proposal separately. Many of these changes can be adopted incrementally, depending on your architecture and client support. Because the underlying SDKs and reference implementations are community-maintained, teams evaluating a migration often lean on open source consulting to vet which parts of the ecosystem are production-ready versus still maturing.

1. Sessionless Core

The traditional initialize and notifications/initialized handshake is removed from the protocol flow.

Instead, requests carry the information needed to process them without depending on a protocol-based session. In Streamable HTTP, the protocol version is communicated through the MCP-Protocol-Version header.

When a client and server do not support the same protocol version, the server returns an explicit UnsupportedProtocolVersionError. This creates a clearer failure path than allowing version mismatches to fail silently.

2. server/discover

The new server/discover RPC allows servers to advertise their supported protocol versions, capabilities, and identity.

Clients can call it before sending other requests to select a compatible protocol version. It can also work as a backward-compatibility check for STDIO-based integrations.

This is particularly useful during migration, when a gateway or client may need to support both legacy clients and the newer stateless protocol.

3. Multi Round-Trip Requests (MRTR)

Multi Round-Trip Requests (MRTR) change how servers handle interactions that require additional client input.

Instead of keeping a connection open for server-initiated requests such as roots/list, sampling/createMessage, or elicitation/create, the server returns an InputRequiredResult. The inputRequests field specifies what information is needed, and the client provides inputResponses when retrying the original request.

Each result now identifies its state through resultType: either complete or input_required.

This creates a clearer request-response cycle without requiring the server to hold a connection open while waiting for the client.

4. Cacheable List Results

The revision adds caching controls to several MCP operations, including tools/list, resources/list, prompts/list, resources/read, and resources/templates/list.

Servers return ttlMs and cacheScope values, allowing clients to determine how long results can be cached and whether shared intermediaries can cache them.

The specification also requires tools returned by tools/list to use a deterministic order. This can improve prompt-cache reuse when tool definitions are repeatedly injected into LLM contexts.

This can reduce repeated network requests and, when cached tool definitions are reused effectively, reduce the amount of tool metadata repeatedly sent to an LLM.

5. Tasks as an Official Extension

Experimental task functionality has been moved out of the core protocol into an official extension.

The extension replaces the blocking tasks/result approach with tasks/get for checking for updates and introduces tasks/update for client-to-server input. Servers can also return task handles without requiring per-request opt-in.

This is particularly useful for long-running agent workflows. A multi-minute data pipeline, document-processing job, or other background task can be handled asynchronously as part of a broader automation services strategy instead of depending on one request remaining open until the operation finishes.

6. Authorization Hardening

The revision also strengthens authorization for multi-server MCP environments.

Public clients must validate the iss parameter in authorization responses under RFC 9207. This helps protect against authorization-response attacks in architectures involving multiple servers.

Clients must also explicitly identify the MCP server a token is intended for under RFC 8707. This helps address the confused deputy problem, where a token issued for one server could otherwise be misused against another.

This becomes increasingly important as MCP deployments become more distributed. A stateless, horizontally scaled architecture can involve more MCP servers within the same organization, increasing the importance of clearly separating authentication and authorization between those servers.

---

What a Stateless MCP Migration Includes

Migrating to the newer MCP architecture is more than updating a dependency or changing a few protocol calls. It is both an infrastructure migration and a protocol migration.

At a minimum, the process should cover the following areas:

1. Audit Existing Session State

Start by identifying MCP server logic that depends on connection-specific state.

This includes pagination cursors, partially completed elicitation flows, per-connection caches, and other data that currently lives only for the duration of a session.

The goal is to identify every place where the server assumes that subsequent requests will return to the same instance, work that often surfaces as part of a wider digital transformation audit rather than a narrow protocol review.

2. Convert Implicit State Into Explicit Handles

State that still needs to persist should be represented explicitly rather than tied to a server session.

For example, a server can return an application-level operation ID or handle that the client passes back in a later request. This allows another server instance to continue the operation without depending on session affinity.

3. Add server/discover and Version Fallback

Implement server/discover so clients can determine the protocol versions and capabilities supported by the server.

During a gradual rollout, version-negotiation fallback is also important. Legacy stateful clients should continue working while newer clients adopt the stateless flow.

4. Replace Blocking Server-Initiated Calls

Existing elicitation and sampling flows that depend on server-initiated requests should be migrated to the MRTR pattern.

Instead of keeping a connection blocked while waiting for client input, the server can return an input_required result and continue the interaction through a subsequent request.

5. Add Response Caching Controls

Update relevant list endpoints to return ttlMs and cacheScope.

At the same time, enforce deterministic ordering for tools/list responses. This allows clients and intermediaries to cache results more effectively and can improve prompt-cache reuse when tool definitions are repeatedly provided to an LLM.

6. Move Long-Running Work to Tasks

Long-running operations should be moved to the tasks extension rather than relying on an open connection.

Use tasks/get for polling task status and the appropriate task mechanisms for exchanging additional input. This makes background processing more resilient to connection changes and server restarts.

7. Harden OAuth and Authorization

Review the authorization flow as part of the migration.

This includes implementing issuer verification under RFC 9207, using resource indicators under RFC 8707, and moving away from Dynamic Client Registration where practical. These changes become particularly important when MCP deployments contain multiple servers and authorization boundaries.

8. Test Without Session Affinity

Finally, test the architecture behind ordinary round-robin load balancing.

The purpose is not simply to confirm that the new protocol works. The test should demonstrate that successive requests can reach different server instances without depending on protocol-based session state.

If the system only works when sticky sessions are enabled, the underlying session dependency has probably been moved rather than actually removed.

The key test: after migration, any MCP server instance should be able to handle the next request without needing to know which instance handled the previous one.

---

Engagement Models for MCP Migration Work

These are starting points, not quotes, actual pricing depends on how many servers are in scope, how much implicit session-state logic has accumulated, and whether legacy stateful clients need to be supported during a transition window. RejoiceHub's AI integration consulting team can assess the existing MCP architecture during a technical discovery process before proposing a project scope.

---

Conclusion

MCP's 2026-07-28 specification does not fundamentally change what agents can do with tools. Instead, it changes how MCP infrastructure can be deployed and operated at scale.

Sessions are removed, list results can be cached, long-running tasks have a proper polling model, and authorization is designed for environments running multiple MCP servers.

The transition period gives teams time to plan rather than rush the migration.

For engineering teams, the practical question is simple: are your MCP servers still dependent on sticky sessions and a shared session store?

If yes, the 2026-07-28 specification provides a clear opportunity to review that dependency and plan a migration based on your deployment requirements.