Version 3

The 2026-07-28 MCP stateless specification release candidate is attracting implementation activity from major platform vendors and a new security-focused argument for adoption. GitHub's MCP server announced support for the new spec [8], and Microsoft's Azure App Service team has published deployment guidance [7], adding two major platform voices to what began as primarily developer and analyst coverage. Simon Willison has shifted from documenting MCP integration with friction notes to active advocacy, releasing three MCP tools and arguing that MCP's constrained interface is fundamentally safer than shell-based agents [14][15]. The enterprise-readiness narrative is consolidating, though a skeptical counterargument — that six critical challenges persist beyond the spec change — remains unresolved [16].

MCP's stateful session model was a concrete obstacle to enterprise cloud deployment; the stateless redesign removes it. The emerging security argument — that bounded tool interfaces reduce agent attack surface compared to arbitrary command execution — extends the case for MCP beyond infrastructure teams to application developers building sensitive systems, broadening the potential adoption base.

The 2026-07-28 MCP specification release candidate redesigns the protocol's transport layer to be stateless, removing per-session, per-server-instance dependencies that had made standard cloud load-balancing incompatible with the protocol [1][2]. The spec was authored by Anthropic's David Soria Parra and Den Delimarsky. Under the prior design, MCP sessions were bound to individual server instances; the new spec removes that constraint so any server instance can handle any request [1][3]. Ars Technica and VentureBeat frame this as the largest update the protocol has received [1][4]; TheNewStack identifies the prior stateful model as the main barrier to enterprise adoption and frames the spec as its resolution [5]. Stacktree has published a technical breakdown of what specifically changed and what existing implementations may break [6].

Major platform vendors are treating the spec change as actionable. Microsoft's Azure App Service team has published guidance on deploying MCP under the new stateless model [7]. GitHub's MCP server separately announced support for the next MCP specification [8], and a changelog date of July 23 suggests GitHub was implementing the new spec before the formal release candidate. A commercial advisory layer is also forming: Manufact (YC S25) launched an MCP Cloud product [9], CData and Nordic APIs have published enterprise adoption guides [10][11], and Gainsight has documented an MCP server integration for its customer success platform [12].

Simon Willison, who had initially documented multi-platform MCP integration as feasible but involving 'quite a few steps' [13], has shifted to active advocacy with the stateless spec. In a July 31 post, Willison argues that MCP's constrained tool interface is 'much easier to reason about' than shell-based agents operating in open network environments, framing MCP as a fundamentally safer foundation for LLM applications [14]. He released three MCP-related projects the same day: datasette-mcp (exposing database query tools on any Datasette instance), mcp-explorer, and an alpha llm-mcp-client plugin for the LLM CLI tool that he is considering promoting to core [14][15]. The security argument — that bounded tool interfaces reduce attack surface compared to arbitrary command execution — is a distinct rationale for MCP adoption beyond the original scaling case.

Not all observers read the stateless spec as a complete solution. A Medium analysis identifies six critical challenges still facing MCP in 2026, arguing the spec is a meaningful step without fully addressing enterprise adoption barriers [16]. Developer community discussion on Reddit surfaces practitioner-level concerns that go beyond the transport layer [17]. Both Claude and ChatGPT now accept custom MCP server connections [13][18], though implementation diverges across platforms, leaving the actual developer experience platform-specific. The specification is currently a release candidate, so final ratification and client-side implementation timelines are not yet confirmed.