The July 28, 2026 Model Context Protocol (MCP) Release Candidate introduced several significant enhancements, including MCP Apps, Tasks, an extensible protocol framework, and improvements to authorization and transport.
Each of these additions expands what developers can build with MCP.
However, one architectural change has the potential to shape how enterprise AI systems are deployed for years to come:
Model Context Protocol is becoming stateless
The official MCP announcement explains the protocol changes in detail. This article takes a different perspective.
Instead of focusing on what changed, we will explore why it matters, particularly for organizations building AI applications that interact with enterprise systems and data.
As AI moves from experimentation to production, architecture becomes just as important as intelligence.
What does "stateless" actually mean?
"Stateless" is one of those technical terms that often sounds more complicated than it really is. The easiest way to understand it is through an everyday example.
Layman’s lens
Example: Coffee order: Imagine visiting your favorite coffee shop every morning. The barista recognizes you, remembers your name, your favorite drink, and that you prefer oat milk with an extra shot of espresso. You simply smile and say, "The usual."
This is a stateful interaction. The barista remembers information from previous visits, allowing future interactions to be shorter and more personalized.
Now think of ordering through a mobile app instead.
Every order includes your name, drink preference, pickup location, and payment information. Any barista can prepare your coffee because everything required to fulfill the order is included in the request itself. Nobody needs to remember your previous visit.
This is a stateless interaction.
Technical lens
In software systems, a stateful protocol maintains information about previous interactions between a client and server. Future requests often depend on that stored context, making the connection itself part of the application's state.
A stateless protocol treats every request independently. Each request carries the information the server needs to process it without relying on previous interactions.
Stateless doesn’t mean memoryless. Applications can still maintain conversation history, authentication, workflows, or user preferences. The difference is that this state is managed explicitly by the application rather than implicitly by the protocol.
Modern web applications have widely adopted this architectural approach through REST APIs because it simplifies scaling, load balancing, and fault tolerance.
The key idea is simple:
“A stateful system remembers previous interactions. A stateless system treats every request independently by including everything needed to process that request.”
Why it matters
As organizations deploy AI agents across sales, customer support, engineering, and operations, the number of interactions between AI applications and enterprise systems grows rapidly.
A stateless protocol allows those interactions to be distributed efficiently across modern cloud infrastructure. The result: AI applications that scale horizontally, recover from failures, and run more cleanly in production.
How earlier versions of MCP worked
Before the July 28 Release Candidate, MCP relied on protocol-level sessions to maintain communication between clients and servers.
When an AI client connected to an MCP server, the server maintained information about that session throughout the interaction. Subsequent requests depended on that established session.
This approach simplified certain workflows but introduced operational challenges as deployments grew. Some of the challenges:
Requests often needed to return to the same server instance.
Load balancers had to maintain sticky sessions.
Server failures could interrupt active conversations.
Scaling horizontally required additional infrastructure to preserve or share session state.
These are familiar challenges. Before REST APIs became the dominant architectural style, many web applications relied on server-side sessions and faced similar scalability limitations.
Example: Bank customer support: Picture a call with your bank's customer support. Before discussing your account, the representative asks you to verify your identity by providing your account number, date of birth, and a security code. Once verified, you can ask multiple questions without repeating your information because the representative remembers your session.
This is a stateful interaction. The conversation depends on the context established at the beginning of the call.
What changed in the July 28 release?
The move to a stateless architecture is more than a protocol update. It changes how MCP clients and servers communicate, manage context, and operate in distributed environments.
1. Connection handshakes are no longer required
Layman's lens
Example: Hotel check-in: Let’s say you are walking into a hotel every morning and checking in at the front desk before you can ask a question.
You have to identify yourself, confirm your reservation, and receive your room information before you can request fresh towels or ask for directions.
Now suppose carrying a digital room key on your phone.
Whenever you need something, you simply present your room key. The hotel immediately knows who you are and can help without repeating the entire check-in process.
That is essentially what changed in MCP.
Technical lens
Earlier versions of MCP required an initialize and initialized handshake before any meaningful work could begin. During this exchange, the client and server negotiated the protocol version, exchanged client information, and advertised their capabilities.
The Release Candidate removes this requirement.
Instead, protocol version and client information are included in the _meta field of every request. When a client needs to discover server capabilities, it can invoke the new server/discover method on demand.
Why it matters
Every request becomes self-contained, reducing connection management overhead and making interactions simpler and more resilient.
2. Protocol-level sessions are gone
Layman's lens
Example: Package shipment: Let’s take shipping packages across the country as an example. Previously, every package had to be handled by the same delivery driver from pickup to delivery because that driver remembered everything about the shipment.
If the driver was unavailable, the package could not easily continue its journey.
Now assume every package carries a complete shipping label with the destination, contents, and delivery instructions.
Any available driver can pick it up and continue the delivery without missing a beat.
That is the difference between a stateful and stateless protocol.
Technical lens
Earlier versions of MCP relied on the Mcp-Session-Id header to maintain protocol-level sessions. Once established, requests were tied to the server instance that created the session.
The Release Candidate removes protocol-level sessions entirely.
Every request now carries the information required for processing, allowing any healthy server instance to service the request.
Why it matters
Load balancing, autoscaling, and failover become significantly simpler because requests are no longer bound to individual servers.
3. State did not disappear. It became explicit.
Layman's lens
Example: Online shopping: Suppose you are shopping online. The website doesn’t remember your browser connection forever. Instead, when you add an item to your cart, you receive a shopping cart associated with your account or a cart identifier.
Every future action references that cart.
The shopping experience remains continuous even though each request is independent.
Technical lens
Removing protocol-level sessions doesn’t eliminate application state. Instead, state moves from the protocol layer into the application layer.
A server that needs to preserve context simply returns an identifier such as a basket_id, browser_id, or workflow_id. Future requests include that identifier so processing can continue where it left off.
This follows the same architectural pattern used by REST APIs for years.
Why it matters
State becomes explicit, easier to reason about, easier to debug, and independent of transport-level implementation.
4. Interactive workflows were redesigned
Layman's lens
Example: Mortgage application: Suppose you submit a mortgage application online. Halfway through processing, the bank asks you to upload proof of income.
Instead of restarting the application, the bank pauses your submission, waits for the document, and then continues processing exactly where it stopped.
That is essentially how interactive MCP workflows now operate.
Technical lens
Even in a stateless protocol, servers occasionally need additional information before completing a request.
Rather than maintaining a long-lived Server-Sent Events (SSE) connection, the server now returns an InputRequiredResult together with an encoded requestState.
After collecting the required input, the client resubmits the original request along with the returned state.
Because all necessary context travels with the request, any server instance can resume processing.
Why it matters
Interactive workflows remain possible without relying on persistent connections, improving resiliency and scalability.
5. Operations become simpler
Layman's lens
Example: Airport luggage traffic: Let’s think of managing the traffic in a busy airport. If every suitcase looked identical, security personnel would need to open each one to determine where it belongs.
Now imagine every suitcase clearly displays its destination, airline, priority status, and tracking information on the outside.
Routing becomes dramatically faster and easier. The same principle applies to network traffic.
Technical lens
The Release Candidate introduces several operational improvements. Requests now include Mcp-Method and Mcp-Name headers, allowing gateways and load balancers to route traffic without inspecting request bodies.
Responses can include ttlMs and cacheScope, enabling standardized caching behavior similar to HTTP Cache-Control.
The specification also formally adopts the W3C Trace Context standard, allowing trace information to propagate through MCP using traceparent, tracestate, and baggage. This enables complete end-to-end observability through platforms such as OpenTelemetry.
Why it matters
Requests become easier to route, responses become easier to cache, and distributed AI systems become significantly easier to monitor and troubleshoot.
At a glance: From Stateful to Stateless MCP
The July 28 Release Candidate introduces several protocol-level changes that collectively transform MCP from a stateful protocol into one that aligns more naturally with modern cloud-native architectures. While each change delivers its own benefits, together they simplify deployment, improve scalability, and make MCP easier to operate in production.
Feature | Legacy MCP (Pre-July 2026) | Stateless MCP (Release Candidate) |
Connection | Required initialize handshake | Self-contained client information in the _meta field |
Sessions | Protocol-level Mcp-Session-Id | No protocol sessions; any server can process any request |
State | Implicit and tied to the transport layer | Explicit application-managed identifiers (basket_id, browser_id, workflow_id, etc.) |
Scaling | Sticky sessions and complex request routing | True horizontal scaling with simpler load balancing |
Interactive Workflows | Dependent on long-lived Server-Sent Events (SSE) connections | Pausable and resumable workflows using requestState |
Collectively, these changes simplify the protocol while making it significantly easier to deploy, scale, and operate MCP in modern distributed environments. The architectural benefits become even more apparent when AI applications begin interacting with enterprise systems, where reliability, scalability, and operational resilience are just as important as model intelligence.
Stateless doesn’t mean memoryless
One of the most common misconceptions is that stateless systems cannot remember anything. That is not the case. Let’s understand this with an example:
Imagine logging into your online banking application.
Every request to view your account balance doesn’t rely on the server remembering your previous network connection.
Instead, your authentication token identifies you, allowing the application to retrieve your accounts, balances, and transaction history.
Similarly, AI applications can still maintain:
Conversation history
User preferences
Authentication
Long-running workflows
Business context
The difference lies in where that information is managed.
Instead of hiding state inside the protocol itself, applications manage state explicitly while the transport layer remains stateless.
This separation creates cleaner architecture, simpler infrastructure, and greater operational flexibility.
Why this matters for Enterprise AI
Now envision an enterprise AI assistant helping a sales representative prepare for an important customer meeting.
The representative asks a simple question:
"Tell me everything I should know about Acme Corp before today's meeting."
To answer that single request, the AI assistant may need to retrieve:
Open opportunities from Salesforce
Customer support cases from Jira or Zendesk
Product usage from a data warehouse
Billing information from an ERP system
Contracts from SharePoint
Recent meeting notes from Microsoft Teams
Although this appears to be a single conversation, it may involve dozens of independent MCP requests behind the scenes.
With a stateless architecture, each of those requests can be processed by any available MCP server rather than depending on a single long-lived session.
As organizations deploy hundreds or even thousands of AI agents across sales, customer support, engineering, finance, and operations, this architectural flexibility becomes increasingly important.
Why this matters for enterprise data connectivity
Enterprise AI is only as valuable as the data it can access.
An AI assistant rarely answers questions using model knowledge alone. Instead, it retrieves live business information from multiple enterprise systems, combines those results, and generates meaningful insights.
This is where the enterprise data connectivity and having a data plane become critical.
Every interaction with a CRM, ERP, support platform, data warehouse, or business application generates requests that must be processed efficiently and reliably.
Stateless architecture makes those requests easier to distribute across multiple servers, resulting in:
For organizations building AI applications that depend on real-time enterprise data, these architectural improvements directly translate into more reliable and resilient systems.
Why this aligns with modern cloud architecture
The move toward stateless communication is not unique to AI.
Modern cloud platforms, including Kubernetes, serverless platforms, API gateways, and autoscaling infrastructure, are all designed around stateless services because they are easier to deploy, monitor, recover, and scale.
By adopting the same architectural model, MCP enables AI infrastructure to integrate naturally with existing cloud-native practices instead of requiring specialized deployment models.
For enterprise engineering teams, this means leveraging proven operational patterns that have already demonstrated success at internet scale.
Looking ahead
The July 28 MCP Release Candidate introduces many important capabilities, but the move to stateless architecture may prove to be its most significant long-term change.
Features such as MCP Apps and Tasks expand what developers can build. Stateless architecture determines how reliably those applications can scale, recover from failures, and integrate into modern cloud infrastructure.
As organizations deploy increasing numbers of AI agents that interact with enterprise applications and data platforms, architecture becomes just as important as model capability.
The intelligence comes from the model. The ability to operate that intelligence at enterprise scale comes from the platform.
References
Your enterprise data, finally AI-ready
Connect AI gives your AI assistants and agents live, governed access to hundreds of enterprise systems — so they can reason over your actual business data, not just what they were trained on
