MCP Just Went Stateless — What the July 28 Protocol Spec Means for Every No-Code Platform

On Monday, the Model Context Protocol ships its largest revision since launch. The spec mark is 2026-07-28, and if you build anything that connects AI agents to tools, data, or services, this one demands your attention. Not because it adds flashy features. Because it removes things. And what it removes is the stuff that made MCP servers a pain to deploy at scale.

The protocol is now stateless at the core. No handshakes. No session IDs. No sticky routing. Any request can land on any server instance and just work.

Combined with MCP Apps (server-rendered UIs that render inside agent conversations), a formal Tasks extension for long-running work, and OAuth 2.1-hardened authorisation, the 2026-07-28 spec changes what no-code platforms can build, embed, and charge for. If your platform doesn't speak MCP, you're about to feel it.

What actually changed under the hood?

The old MCP, the 2025-11-25 spec, was stateful. A client had to send an `initialize` request first. The server would respond with an `Mcp-Session-Id` header, and every subsequent request had to carry that header. It pinned you to whichever instance first answered your call.

If you wanted to run more than one MCP server behind a load balancer, you needed sticky sessions. Or a shared session store. Or both. And your gateway had to do deep packet inspection to route requests to the right instance. Fine for a developer laptop. A headache at platform scale.

The new spec deletes two things, via SEP-2575 and SEP-2567:

* The `initialize`/`initialized` handshake is gone. Protocol version, client identity, and capabilities now ride in `_meta` on every request. A new `server/discover` method lets clients fetch server capabilities when they actually want them.

* The `Mcp-Session-Id` header is gone. No protocol-level session at all.

The effect on deployment is immediate. An MCP server can now sit behind a plain round-robin load balancer. Route on the `Mcp-Method` and `Mcp-Name` headers (SEP-2243). Let clients cache `tools/list` responses for however long the server's `ttlMs` permits. The infrastructure story goes from bespoke to commodity HTTP.

For no-code platforms, this is the bit that matters. When you're embedding MCP tool access into a visual builder, you don't want to be thinking about session affinity. You want a request to come in, hit any instance, and resolve. Now it does.

So where did the state go?

Into the conversation itself. Pay attention to this one.

If a server needs state across calls, say tracking a multi-step workflow, it mints an explicit handle: a `basket_id`, a `browser_id`, a `workflow_id`. Returns it in the tool result. The AI model then passes that handle back as an ordinary argument on subsequent calls.

The model sees the handle. Reasons about it. Can hand it between tools, compose it, include it in planning. As the spec maintainers note, that's often more powerful than hidden session state. But it also means the handle lives in the chat transcript. If that transcript ends up in Slack, a Jira ticket, or a shared log, the handle goes with it.

Backslash Security called this out directly: state didn't disappear. It moved. And whoever has the string can now gain access.

I think the trade-off is right for the ecosystem. Stateless architecture at the protocol layer is the correct call for something with 97 million monthly SDK downloads and 10,000-plus public servers. But no-code platform builders need to understand that handle hygiene just became your problem, not the protocol's.

What are MCP Apps, and why should no-code builders care?

MCP Apps, formalised as an extension via SEP-1865, let servers return interactive HTML UIs that render inside sandboxed iframes directly in the agent conversation. Dashboards, configuration forms, approval dialogs, visualisations. Not text output. Not a separate browser tab. An interactive widget right where the agent and user are already working.

A tool declares a `_meta.ui.resourceUri` pointing to a `ui://` resource. The host fetches it, renders it in a sandboxed iframe, and enables bidirectional JSON-RPC communication over `postMessage`. Users click buttons, fill forms, filter charts. The model sees what they do and responds.

For no-code platforms, the embedding angle is what matters. If you're building a visual app builder and your users want AI agents that can surface interactive components: charts, wizards, approval flows, MCP Apps gives you a standards-based way to do it. No custom widget SDK. No proprietary iframe protocol. Just a resource URI and an iframe. ChatGPT, Claude, VS Code, and Goose already ship support. More clients are coming.

The flip side: that sandboxed iframe is rendering inside an IDE or a chat client, not a browser tab with decades of origin hardening. A compromise in one context is far costlier in the other. If your platform lets users connect arbitrary MCP servers, you need a position on iframe sandboxing. The spec won't provide one.

Is the new spec more secure or less?

Both. Depends where you look.

On authorisation: better, and by a margin. The spec aligns with OAuth 2.1 and OpenID Connect properly. Client ID Metadata Documents (CIMD) replace Dynamic Client Registration. Issuer verification is now required, blocking a class of mix-up attacks where one client talks to many MCP servers. Refresh token handling is formalised. If you're running an enterprise MCP deployment behind an identity provider, the auth story is cleaner than it's ever been.

On filesystem scope: worse. The Roots capability, which let platforms enforce which filesystem paths an AI agent could touch, is deprecated. With no session, there's no natural enforcement point for filesystem boundaries. Scope enforcement becomes opt-in, applied inconsistently by individual server developers. Your gateway can't tell whether a server respects boundaries or not.

We already know what happens when scope is only enforced by convention. An agent tasked with generating a usage report accessed 340 files before completing the task, including credential stores and `.env` files with database passwords and Stripe API keys. It wasn't breached. It was used exactly as intended. The scope was just never structural.

On handle security: new territory. Session hijacking becomes handle hijacking. A malicious tool response can feed the model an attacker-controlled ID, and the model will obediently pass it along. Replay risk goes up because handles are valid anywhere until the resource expires, not tied to a server-side session you can revoke. And the `_meta` blobs that servers echo back for multi-step operations can be tampered with before they return: change the transaction amount, change the recipient. If the server trusts the echo without verification, you've been had.

What about Tasks?

Tasks graduated from an experimental core feature to a formal extension. The old blocking `tasks/result` pattern is replaced by polling via `tasks/get`. Servers can return task handles unsolicited. Long-running work (builds, deployments, batch processing, multi-minute agent runs) now has a proper home in the protocol.

For no-code platforms that trigger AI workflows, this is meaningful. Instead of hoping a tool call finishes before the HTTP timeout, your platform fires off a task, polls for completion, and surfaces progress in your UI. The stateless architecture means any polling request can hit any instance. No need to track which server has which task in flight.

Platforms that skip MCP are missing more now

The 97 million monthly SDK downloads isn't vanity. It reflects a protocol that has become the de facto standard for connecting AI applications to tools, data, and services. ChatGPT, Claude, Cursor, Gemini, Copilot, and VS Code all ship first-class MCP support. When MCP Apps renders interactive widgets inside those surfaces, users will expect to see them.

A no-code platform that doesn't speak MCP in mid-2026 is in roughly the same position as one that didn't speak REST in 2010. You can build a walled garden. Your users will find the door.

The stateless shift makes integration simpler than it's ever been. No handshake dance. No session tracking. A single self-contained POST request. If your platform can make HTTP calls and render an iframe, you can ship MCP support. The question isn't whether you should. It's what your competitors will build with it while you're deciding.

And if you're building something that looks like a governed agent platform, which is where the smart money in no-code is heading, the new auth hardening means you can actually do MCP with proper identity propagation, per-request policy enforcement, and audit trails that survive a server restart. That wasn't true before Monday.