MCP drops sessions: the 28 July 2026 spec makes in-house agents replicable — and here is the list you must fix before upgrading

On 28 July 2026 the Model Context Protocol — the layer almost every enterprise AI assistant now uses to reach out to tools and data — shipped a new specification, named after the day it landed: 2026-07-28. The headline is not a feature that was added but something that was taken away: the protocol no longer has a session. No initialize handshake, no Mcp-Session-Id header. For anyone operating an in-house AI stack, that removal fixes the exact bottleneck that made MCP servers awkward to replicate across machines; in exchange, this is a breaking release, and the things that were removed are genuinely gone. This article reads the three primary project documents, quotes the load-bearing parts verbatim, and turns them into a practical question: if your company runs an MCP server behind the firewall, what do you need to audit? Figures checked on 03/08/2026.

What exactly did MCP change?

MCP removed the notion of a session at the protocol level: instead of opening a connection, shaking hands to agree on a version and a capability set, and then keeping that connection for every later call, each request now carries everything it needs and stands on its own.

In the release post of 28 July 2026, lead maintainers David Soria Parra and Den Delimarsky put it plainly in the opening section: "The highlight of this release is a stateless protocol core - MCP is transforming from a bidirectional stateful protocol into a request/response stateless protocol." They add that this was one of the most requested changes from developers who wanted better reliability and scalability out of their MCP servers.

Mechanically, two things were pulled out. The first is the handshake: "we've officially retired the initialize/initialized exchange along with the Mcp-Session-Id header". The second is the state that travelled with it. In their place, every request declares its own protocol version and client capabilities inside _meta, and a server that wants to advertise what it supports exposes a new server/discover call. Note the asymmetry — it is mandatory for servers but optional for clients. The changelog is explicit: "servers MUST implement this RPC to advertise their supported protocol versions, capabilities, and identity. Clients MAY call it before any other request."

How seriously the project treats this release shows in its label: it is stable, not a preview. The GitHub release page carries exactly one line — "This release marks the stable release of the 2026-07-28 revision of the Model Context Protocol" — timestamped 28 July 2026 at 16:47 UTC. The ecosystem behind that number is not small either: according to the release post, "Across our Tier 1 SDKs, we're seeing close to half-a-billion downloads a month, with both TypeScript and Python SDKs crossing the 1 billion total downloads threshold."

Why dropping sessions matters for an in-house AI stack

Because a protocol-level session ties one client to exactly one server process, and once you are tied like that, every way of replicating for capacity or for survival becomes expensive.

Picture an internal assistant running inside a company: it connects to one MCP server to search documents and another to query the sales system. Under a session model, running two replicas of the same MCP server for resilience forces the operations team into one of two choices — configure sticky load balancing so every request from a client returns to the same machine, or stand up a shared state store in between. Both add a component, a failure mode and something else to monitor. The new spec deletes that requirement in a sentence: "Any request can now land on any server instance behind a plain round-robin load balancer without needing shared storage."

The easy misreading here, which the documentation heads off directly, is that "stateless" means your application may not remember anything. The maintainers write: "Dropping the protocol-level session doesn't force your application to be stateless. If your server needs to carry state across calls, mint an explicit handle from a tool and have the model pass it back as an argument." State still exists; it simply moves from hidden inside the transport to visible in the open — the server mints a handle and the model threads it between calls. Their stated reason is pragmatic: it works better precisely because the model can see the handle.

Alongside comes a small change that carries real weight for infrastructure teams: method and tool names now travel in HTTP headers. The release post says: "Streamable HTTP requests now must include Mcp-Method and Mcp-Name (SEP-2243). Your gateway, rate limiter, or WAF can route and meter on those headers instead of parsing JSON bodies." For an organisation that already runs an API gateway and a web application firewall, this means per-tool blocking and rate limiting can finally live at the network layer, without unpacking JSON payloads. That is exactly the sort of control a security team asks for before letting an AI assistant near internal systems — we described that protective architecture in a security architecture for in-house AI.

This release breaks compatibility, and it breaks it predictably

A client written against the new revision talking to a server on the old one will fail, and the reverse fails too — the specification does not hide this but publishes a matrix of all five combinations along with the outcome of each.

