MCP Goes Stateless: What the 2026 Spec Means for SMEs

On 28 July 2026, the Model Context Protocol (MCP) — the open standard that connects AI agents to business software — gets its largest revision since launch. The 2026-07-28 specification makes the protocol stateless: agent integrations that previously needed sticky sessions, a shared session store and specialist infrastructure will now run on ordinary HTTP hosting behind a plain load balancer. For small and mid-sized companies, this is the moment MCP stops being early-adopter technology and starts becoming boring infrastructure — which is exactly when it becomes safe to build on.

The release candidate was locked on 21 May 2026, giving SDK maintainers a ten-week validation window before the final specification ships. Most coverage of the release is written for protocol engineers: what breaks in your server code. This post covers the other half — what the change means if you run a Dutch or Belgian SME that is buying or building AI agent integrations this year.

What MCP is, and why this release matters

MCP was open-sourced by Anthropic in November 2024 to solve the N×M integration problem: N AI applications times M business tools used to mean N×M custom connectors. With MCP, you build one server for a tool and every compatible AI client can use it. Since then it has been adopted by OpenAI, Google and Microsoft, with native support in Claude, ChatGPT, Gemini, Copilot and Cursor; the Python and TypeScript SDKs alone see roughly 97 million downloads per month. In December 2025 Anthropic donated the protocol to the Agentic AI Foundation under the Linux Foundation, making it a vendor-neutral standard.

For a business, the practical point is this: if you expose your ERP, CRM or planning package through one MCP server, every AI assistant your team uses can work with it — today and after your next vendor switch. That is why a spec revision matters outside developer circles: MCP is becoming the standard socket that AI agents plug into, and the socket is changing shape.

What actually changes on 28 July

The headline change is that MCP becomes stateless at the protocol layer. The initialize handshake and the Mcp-Session-Id header — which pinned every client to one specific server instance — are removed. Each request is now self-contained: protocol version, client info and capabilities travel in a _meta field on the request itself, and a new server/discover method lets clients fetch server capabilities on demand.

Three supporting changes make the traffic easier to operate. Required Mcp-Method and Mcp-Name headers let load balancers and gateways route and rate-limit requests without inspecting the body. List and read results now carry ttlMs and cacheScope fields modelled on HTTP Cache-Control, so clients know how long a tool list stays fresh. And W3C Trace Context propagation is now pinned down in the spec, so a tool call can show up as a single trace across client, server and downstream systems in any OpenTelemetry-compatible backend.

The maintainers describe the practical effect directly: a remote MCP server that previously needed sticky sessions, a shared session store and deep packet inspection at the gateway can now run behind a plain round-robin load balancer. In infrastructure terms, an MCP server used to be a stateful application — the kind that needs session affinity and a Redis store to scale. From 28 July it is a stateless web service, deployable on any commodity container platform or serverless runtime. Anyone who can host a standard web API can host an MCP server.

One nuance matters: a stateless protocol does not force your application to be stateless. Servers that carry state across steps — a shopping basket, an open work order — mint an explicit handle and let the model pass it back on later calls, the way HTTP APIs have always done it. The state becomes visible to the model instead of hidden in transport metadata, which in practice makes multi-step workflows easier to debug, not harder.

Tasks and MCP Apps: two extensions that map to real work

The release also makes extensions first-class, with their own repositories, versioning and a formal path from experimental to official. Two official extensions ship with it, and both matter for business workflows more than for chatbots.

The Tasks extension gives agents a call-now, fetch-later pattern: a server can answer a tool call with a task handle, and the client polls or checks back while the real work runs in the background. Real back-office work is measured in minutes, not milliseconds — matching a month of invoices, generating a management report, syncing a product catalogue. Tasks is how an agent kicks off that kind of job without blocking. Note for early adopters: Tasks shipped experimentally in the 2025-11-25 spec, and production feedback forced a redesign — anything built against the experimental API must migrate to the new lifecycle.

