MCP 2026-07-28: The Big Architectural Shift

TL;DR: MCP’s biggest update since launch moved the protocol from connection-oriented to stateless and web-native, unlocking production-scale deployment patterns. This is the first in a five-part series exploring how MCP evolved in 2026. Throughout the series, we’ll examine the architectural changes, what they mean for enterprise deployments, and where the protocol is heading next.

Aug, 2026
3 min read

Summarize:

Read

What Happened to the Model Context Protocol?

On July 28, the Model Context Protocol (MCP) released its most significant architectural revision since launch. If you’ve built anything on MCP in the past 18 months, this change matters – and it’s worth understanding why the maintainers made such a breaking revision.

The headline: MCP moved from a connection-oriented, session-based protocol into a stateless, request-response model designed to run on ordinary web infrastructure.

This change fundamentally shifts how MCP operates, scales, and integrates with the enterprise infrastructure most organizations already have in place.

What Actually Changed?

Sessions are gone. The old protocol relied on an initialize/initialized handshake that established a persistent session, tracked by an Mcp-Session-Id header. Every request in that session was “sticky” – it had to go back to the same server instance. That worked fine for local stdio connections but became a problem the moment MCP moved to remote HTTP.

Now, every request is independent. Version, client identity, and capabilities travel with each request. The server doesn’t need to remember who you are between calls. For infrastructure operators, this changes everything: you can use plain round-robin load balancers instead of sticky sessions, you can scale server instances without preserving protocol-level session state, and you can scale horizontally without a shared session store.

Multi Round-Trip Requests (MRTR) replace server-initiated flows. Before, if a server needed more information before it could finish an operation (think: asking for approval, requesting clarification, eliciting input), it had to send a request back to the client while keeping the connection open. MRTR inverts this: the server says “I need X before I can proceed,” and the client sends the requested data in the next round trip. No long-lived connections required.

MCP becomes more HTTP-native.The spec now includes dedicated headers, Mcp-Method and Mcp-Name, which let gateways, rate limiters, and proxies inspect and route MCP traffic without parsing the JSON-RPC body. List responses include cache metadata so clients can know how long tools/list results are good for. These are boring details, but they matter: infrastructure operators can now treat MCP like any other HTTP service.

Extensions are formalized. Tasks – which used to be experimental – are now an official extension. MCP Apps (for server-rendered UIs), Enterprise-Managed Authorization, and custom extensions live here too. The core protocol stays lean; rich behavior lives in extensions.

Authorization got tightened. The spec moved away from Dynamic Client Registration toward Client ID Metadata Documents. OAuth mix-up attacks are now defended against. Credentials and issuer bindings are stricter. This matters for security-conscious deployments.

There’s a deprecation policy. Features marked deprecated get at least a 12-month window before removal. Roots, Sampling, Logging, and the legacy HTTP+SSE transport are deprecated, but nothing disappears overnight.

Why This Timing?

The release candidate appeared in May specifically to give SDK authors and implementers time to test. The final spec landed July 28. The 10-week validation window was a practical decision because, as the maintainers said explicitly, this is a deliberately breaking change and authors and implementers needed time to get ready.

Along with the final spec, Enterprise-Managed Authorization became stable on June 18, letting organizations use their existing identity provider to control MCP server access centrally.

Why Do These Changes Matter?

Here’s what matters: the MCP maintainers redesigned the protocol around reliability and scalability requirements that had emerged as MCP moved into production deployments. Sessions, persistent connections, and server-initiated requests created scaling and operational requirements that the new architecture is designed to remove. The new specification replaces that foundation with a stateless request-response model.

The graphic above shows the before and after. But the real question isn’t “what changed” – it’s why these changes position MCP for something much bigger than function-calling.

Coming next: We’ll dig into what these architectural changes actually enable and why the maintainers are now talking about MCP not as a tool-calling API, but as a full application protocol for agents.

Learn More

MCP 2026-07-28 Specification Release (https://blog.modelcontextprotocol.io/posts/2026-07-28/)
MCP Changelog: Key Changes (https://modelcontextprotocol.io/specification/2026-07-28/changelog)
Enterprise-Managed Authorization Stable Release (https://modelcontextprotocol.io/specification/2026-07-28/)

MCP 2026-07-28 FAQ: What Changed in the New Specification?

What changed in the MCP 2026-07-28 specification?

The July 28, 2026, MCP specification introduced a stateless request-response architecture for remote deployments. It removed protocol-level sessions, changed how server-to-client interactions work, added HTTP-visible routing metadata, formalized extensions, and strengthened authorization requirements.

Why did MCP move to a stateless architecture?

The previous session-based model created operational requirements such as sticky routing and shared session stores. With stateless MCP, each request carries the information needed to process it, making it easier to distribute traffic across standard web infrastructure and scale server deployments horizontally.

What are Multi Round-Trip Requests in MCP?

Multi Round-Trip Requests, or MRTR, provide a new way to handle interactions that require additional information from the client. Instead of keeping a connection open while the server sends a request back to the client, the server indicates what it needs, and the client provides that information in a subsequent request.

What does the new MCP specification mean for enterprise deployments?

The changes make MCP easier to operate with infrastructure enterprises already use, including load balancers, proxies, gateways, and caching. They also support stronger enterprise authorization patterns and reduce some of the state-management complexity that came with earlier remote MCP deployments.