This is good specification writing: rather than leaving each team to guess, the versioning and compatibility page spells out the expected behaviour of every client–server pair. The spec calls an implementation written the old way "legacy", one written the new way "modern", and one supporting both "dual-era". The core sentence: "A server that wishes to support both legacy clients (which expect an initialize handshake) and modern clients (which use per-request metadata) MAY implement both behaviors."

Row two is the one to worry about. When a modern client calls a legacy server, the spec concedes the server may "stay silent, or even process an era-ambiguous method under legacy semantics". In an internal system where the MCP server touches real data, a call silently executed under the wrong semantics is the hardest class of incident to trace. That is why the safe upgrade order is servers first — or servers running in dual-era mode — rather than clients first.

The release also removes a few things teams may be using without noticing: ping, logging/setLevel and notifications/roots/list_changed are all gone from the protocol. Log level is now set per request through io.modelcontextprotocol/logLevel in _meta, and the changelog is blunt: "servers MUST NOT emit notifications/message for requests that did not include this field". One more detail that will quietly break hand-written error handling: the resource-not-found error code moves from -32002 to -32602 to align with JSON-RPC.

The hardening: a classic OAuth hole gets closed

The release requires authorisation servers to return their own identifier in the response, and requires clients to validate it before redeeming a code — precisely the countermeasure the IETF standardised back in 2022 against a named family of attacks.

The maintainers concede this is where implementers spend most of their time. The concrete change: "Authorization servers should return the iss parameter per RFC 9207, and clients must validate it before redeeming a code (SEP-2468). This closes an authorization-server mix-up hole." Read IETF RFC 9207, published in March 2022, and it is clear why this is not a footnote: the document defines iss to "explicitly include the issuer identifier of the authorization server in the authorization response", and concludes that "The iss parameter serves as an effective countermeasure to 'mix-up attacks'". Those attacks exploit a client's inability to tell which server issued the authorisation code it just received — a real scenario in enterprises running several identity providers at once.

Two further tightenings point the same way. One binds credentials to their issuer: "Client credentials are bound to the issuer that minted them. No reuse across authorization servers (SEP-2352)." The other begins retiring dynamic registration: "Dynamic Client Registration itself is now formally deprecated in favor of CIMD. DCR continues to work for backward compatibility, but will be removed in a future version of the MCP spec." For an organisation that has built departmental access control around an internal assistant — the model we set out in departmental access control for internal AI — this is good news: the protocol is moving from "anyone may register" to "identity must be declared up front and be verifiable".

The change operations teams will appreciate most, though, is governance rather than engineering. The changelog records: "Adopt a specification feature lifecycle and deprecation policy defining the Active, Deprecated, and Removed feature states, a minimum twelve-month deprecation window, and a registry of deprecated features (SEP-2596)." Previously a feature could vanish between revisions with no warning. From now on, anything entering the Deprecated state gets at least a year, and there is a registry to check. The release post puts it more simply: "so you can plan upgrades instead of reacting to them".

The same week: 22 MCP-related vulnerabilities published

In the ten days around the release, the United States National Vulnerability Database published 22 MCP-related vulnerabilities — and the most repeated pattern among them is exactly what the new spec just deleted from the protocol: a session identifier that is not bound to its owner.

That figure is directly checkable rather than estimated. A public query against the National Vulnerability Database API for the keyword MCP, limited to publication dates from 25/07/2026 to 03/08/2026, returns totalResults: 22 as checked on 03/08/2026. To be fair about what that means: these are vulnerabilities in products that implement MCP, not in the specification. And by the same token, removing protocol-level sessions does not automatically patch a single one of them — each product still has to fix its own.

What is worth reading is the pattern. Three of them describe nearly the same mistake in three unrelated projects. The NVD record for CVE-2026-67431, in MCP's own official Ruby SDK, states that the streamable HTTP transport "does not bind a session ID to a session owner, allowing an attacker with a stolen session ID to send tools/call requests that execute in the victim's session". For HashiCorp's terraform-mcp-server the consequence is sharper still: someone who obtains another user's session ID can have their tool calls "executed using that user's Terraform credentials". And ArcadeDB, disclosed on 02/08, "fail[s] to bind the authenticated principal in the MCP HTTP transport, causing all engine permission checks to silently pass as no-ops".

