Let's say you built an MCP server called Slotly — it lets AI agents book meeting rooms on behalf of your users. It's been running fine for a few months. One process, one server, nothing fancy. Then usage picks up, someone on your team says "let's scale this to three instances behind a load balancer," and suddenly Slotly starts throwing errors nobody can explain.
That's roughly the story behind the biggest MCP spec update since the protocol launched. On July 28, 2026, MCP moves to a new version — the release candidate has been locked since May 21 — and it changes exactly the kind of thing that broke Slotly. If you run or build on an MCP server, here's what's different, told through what it would actually mean for something like Slotly — not just the changelog version.
Every version of MCP up to now works like this: when a client connects, the server hands back a session ID, kind of like a coat-check ticket. Every request after that has to come back to the exact same server that issued the ticket — because that's the only place the ticket means anything.
That's fine with one process. It falls apart the moment you add more than one. Say Slotly runs on three servers behind a load balancer. Instance A hands out the session ticket. But the very next request from that same client gets routed to Instance B — which has never seen that ticket before and has no idea what to do with it. To the person using Slotly, it looks like the booking flow just randomly failed. To your team, it looks like a network bug that takes a full afternoon to trace back to "oh, it's the session thing again."
Most teams solve this today with sticky routing (always send the same client back to the same instance) or a shared session store (every instance can look up every ticket). Both work. Both are also extra infrastructure you built purely to work around a limitation in the protocol.
The new spec removes sessions altogether. There's no handshake, no ticket. Every request now carries everything a server needs to understand it — protocol version, client identity, capabilities — bundled into the request itself, in a field called _meta. Clients also send two new headers, Mcp-Method and Mcp-Name, on every call.
Back to Slotly: with this change, any of your three server instances can answer any request, because nothing is pinned to a specific one anymore. You can point a plain round-robin load balancer at it — the simplest, cheapest option — and the "instance B doesn't recognize this ticket" bug just can't happen, because there's no ticket to not recognize.
If you're running an MCP server behind more than one instance today, this is the one change worth reading the spec for. Everything else in this update matters, but this is the one that removes real infrastructure you've probably already built to work around the old model. If you want more background on what MCP servers are and how they're structured, our beginner's guide to MCP servers is a good starting point.
Good question — because Slotly still needs to remember things. If an agent is halfway through booking a room, picking a time, and choosing catering, something has to hold onto all of that between steps.
The answer: tools now return an explicit handle. Instead of the protocol quietly tracking "this session is mid-booking" for you, Slotly's tool returns something like a booking_id, and the agent passes that ID back on every subsequent call. Slotly stores the actual booking details whichever way it wants — Postgres, Redis, doesn't matter — and the booking_id is just a pointer to it.
This is a real improvement, because the agent can now see and reason about what it's holding onto, instead of state being invisible protocol plumbing. But it also puts a responsibility on you that used to be handled for you: is that booking_id tied to the person who created it, and does it expire? A booking handle that works forever, for anyone who happens to have the string, is a permanent access token wearing a different name. We've written before about exactly this failure pattern — a credential that outlives the moment it should've stopped working — in our breakdown of the Vercel breach.
Say Slotly wants to show an actual visual calendar picker instead of the agent describing available time slots in a paragraph of text. Under the new spec, a tool can declare that UI ahead of time, and the client renders it as an interactive HTML interface inside a sandboxed iframe — the host gets to prefetch, cache, and review it before anything runs, and every click inside that calendar still goes through the same audit and consent path as a normal tool call.
Useful, and worth treating with the same care as any third-party script running on your own site — it's UI code shipped by someone else, rendered in front of your users. For a broader look at how MCP apps are reshaping SaaS architecture, see our piece on why AI agents are forcing SaaS to become context engines.
If someone uses Slotly to send meeting reminders to 500 people, that's not a one-second operation. The previous spec version added an experimental "Tasks" feature for exactly this — operations that take longer than a normal request-response cycle. Production use showed it needed a redesign, so it's moving out of the core spec and into its own extension.
The mechanics change from "wait for the result" to "check back later": instead of a blocking call, the server hands back a task handle immediately, and the client polls it with tasks/get, sends input with tasks/update, or stops it with tasks/cancel. If you built anything on the old experimental version, budget time to move it over.
A few changes that won't make headlines but will break something if you skip them:
Say Slotly is used by a 200-person company and the security team wants every login validated properly and every client registered safely. Six SEPs tighten exactly this: clients must now validate the iss field on tokens (per RFC 9207) to stop a specific class of mix-up attack, and OpenID Connect apps have to declare their type during registration. If you're running MCP for more than one tenant or organization, this is worth its own audit pass — we go deeper on the OAuth 2.1 foundation these SEPs build on in our MCP authorization guide.
The RFC 9207 requirement is also covered in our dedicated explainer on OAuth 2.0 authorization server issuer identification — useful if you want to understand exactly what the iss validation check is preventing.
Separately — shipped just ahead of this release rather than inside it — a company-wide version of this problem got its own answer: Enterprise-Managed Authorization (EMA), which lets the company's identity provider decide who gets into which MCP servers, without a consent click per person per server. It's substantial enough that we've given it its own explainer.
If Slotly were real, here's what your team would be doing this month:
None of this needs to happen today. The validation window runs right up to the 28th, and Tier 1 SDKs — Python and TypeScript — are expected to have full support ready within it. If Slotly's auth already runs through Scalekit's drop-in OAuth 2.1 layer for MCP servers, a good chunk of the session and auth changes above are already handled — worth a quick check of what's covered automatically versus what still needs your attention. For teams thinking through whether to build or buy this layer, our MCP authentication build vs. buy roadmap lays out the tradeoffs clearly.
For deeper background on the enterprise identity and SSO patterns that underpin MCP auth, Enterprise MCP: How Identity, SSO, and Scoped Auth Actually Work is worth reading alongside this checklist.
The biggest change is the removal of stateful sessions. Every request now carries protocol version, client identity, and capabilities in a _meta field, so any server instance can handle any request. This eliminates the need for sticky routing or shared session stores when running multiple MCP server instances behind a load balancer.
With sessions gone, you no longer need sticky routing or a shared session store. A plain round-robin load balancer works out of the box. Any instance can answer any request, which simplifies horizontal scaling significantly.
Tools now return explicit handles — like a booking_id — that the agent passes back on subsequent calls. The server stores the actual state in whatever backend it chooses (Postgres, Redis, etc.), and the handle is a pointer to it. The key responsibility: handles must be scoped to the right user and must expire, or they become permanent access tokens in disguise.
Tasks has moved out of the core spec into its own extension. The model changes from a blocking call to a polling pattern: the server returns a task handle immediately, and the client uses tasks/get, tasks/update, or tasks/cancel to interact with it. Teams using the old experimental version will need to migrate.
Six SEPs tighten MCP's auth model. Clients must now validate the iss field on tokens per RFC 9207, which prevents a class of mix-up attacks. OpenID Connect apps must also declare their type during registration. If you operate MCP for multiple tenants or organizations, this warrants a dedicated audit pass.
EMA lets a company's identity provider control access to MCP servers centrally, without requiring a per-user, per-server consent click. It was shipped just ahead of the July 28 release as a companion feature and is substantial enough to warrant its own explainer.
Tier 1 SDKs — Python and TypeScript — are expected to have full support ready within the validation window leading up to July 28.
Yes, if you check for error codes by value. "Resource not found" moves from the custom -32002 to the standard JSON-RPC -32602. Search your codebase for the literal string -32002 and update it before the spec goes live.
