Architecture · 8 min read · Aug 15, 2026

The session went away, and the sticky server with it.

If your group is connecting AI to a POS, an accounting package and an HR system, the protocol underneath that plumbing changed on 28 July 2026 — and it changed in the direction of being cheaper to run and easier to secure.

What MCP is, for someone who does not write the integrations

The Model Context Protocol is a standard way for an AI system to reach the software you already run. Instead of a bespoke integration per model per system, a system exposes an MCP server once and any compliant client can use it. It has become the default: the project reports passing 400 million monthly SDK downloads, roughly a fourfold increase over the year.

The 2026-07-28 revision is the largest since launch. Three parts of it matter to a buyer.

Before the 2026-07-28 specification, a client opened a session with one server instance and every later call had to return to it. After, each request is independent and any instance can answer.
The change in one picture: no session identifier means no sticky server, which is what makes serverless and edge deployment possible.

1 — The core is stateless

MCP moved from a bidirectional stateful protocol to plain request and response. The initialize handshake and the Mcp-Session-Id header are gone — removed, not deprecated. Sessions previously pinned a client to whichever server instance answered first, so scaling meant session affinity, sticky load balancing and instances that could not share work.

Without them, servers deploy to serverless and edge infrastructure, list results become cacheable, and horizontal scaling is ordinary load balancing. For an operator the consequence is commercial rather than technical: the integration layer becomes something that costs almost nothing when idle, which is most of the time for a system that syncs a POS overnight.

2 — Extensions became a governed system

Capabilities that were informal conventions now ship under a versioned extensions framework with reverse-DNS identifiers, capability negotiation and versioning independent of the core spec. Two matter:

  • MCP Apps — server-rendered interactive interfaces running in sandboxed iframes, with tools declaring their UI templates up front so a client can prefetch and security-review them before anything renders.
  • Tasks — a stateless lifecycle for long-running work, contributed by AWS: tools/call returns a handle and the client drives progress through tasks/get, tasks/update and tasks/cancel.

Tasks is the one to care about if any of your jobs take minutes rather than seconds — a month-end consolidation, a bulk reconciliation, a document batch. It gives that work a defined shape instead of a held-open connection.

3 — Authorization got materially stricter

Authorization now aligns closely with OAuth 2.0 and OpenID Connect. Clients must validate the iss parameter on authorization responses per RFC 9207, and client credentials are bound to the issuer that minted them. Dynamic Client Registration is deprecated in favour of Client ID Metadata Documents.

The practical effect is that MCP servers integrate with enterprise identity providers — Microsoft Entra, Okta — as a first-class path rather than a workaround. For a multi-entity group this is the difference between access that follows your existing directory and a second, parallel set of credentials nobody audits. It is the same argument we make about isolation that is enforced rather than remembered.

Roots, Sampling and Logging are deprecated, as is the legacy HTTP+SSE transport, each with at least twelve months of runway. Nothing breaks this quarter — but anything built on them now has a known end date.

What to ask whoever maintains your integrations

  • Do we rely on Mcp-Session-Id or any implicit session state? That is the migration, and it is not optional.
  • Do we use server-initiated elicitation or sampling? Those move to InputRequiredResult.
  • Are we on the experimental Tasks API? It has to move to the new stateless lifecycle.
  • Are we still on HTTP+SSE transport? Twelve months of runway is not the same as no deadline.
  • Can our MCP servers authenticate against our existing identity provider — and if not, what are they using instead?

The Tier 1 SDKs — TypeScript, Python, Go and C# — already speak the new specification, so this is a scheduling question rather than a blocked one. The groups that will feel it are those whose integrations were written once by a contractor and have not been opened since.

Sources

Dealing with this in your own group?

We answer scoping questions before there's a contract in sight — including the ones about cost and data handling.

Book a demo See what we've shipped

Questions

Short answers,
in full.

The questions this article gets asked most, answered so each one stands on its own.

Talk to us
What changed in the MCP 2026-07-28 specification?

Three things: the protocol core became stateless, with the initialize handshake and Mcp-Session-Id header removed rather than deprecated; extensions became a governed, versioned framework covering MCP Apps and Tasks; and authorization aligned with OAuth 2.0 and OpenID Connect, requiring iss validation per RFC 9207 and deprecating Dynamic Client Registration in favour of Client ID Metadata Documents.

Why does a stateless MCP matter commercially?

Sessions pinned a client to one server instance, which forced sticky load balancing and kept servers running to hold state. Without them, MCP servers deploy to serverless and edge infrastructure, list results become cacheable, and scaling is ordinary load balancing. For workloads that are idle most of the day — an overnight POS sync, for instance — the integration layer's cost falls accordingly.

Will the 2026-07-28 spec break our existing MCP integrations?

Not immediately. Roots, Sampling, Logging and the legacy HTTP+SSE transport are deprecated with at least twelve months of runway. The genuine migration work is auditing any reliance on Mcp-Session-Id or implicit session state, moving server-initiated elicitation or sampling to InputRequiredResult, and moving experimental Tasks API usage to the new stateless lifecycle.

Can MCP servers use our company identity provider?

Yes, and that is now the intended path. Authorization aligns with OAuth 2.0 and OpenID Connect, with client credentials bound to the issuer that minted them, which supports integration with enterprise identity providers such as Microsoft Entra and Okta. For multi-entity groups this keeps access following the existing directory rather than creating a second set of credentials outside it.

Keep reading

More from the desk.

OperationsWhere back-office agents pay back, and where they don't ToolingThe AI tool stack for a multi-entity operator BuyingThe questions to ask an AI vendor before you sign OperationsIs that outlet actually profitable, or just busy? ControlsWhat happens when an AI agent gets it wrong CommercialsAnother hire, an outsourcer, or an agent?