The second cluster is more basic: MCP endpoints exposed without authorisation checks. The most severe of the whole set is CVE-2026-66012, with a maximum CVSS of 10.0, in the note-taking application SiYuan: its POST /mcp endpoint sits behind only a generic authentication check with no admin-role or read-only enforcement, and per NVD it "exposes 31 MCP tools, including a file tool with list/read/write/delete/rename/copy actions across the entire workspace". The same cluster includes a flaw that crashes GitHub's official MCP server with a single malformed request where, in NVD's words, "the crash occurs before any authentication or token validation".

Read this table next to the new specification and the overlap is no coincidence: when sessions are something each project implements for itself inside the transport, each project makes the same mistake for itself. Dropping sessions from the protocol does not erase the bugs that already exist, but it does erase a category that every future implementer would otherwise have to get right unaided. The lesson applies even before you upgrade: treat any MCP server in your organisation as a privileged HTTP endpoint — behind authentication, never listening on every network interface, and logging who invoked which tool.

What Vietnamese companies running an in-house MCP server should do

The task is not to upgrade this week but to build an inventory: list the MCP servers running in the organisation, establish who wrote each one and which revision it speaks, and only then decide the order — servers first, clients after.

The reason for that order is in Table 2: the combination that fails silently is a new client against an old server, while an old client against a new server fails loudly with 400 Bad Request. Between two kinds of failure, the noisy one is always easier to handle. For MCP servers supplied by third parties, the questions to put to the vendor are specific: does it support 2026-07-28 yet, does it run in dual-era mode, and when will the legacy HTTP+SSE transport be dropped?

The upside is clear enough to be worth scheduling. A stateless MCP server can run many replicas behind an ordinary load balancer, which means the internal assistant stack no longer has a single point of failure and can scale by adding machines rather than replacing them with bigger ones. That is the missing piece in the picture we drew in the architecture of an in-house AI system and in the model-serving discussion in building in-house AI: serving. Wiring MCP into existing enterprise systems is covered separately in building in-house AI: integration.

There is one more reason to audit, and it is legal rather than technical. The MCP server is where an AI assistant touches an organisation's real data, which routinely includes personal data belonging to staff and customers. Per the Ministry of Public Security portal: "Ngày 01/01/2026, Luật Bảo vệ dữ liệu cá nhân (Luật số 91/2025/QH15) chính thức có hiệu lực thi hành" — on 1 January 2026 the Personal Data Protection Law took effect, establishing citizens' rights to be informed, to consent, and to access, correct and demand deletion of their data. The same page sets out the penalty: the maximum administrative fine for buying or selling personal data is ten times the revenue obtained from the violation. Meeting those obligations requires being able to say who accessed what data, when, and through which tool. Having the tool name in an HTTP header, loggable at the API gateway, makes that answer far easier to assemble than digging JSON payloads out of logs. We analysed the AI-specific legal framework separately in Decree 142/2026 on AI.

Keep the dose right, though: this is a protocol specification, not an emergency patch, and the twelve-month policy exists precisely to give organisations time. But there is one thing worth doing immediately and at almost no cost: open the inventory of internal MCP servers and check whether any still run the legacy HTTP+SSE transport — the thing considered obsolete since March 2025 that has now formally started a one-year countdown.

The MCP specification of 28 July 2026 takes the session out of the protocol, and it is precisely that removal which lets an in-house MCP server run many replicas behind an ordinary load balancer — in exchange, every system that relied on sessions has to be audited before it can be upgraded.

Frequently asked questions

Note: This article is compiled from public sources, checked on 03/08/2026. Quoted passages are taken verbatim from the official Model Context Protocol documentation, from IETF RFC 9207, from the National Vulnerability Database and from the Vietnamese Ministry of Public Security portal; the Vietnamese-to-English rendering of the last of these is Namtech's. Vulnerability figures come from the National Vulnerability Database (NIST), checked 03/08/2026. Table 5 is Namtech's recommendation, not content from the MCP documentation. Illustrations are from Pexels under the Pexels License — lead and share images: panumas nikhomkhai. For information only; not legal advice.