If you have an AI assistant that can look things up in your systems or take actions in them, there is a good chance the plumbing between the assistant and your systems is the Model Context Protocol. MCP is the open standard that lets a model call a tool: search the orders database, create a ticket, fetch a document. We build a lot of those servers under AI Automation, and we run them on AWS Lambda and Cloudflare Workers because that is where our clients' backends already live.
Last Tuesday the protocol shipped its largest revision since it launched. The 2026-07-28 spec makes MCP stateless. That sounds like a detail. For anyone running these servers on serverless infrastructure it is the change we have been waiting for.
What Was Wrong Before
The old protocol was built like a phone call. A client connected, the two sides exchanged an initialize handshake, the server issued a session ID, and every later request had to carry that ID back to the same server that issued it. Some features, like a server asking the user a clarifying question mid-tool, needed a stream held open in the other direction.
On a long-running server that is fine. On Lambda it is a nuisance. Serverless functions do not remember the last request, so every MCP server we shipped needed somewhere to keep session state, usually a DynamoDB table, and a way to make sure requests for one session did not land on an instance that had never seen it. Cloudflare Workers were slightly easier and still needed care. Every one of those servers carried a hundred lines of session bookkeeping that had nothing to do with the client's actual tools.
What Changed
The new spec, in the order that matters to us:
- No handshake, no session ID. The initialize exchange is gone and so is the session header. Every request carries the protocol version, the client's identity and its capabilities in a metadata field, so it stands on its own. Any request can land on any server instance behind a plain load balancer with no shared storage.
- Routing headers. Every HTTP request now declares the method and the tool name in headers,
Mcp-MethodandMcp-Name. A gateway can route, meter and log by tool without parsing the body. - Multi round-trip requests. Instead of the server opening a stream to ask the user something, it returns a result that says input is required and lists what it needs. The client retries the original call with the answers attached. Same behaviour, ordinary request and response.
- Cacheable listings. Tool, prompt and resource lists carry a time-to-live and a cache scope, and come back in a stable order so upstream prompt caches stay warm.
- Auth tightening. Authorization servers return an issuer parameter that clients must check, credentials are bound to the server that issued them, and Dynamic Client Registration is deprecated in favour of Client ID Metadata Documents.
- Deprecations with a clock. Roots, sampling, logging and the old HTTP-plus-SSE transport are deprecated with at least a twelve-month window. All of it still works today.
Official SDKs for TypeScript, Python, Go and C# shipped with the spec, with Rust in beta. Simon Willison's summary matched ours: it greatly decreases the complexity of implementing both clients and servers. Cloudflare's line was that agent infrastructure now works like the rest of the web, stateless and cacheable. AWS said the quiet part: MCP servers can now be deployed on standard, scalable infrastructure without managing sessions.
What It Means for the Servers We Build
Less code and fewer moving parts. The session table goes away. The sticky-routing workaround goes away. An MCP server on Lambda becomes what a Lambda function is good at: receive a request, do the work, return. We expect the next server we ship to be noticeably smaller than the last, and the difference is all plumbing that used to need testing.
Cheaper to run. No held-open streams means no long-lived connections on Workers or API Gateway, and no function sitting idle waiting for a client to answer a question. For a client paying per invocation, that is a real line on the bill.
Better observability. With the tool name in a header, API Gateway and Cloudflare can meter usage per tool without us instrumenting the handler. "Which tools does the assistant actually use, and how much do they cost" becomes a dashboard rather than a research project. That feeds directly into Cruise & Maintenance cost tuning.
Clarifying questions that fit serverless. Several of our servers ask for confirmation before doing something irreversible, such as issuing a refund. Under the old protocol that was the hardest feature to run on Lambda. Under the new one it is a normal response and a normal retry, which is exactly how Supabase described using it: tools can confirm with the user before they act.
Cheaper prompts. Cacheable, stable tool listings mean the model's prompt cache stops being invalidated by the order of a list. That is a small saving on every call and a large one across a busy assistant.
The Migration We Are Starting
Twelve months sounds like a long time. It is one Cruise & Maintenance cycle, and most of the work is mechanical. For each MCP server we run for a client, the plan is:
- Upgrade the SDK to the 2026-07-28 release and run the existing tests.
- Delete session state. The table, the middleware, the sticky routing. If a tool genuinely needs to remember something across calls, the spec's answer is to hand the model an explicit handle and take it back as an argument, which is cleaner anyway.
- Replace any server-initiated questions with the multi round-trip pattern.
- Check for sampling, roots or logging and move off them before the window closes. We used sampling in one server. It goes.
- Move auth from Dynamic Client Registration to Client ID Metadata Documents, and add the issuer check.
- Turn on the headers and point the client's metering at them.
The spec is backwards compatible, so this does not need to happen in one weekend. It does need to happen, and new servers start on the new spec from today.
What a Founder Should Take From This
If your product has an assistant that acts on your systems, ask whoever built it two questions: which version of MCP does it speak, and is there a plan for the twelve-month window? The right answers are "the July spec, or a dated plan to get there" and "yes". The wrong answer is a blank look, because the old transport will eventually stop being supported and the servers that rely on it will stop working with new clients.
For our clients, the answer is that the plan is in the maintenance backlog with a date next to it, and the next server they get is simpler, cheaper and easier to watch than the last.
Running an Assistant That Talks to Your Systems?
At Dev Force One, AI Automation means MCP servers on the serverless stack your product already runs on, and the new spec makes them smaller, cheaper and easier to meter.
What we offer:
- New servers on the 2026-07-28 spec from day one, stateless on Lambda or Workers
- A dated migration plan for existing servers inside Cruise & Maintenance, well ahead of the deprecation window
- Per-tool cost visibility through the new routing headers, so you can see what your assistant spends
Have an assistant on the old protocol, or one you want to build? Book a Pre-flight call and we will map the migration.