MCP went stateless. What the 2026-07-28 specification changes for the operating model you are building

Why this is on the go:lofty blog. The studio runs through MCP every working day: the website, the CRM, the database and the commercial opportunities monitors are all reached by AI agents through MCP servers. When the protocol underneath that changed on 28 July 2026, it changed our own operating model before it changed anyone else's. This is what I would want a board member or a technical founder to know before the next infrastructure planning cycle, written so that both can read the same page.

Key takeaways

• The Model Context Protocol (MCP) is the open standard through which AI agents reach a company's systems. On 28 July 2026 the 2026-07-28 specification made it stateless: no session, no handshake, every request self-contained.
• MCP servers now run as ordinary HTTP workloads. Load balancing, caching, rate limiting, routing and audit all work with the infrastructure a platform team already owns.
• Governance moves to the gateway. Because method and tool names travel in the Mcp-Method and Mcp-Name headers, per-tool policy becomes an infrastructure control with an audit trail.
• Human approval becomes a designed checkpoint through Multi Round-Trip Requests (MRTR), which turns "an agent may not delete data or spend money without a human" into an enforced control.
• The tool catalogue is now a product. Cacheable, deterministically ordered catalogues reward servers that are small, stable and well described, and they lower inference cost.
• A twelve-month deprecation clock runs to July 2027. Inventory, classify, gate, encode approvals, assign ownership, plan identity, schedule migrations: seven steps for the next two quarters.

Published 12 September 2026. Based on the MCP 2026-07-28 specification, its changelog and the referenced Specification Enhancement Proposals. Written for management boards and technical founders.

The short version, for a board

The Model Context Protocol (MCP) is the open standard through which AI agents reach the systems a company runs on: the CRM, the ERP, the database, the ticketing queue. Think of it as the plug shape that lets any agent connect to any system without a bespoke integration for each pair.

Until this summer, MCP was stateful. Every conversation between an agent and a system opened a session that had to be remembered by one specific server for as long as it lasted. That works on a laptop. In a data centre it means special hosting, sticky sessions and infrastructure your platform team cannot reuse.

On 28 July 2026 the maintainers published the largest revision since launch and made the protocol stateless. Every request is now complete in itself. Any request can land on any server. Routing, metering and authorisation can be done at the gateway from HTTP headers alone, the way your other services are already governed.

The consequence is simple to state. MCP servers now behave like any other web service in your estate. They can be load-balanced, cached, rate-limited, audited and governed with tooling you already own. That is the moment a protocol stops being a developer topic and becomes an operating-model topic.

Scale is settled. The maintainers report close to half a billion SDK downloads a month across the four official SDKs, with the TypeScript and Python SDKs each past one billion cumulative downloads. AWS, Google Cloud, Microsoft, Cloudflare, Figma, Supabase and Xero shipped support on release day. The protocol has lived under the Linux Foundation since late 2025. Whatever your view of agents, the substrate they will use to reach your systems is now decided.

What is MCP, at the level that matters for planning?

The M x N problem

Before MCP, every pairing of a model and a system was a separate integration. With M agents and N tools you maintained M x N connectors, each with its own authentication, error handling and documentation. MCP collapses that to M + N. A system publishes one MCP server; any compliant agent can consume it. HTTP did the same for the web, and the Language Server Protocol did it for code editors. One side publishes a standard surface, the other side stops writing bespoke adapters.

Three roles and four capabilities

The architecture has three roles. The host is the agent application that decides what to call: Claude, Cursor, Copilot, or an internal agent runtime. The client is the transport adapter inside the host, one per server. The server is the wrapper around a system of record: Webflow, HubSpot, Salesforce, Veeva, Postgres, an ERP.

Servers expose four kinds of capability. Tools are actions, and the model chooses when to invoke them. Resources are data, and the application decides what to surface. Prompts are templates, and the user selects them. Elicitation lets a server pause in the middle of a call and ask a human for a confirmation or a missing value. That last capability is where governance lives, and the July revision rebuilt it from the ground up.

The misreading that costs the most

Most organisations file MCP under integration. That framing leads to the wrong optimisation target. An integration layer is measured by API coverage: how many endpoints are wrapped. A capability exposure layer is measured by how much context an agent must consume before it can work out what to do. Those are different objective functions, and the second one now determines the quality of every agentic workflow you run.

The evidence sits in the tool catalogue. A server that exposes 140 thinly described tools forces the model to spend its context window on discovery before it does any work. A server that exposes twelve well-described capabilities, each with a clear contract and a clear failure mode, lets the model act. The July specification made tool lists cacheable and deterministically ordered precisely because catalogue design has become a performance variable. Treat MCP as product surface, with the discipline you apply to a public API or a customer-facing interface.

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

