Model Context Protocol has been one of the fastest-adopted developer standards in recent memory — 97 million monthly SDK downloads, 10,000+ servers, adopted by every major AI lab within months of launch. The version that drove all of that adoption, though, had some significant limitations for production deployments. The July 28, 2026 specification release candidate changes that.
This is the largest revision to MCP since Anthropic published the original spec. It's not a cosmetic update — it touches the protocol's core architecture, adds two major extensions, hardens authorisation, and introduces a formal deprecation policy. If you're building with MCP or planning to, here's what you need to know.
The Headline Change: MCP Goes Stateless
The original MCP spec required servers to maintain session state. In practice, that meant running a remote MCP server required sticky sessions — routing every request from a given client to the same server instance — a shared session store so instances could hand off context, and deep packet inspection at the gateway to route correctly. That's a significant infrastructure overhead for something that's supposed to be a lightweight connectivity layer.
The 2026-07-28 spec makes MCP stateless at the protocol layer. Any server instance can now handle any request. You can run MCP servers behind a standard load balancer, on serverless infrastructure, or in containers that scale up and down without the session-stickiness constraint. The protocol no longer requires specialised gateway configuration.
What stateless means in practice
Before: MCP server deployment required sticky sessions, shared session stores, and deep packet inspection at the gateway. After: Any server instance handles any request. Deploy on ordinary HTTP infrastructure — load balancers, serverless functions, standard containers — without specialised routing.
This is the change that makes MCP viable for the kind of high-availability, auto-scaling production deployments that enterprise customers require. It's also what makes the Tasks extension possible.
New: The Tasks Extension
One of the awkward gaps in the original MCP spec was long-running operations. If a tool call took thirty seconds — or five minutes — the client had to hold the connection open and wait. That's fine for demos, not fine for production systems where network reliability matters and timeouts are real.
The Tasks extension solves this by decoupling initiation from completion. A server can now respond to a tools/call with a task handle rather than an immediate result. The client then drives the lifecycle with three new methods: tasks/get to check status, tasks/update to pass new inputs to a running task, and tasks/cancel to terminate it early.
For developers building agentic workflows that involve slow operations — code execution, file processing, external API calls, multi-step reasoning — this is a significant improvement. Tasks can run on the server side without the client maintaining an open connection, and the client can poll at whatever interval makes sense for the use case.
New: MCP Apps
MCP Apps is the most visually striking addition. It lets servers ship interactive HTML user interfaces that host applications render in a sandboxed iframe. The rendered UI communicates back to the host over the same JSON-RPC protocol used everywhere else in MCP — which means every UI-initiated action goes through the same audit and consent path as a direct tool call.
Tools declare their UI templates ahead of time so hosts can prefetch and cache them. The result is that a complex MCP server — say, a database tool with a query builder UI — can ship its own interface rather than relying on the host application to render it generically.
This matters for the developer experience of building MCP-connected products. Instead of every MCP tool looking like a raw JSON input/output panel in whatever host it's connected to, servers can now ship purpose-built interfaces that match their actual use case. The consistency guarantee comes from the protocol: the UI sandbox can't do anything the tool itself couldn't do through a direct call.
Authorisation: Now Actually Enterprise-Ready
The original MCP authorisation model was functional but not aligned with how enterprises actually manage identity. The 2026-07-28 spec reworks authorisation to align with OAuth 2.1 and OpenID Connect in ways that make it meaningfully compatible with existing enterprise identity infrastructure.
The Enterprise-Managed Authorisation extension is now stable. Organisations can centrally manage authorisation for MCP servers — users access all connected servers through a single login, with permissions managed centrally rather than server by server. For enterprises deploying MCP at scale across multiple internal tools, this removes a significant administrative overhead.
The security improvement is real too. The new spec adds Mcp-Method and Mcp-Name headers to the Streamable HTTP transport so load balancers, gateways, and rate-limiters can route and restrict on the operation without inspecting the body. That's a meaningful change for security teams who need to enforce per-tool access controls without deep packet inspection.
What Breaks: The One Change to Watch
The 2026-07-28 spec contains one notable breaking change. The error code for a missing resource changes from the MCP-custom -32002 to the JSON-RPC standard -32602 Invalid Params. If your client code matches on the literal -32002 value to detect missing resource errors, it will stop working correctly after the spec ships.
Check your error handling code before July 28. If you're catching -32002 specifically, update it to -32602. If you're using an official MCP SDK, check whether the SDK version you're on handles this automatically — the SDK maintainers will likely ship updates ahead of the spec finalisation.
- Error code -32002 (missing resource) → -32602 (Invalid Params) — update any client code that matches on this literal
- Session-based server infrastructure may need redesign for the stateless core — the migration path is documented in the release candidate
- The formal deprecation policy means 12 months minimum between deprecation and removal — check the spec for what's been marked deprecated in this release
The Bigger Picture
The 2026-07-28 spec is MCP growing from a clever idea into production infrastructure. Statelessness means it can run anywhere. Tasks means it can handle real workloads. MCP Apps means it can ship real interfaces. OAuth 2.1 alignment means enterprises can actually deploy it. The formal deprecation policy means teams can build on it with confidence that the ground won't shift unexpectedly.
If you've been evaluating MCP but holding off because of the production deployment complexity, the July 28 release is worth revisiting. The spec that made 97 million monthly downloads happen was already compelling. The spec that ships on July 28 is considerably more so.