# MCP Goes Stateless

John Dellenbaugh, Early-stage AI startup & Pankaj Kumar, Amazon | MCP Release Party 2026 | 22:41

Source: https://www.youtube.com/watch?v=banffxk7EqQ
Channel: MLOps Community, now AAIF Live (https://www.youtube.com/@AAIFLive-x1r). Summarised by MLOps Talks.
Page: https://mlopstalks.com/talks/mcp-goes-stateless
Published: 2026-08-17
Tags: deployment, mcp

## TL;DR
- The 2026-07-28 MCP specification removes protocol-level sessions and the handshake that previously made horizontal scaling harder.
- Stateful MCP deployments need sticky routing and a separate session store, which adds infrastructure and creates failure points when servers restart.
- A stateless design puts the cart identifier with the cart data in the database, allowing requests to move between MCP instances behind a regular load balancer.

## Summary
John Dellenbaugh and Pankaj Kumar explain why the 2026-07-28 MCP specification changes horizontal scaling. Their shopping-cart demo first shows the old design, where an MCP server keeps session data in local memory. When a load balancer sends later requests to another instance, the server returns "session not found". Sticky routing fixes request placement, while a session store preserves data after an instance restarts, but both add infrastructure that the application must operate. The stateless design removes this dependency. Each cart receives an identifier that is stored with the cart data, and every later tool call sends that identifier. Requests can then reach different MCP instances through a standard round-robin load balancer. The demo distributes carts across modern instances and runs 60 concurrent carts. Dellenbaugh also explains that statelessness does not provide security or application durability automatically. Those concerns still need normal engineering practices.

## Key ideas
### The old MCP scaling problem came from session state in one server
[00:00](https://www.youtube.com/watch?v=banffxk7EqQ&t=0s)
John Dellenbaugh opens with a system design interview where he proposed putting multiple MCP servers behind a load balancer. He missed the need for a sticky store and session tracking. In the demo, an agent creates a shopping cart through Legacy A, which keeps the session in local memory. A later add-item request reaches Legacy B, which has no record of that session and returns "session not found." The design works while requests stay on one instance, then fails after horizontal scaling.

### The shopping assistant makes the failure easy to see
[01:45](https://www.youtube.com/watch?v=banffxk7EqQ&t=105s)
Pankaj Kumar models an AI shopping assistant that creates a cart, adds products, and reads the cart through MCP tools. The demo uses two MCP server instances and a Postgres database containing cart data. Under the old protocol, the cart operation is spread across several calls, and the session connects those calls to the server that first handled them. When the load balancer sends a call to another instance, that instance cannot identify the cart through its local session memory.

### Sticky routing and a session store repair the stateful design
[06:24](https://www.youtube.com/watch?v=banffxk7EqQ&t=384s)
The stateful workaround has two parts. A sticky gateway keeps a map from session IDs to server instances, so later calls return to the instance that created the session. A separate session store keeps the session data outside that server's memory. The demo shows the calls working after sticky routing is added. When the server holding the session is killed, the session store allows the data to be recovered after the server returns. Kumar points out that this infrastructure is extra operational work.

### Stateless MCP moves the identifier into application data
[09:55](https://www.youtube.com/watch?v=banffxk7EqQ&t=595s)
Dellenbaugh describes the stateless version as removing the infrastructure tax of the sticky gateway and session store. The modern systems sit behind a regular round-robin load balancer. One instance creates the cart and another handles a later item request. The cart ID is stored with the cart in the database, and each subsequent MCP request carries that ID. The MCP servers therefore do not need to retain the session themselves.

### The demo distributes concurrent carts across instances
[12:06](https://www.youtube.com/watch?v=banffxk7EqQ&t=726s)
The scale test starts 60 concurrent carts, each with one item. Dellenbaugh shows the requests being divided between systems, with one run sending 46 carts to the first system and another run producing a different distribution. The backend contains separate carts with their items. The point of the test is that requests can be assigned to different instances when the cart identity and data live outside the MCP server.

### Statelessness does not solve security or durability
[13:45](https://www.youtube.com/watch?v=banffxk7EqQ&t=825s)
Dellenbaugh directly rejects the idea that statelessness supplies security. The application still has to handle security, including concerns such as session stealing and prompt engineering. He also says MCP does not automatically provide ACID behavior, durability, or resiliency. Engineers should apply the same durability and resiliency practices used for other applications behind a load balancer.

### The implementation can use ordinary cloud infrastructure
[11:00](https://www.youtube.com/watch?v=banffxk7EqQ&t=660s)
The demo runs in Google Cloud using Cloud Run and Supabase for the database. Dellenbaugh says the same pattern could run with Lambda or Azure Functions. The choice of Supabase was based on its low cost for the demo. He provides the code in the GitHub repository John Del 914, including instructions for running it locally or rebuilding it in GCP.

## Notable quotes
- John Dellenbaugh: "We showed the model working in a, you know, we're basically paying the tax. We're paying the tax with infrastructure." (09:55)
- John Dellenbaugh: "So, when we go to go stateless, you'll see we have a standard load balancer and we have the ability to scale without issue." (10:20)
- John Dellenbaugh: "The answer is no. You have to handle security." (13:45)
- John Dellenbaugh: "The MCP spec by nature won't solve all of those things for you." (16:50)

## Tools & references mentioned
- Model Context Protocol
- MCP
- Shopify
- Storefront MCP server
- Postgres
- Google Cloud
- GCP
- Cloud Run
- Supabase
- Lambda
- Azure Functions
- GitHub

## Who should watch
- You are designing an MCP service that must run behind a load balancer and want to understand why protocol-level sessions complicate horizontal scaling.
- Your current MCP deployment uses sticky routing or a session store, and you want to compare that setup with the stateless design in the 2026-07-28 specification.
- You need a practical demo that separates MCP scaling from application concerns such as security, durability, and resiliency.

## Related talks

- [MCP Release Overview: Stateless and the Big Changes in the New Spec](https://mlopstalks.com/talks/mcp-release-overview-stateless-and-the-big-changes-in-the-new-spec) (Alex Hancock, Block, 17:48)
- [MCP 2.0: What Changes, What Breaks, and What You Need to Do About It](https://mlopstalks.com/talks/mcp-2-0-what-changes-what-breaks-and-what-you-need-to-do-about-it) (Mateo Torres, Arcade.dev, 21:47)
- [Yes, we do need MCP](https://mlopstalks.com/talks/yes-we-do-need-mcp) (Ben Hindman, reboot.dev, 26:32)
- [Stateless, Yet Durable: MCP Tasks v2](https://mlopstalks.com/talks/stateless-yet-durable-mcp-tasks-v2) (Cornelia Davis, Temporal, 26:23)
- [MCP Security: What Happens When Your Agents Talk to Everything?](https://mlopstalks.com/talks/mcp-security-what-happens-when-your-agents-talk-to-everything) (, 24:26)