The release notes from lead maintainers David Soria Parra and Den Delimarsky list seven headline changes. Six of them matter to an operating model. Each one below is stated twice: what it is in protocol terms, then what it means for you.

• Stateless core. The initialise handshake and the Mcp-Session-Id header are removed (SEP-2575, SEP-2567). Each request carries its protocol version, client identity and capabilities in its own metadata, and an optional server/discover call exists for clients that want capabilities up front. For you: any request can land on any instance behind a plain round-robin load balancer, with no sticky sessions and no shared session store.
• Multi Round-Trip Requests (MRTR). Elicitation and sampling used to require a held-open, two-way stream. Under MRTR (SEP-2322) the server returns an input_required result with the questions it needs answered, and the client retries the original call with the answers attached. For you: a human approval step is now a plain request-and-response pattern that survives load balancers and serverless runtimes.
• Header-based routing. Streamable HTTP requests must carry Mcp-Method and Mcp-Name headers (SEP-2243), and servers reject requests where headers and body disagree. For you: a gateway, WAF or rate limiter can route, meter and authorise per tool without opening the JSON body.
• Cacheable catalogues. tools/list, prompts/list, resources/list and resources/read now return ttlMs and cacheScope (SEP-2549), modelled on HTTP Cache-Control. For you: clients know how long a catalogue stays fresh and whether it may be shared across users, which keeps prompt caches intact and lowers inference cost.
• Authorisation hardening. Clients must validate the RFC 9207 issuer parameter before redeeming a code (SEP-2468). Credentials are bound to the issuer that minted them (SEP-2352). Dynamic Client Registration (DCR) is formally deprecated in favour of Client ID Metadata Documents (CIMD). For you: MCP identity now looks like the OAuth patterns your identity team already runs.
• Extensions framework and deprecation policy. Tasks, MCP Apps and Enterprise Managed Authorisation now live as formal extensions on their own release cadence. Roots, Sampling and Logging are deprecated with a twelve-month minimum runway, as is the legacy HTTP+SSE transport. For you: a planning horizon you can schedule against.

One nuance is being misreported and deserves emphasis. Removing the protocol session does not force your application to be stateless. If a workflow needs state across calls, the recommended pattern is to mint an explicit handle from a tool and have the model pass it back as an argument. State becomes visible to the model and to your audit log, which is a better place for it than a transport header.

The reaction split in a telling way. InfoQ summarised one camp as calling the release a rediscovery of REST. That reading misses the point. The value of MCP was never the transport; it was the standard. A standard that runs on commodity HTTP infrastructure is a standard that procurement, security and platform teams can approve without a special case.

What does stateless MCP mean for the operating model? Six planning implications

1. MCP servers are now a standard workload class

Sticky sessions, session stores and deep packet inspection at the edge were the three reasons remote MCP servers needed bespoke hosting. All three are gone at the protocol layer. Plan for MCP servers to run wherever your other HTTP services run, under the same SLOs, the same observability and the same cost model. If a vendor is still selling you a proprietary MCP hosting tier, ask what it does that a standard container and a gateway do not.

2. Governance moves to the gateway

Because method and tool name travel in headers, per-tool policy is now an infrastructure control rather than an application control. Rate-limit a destructive tool more tightly than a read tool. Route high-cost tools to dedicated capacity. Deny a tool by name for a given identity. Meter usage per team for chargeback. Every one of these is a gateway rule, and every one produces an audit trail your compliance function can read. Budget for an MCP-aware gateway as a line item in the same way you budget for an API gateway today.

3. Human approval becomes a designed checkpoint

MRTR makes the approval step a first-class, stateless pattern. It is the same principle set out in the piece on cascading automation: automation removes administrative work and must not remove judgement. Supabase describe using it to confirm the cost of a new project before creation, or to confirm a query that would delete data. Decide now which actions in your estate require a human in the loop, encode that as elicitation in the server rather than as policy in a document, and you have converted a governance principle into an enforced control. This is the single most important design decision in an agentic operating model, and the protocol has just made it cheap.

4. The tool catalogue is a product

Cacheable, deterministically ordered catalogues reward servers that are stable and well described. Assign ownership of each MCP server to a product owner, and only to an engineer as second line. Review the catalogue as you would review a public API: naming, granularity, contracts, deprecation. Measure the context an agent spends before its first useful action, and drive that number down.

5. Identity is where integration time goes

The maintainers state that authorisation is where implementers spend most of their integration effort. The move from DCR to CIMD, issuer validation and issuer-bound credentials all push MCP identity toward the patterns your identity team already runs for OAuth. Put MCP client identity on the IAM roadmap now, and treat the Enterprise Managed Authorisation extension as the target state for any server that touches regulated data.