MCP Apps lets a server ship interactive interfaces that render inside the chat window, in a sandboxed iframe, with templates declared up front so the host can review them before anything runs. It was co-developed with OpenAI and launched with partners including Asana, Box, Canva, Figma, Slack and Salesforce. For an SME the interesting version is internal: a planning dashboard or approval form that renders inside the assistant your staff already use, instead of yet another browser tab.

What breaks, and the new deprecation rules

This is a breaking release, and the maintainers say so openly. Besides the Tasks migration, the error code for a missing resource changes from the custom -32002 to the JSON-RPC standard -32602; tool schemas are lifted to full JSON Schema 2020-12 (composition and references are now allowed); and the authorization rules are hardened to match how OAuth 2.0 and OpenID Connect are actually deployed, including required validation of the iss parameter to block a class of mix-up attack. The full list is in the changelog.

Three familiar core features — Roots, Sampling and Logging — are deprecated, with replacements pointing to tool parameters, direct LLM provider APIs and OpenTelemetry respectively. But the more important news is the policy around them: every feature now has a formal lifecycle with at least twelve months between deprecation and the earliest possible removal, new capabilities ship as opt-in extensions first, and no proposal reaches final status without a matching scenario in the conformance test suite. Translated: 2026-07-28 is designed to be the last clean break. That is a maturity signal procurement teams should read as: the ground has stopped moving.

What this means for a Dutch SME buying or building agents

Here is the part the developer coverage skips. Whether the July revision is good news for you depends on which of three positions you are in.

If you are buying agent-enabled software

Your software vendors — ERP, CRM, planning, accounting — are increasingly shipping MCP servers as their AI integration layer. Before you commit to anything this summer, ask three questions. Which MCP spec version does the integration target, and when will it support 2026-07-28? Is it built on a Tier 1 SDK (the official SDKs expected to support the new spec within the ten-week window)? And if the vendor built on the experimental 2025 Tasks API, what is their migration plan? A vendor without answers is not disqualified — but a vendor who has answers is telling you something about their engineering discipline.

If you are building your own integration

The economics just improved. Until now, running a production MCP server for your own systems meant stateful hosting: session affinity at the load balancer, a shared session store, and long-lived connections that many serverless platforms handle badly. Under the new spec the same server is a stateless service — cheaper to host, trivial to scale horizontally, and observable with the OpenTelemetry tooling your IT partner already knows. If you are scoping an agent development project for the second half of 2026, target the 2026-07-28 spec from day one and you skip the migration entirely. The same logic applies to production AI implementations that expose internal data to an assistant: build against the release candidate now, ship against the final spec.

If you already shipped an MCP integration in 2025

Nothing stops working on 29 July. Existing spec versions keep functioning, and the deprecated features carry a minimum twelve-month window. But plan the migration this quarter rather than next year: the ten-week release-candidate window exists precisely so implementers can validate against real workloads before the spec is final, and the stateless rework touches transport code that is cheaper to change deliberately than under pressure. If your integration leans on Sampling or protocol-level Logging, schedule the move to provider APIs and OpenTelemetry now.

Our take

The stateless rework is the least glamorous kind of protocol news, and that is exactly its significance. Technologies become adoptable for SMEs when they stop being interesting — when hosting is commodity, versioning is predictable and breaking changes come with policies instead of surprises. MCP now has all three. What it still lacks, per its own 2026 roadmap, is the enterprise layer: standardized audit trails, gateway patterns and configuration portability are open work items. So keep expectations calibrated — the protocol will move your data reliably, but access governance, logging for compliance and human approval steps remain your responsibility to design. That division of labour is normal; pretending the protocol solves it is the mistake we see most often in vendor decks.

If you are planning an agent pilot for the autumn, the sequencing writes itself: scope small, target the new spec, and put the governance questions on the table in week one — our note on how to run an AI pilot covers that structure, and for the model-side choices our LLM optimisation service page explains where the protocol ends and the model work begins.

Frequently asked questions