6. A twelve-month clock is running

The formal deprecation policy is a gift to planners. Roots, Sampling, Logging and the HTTP+SSE transport keep working until at least July 2027. The old initialise handshake and session header, by contrast, are removed rather than deprecated, so a server that must serve older clients has to run both paths. Inventory every MCP server and host in your estate, tag each with its protocol version, and schedule migrations inside the window. Migration cost is real for anything that depended on session identifiers; the SDK teams published migration notes for exactly that case.

What I see from the operator's chair

Three observations from running a studio on this protocol, offered because they are the parts the release notes cannot tell you.

The bottleneck was never the connection. When we moved the studio onto MCP, the first month went on wiring. Every month since has gone on catalogue design: which capabilities to expose, how to name them, what a failure should look like to the model. The July revision confirms that this is where the effort belongs. A company that treats its MCP servers as a product will outperform one that treats them as plumbing, by a margin that shows up in agent reliability within weeks.

Approval design is a board question. Elicitation decides which actions an agent can take alone and which need a human. That is a risk appetite decision, and it belongs at the same table that sets delegation limits for people. The technical team can encode it; it should not be the team that invents it. Ask for the list of destructive and financial tools, and ask who signed off on where the checkpoint sits.

The twelve-month window is shorter than it looks. Most estates I see have MCP servers nobody at the centre knows about, adopted by one team for one workflow. The inventory step in the next section is unglamorous and it is where the migration either becomes routine or becomes an incident in the summer of 2027.

What should a company do about MCP in the next two quarters?

1. Inventory. List every MCP server and host in use, including the ones individual teams adopted without telling you. Record protocol version, transport, authentication method and whether it relies on session state.
2. Classify tools by blast radius. Read, write, destructive, financial. This classification drives gateway policy and elicitation design in the next two steps, and it is the same discipline as a business case: name the conditions behind the numbers before anyone signs.
3. Stand up an MCP-aware gateway. Route, meter and authorise on Mcp-Method and Mcp-Name. Start with the servers that touch customer data or money.
4. Encode approvals as elicitation. Every tool in the destructive or financial class gets an MRTR confirmation step. Test that the confirmation survives a load-balanced deployment.
5. Assign catalogue ownership. One accountable owner per server. Quarterly catalogue review with a context-cost metric.
6. Put MCP identity on the IAM roadmap. Plan the move from DCR to CIMD. Evaluate Enterprise Managed Authorisation for regulated systems.
7. Schedule migrations. Anything on the deprecated primitives or the legacy transport moves before July 2027. Anything on session identifiers moves sooner, because compatibility there is a dual-path cost you are paying every month.

The strategic reading

Every previous wave of enterprise software had a substrate moment: TCP/IP for networks, HTTP for the web, SQL for data, OAuth for identity. The pattern is the same each time. A protocol matures from clever to boring, the infrastructure teams absorb it, and the competitive question shifts from whether you can connect to how well you have designed what sits on top. The July 2026 revision is MCP's boring moment, and boring is the highest compliment infrastructure can receive.

The consequence for operators is that the differentiator has moved up a layer. Access to systems through agents is now table stakes. Advantage sits in the quality of the capability surface you expose, the precision of the governance you encode, and the speed at which your operating model can absorb an agent as a participant rather than a tool. That is growth architecture work, and it is where I expect the next eighteen months of serious operating effort to go.

If you are planning infrastructure for 2027, plan for agents that reach your systems through a protocol your platform team can govern like any other. The protocol has done its part. The design decisions are now yours.

Sources

• Model Context Protocol Blog, "The 2026-07-28 Specification", David Soria Parra and Den Delimarsky, 28 July 2026. blog.modelcontextprotocol.io/posts/2026-07-28/
• Model Context Protocol Blog, "The 2026-07-28 MCP Specification Release Candidate", 2026. blog.modelcontextprotocol.io/posts/2026-07-28-release-candidate/
• MCP Specification 2026-07-28 and changelog. modelcontextprotocol.io/specification/2026-07-28
• InfoQ, "MCP Goes Stateless, and Developers Ask Whether That Just Makes it an API Again", August 2026.
• Equixly, "Stateless MCP: What the 2026-07-28 specification changes for security", 5 August 2026.
• Specification Enhancement Proposals referenced: SEP-2243, SEP-2322, SEP-2352, SEP-2468, SEP-2549, SEP-2567, SEP-2575, SEP-2577, SEP-2663. github.com/modelcontextprotocol/modelcontextprotocol

Talk to us about the MCP servers your agents already depend on.