The release candidate for the Model Context Protocol's largest specification rewrite since its 2024 launch removed the concept of a session entirely today, requiring every server call to carry its own complete context instead of relying on a persistent connection between client and server.

A protocol built without memory

The Model Context Protocol - the open standard that lets AI agents query databases, trigger workflows, and pull live data from external systems through a consistent interface - published its 2026-07-28 release candidate on May 21, 2026, and the final specification shipped today, July 28, 2026, according to the Model Context Protocol Blog. Lead maintainers David Soria Parra and Den Delimarsky co-authored the announcement, which describes the update as the largest revision of the protocol since its original launch.

The headline change removes the protocol-level session mechanism that MCP has relied on since it first shipped in November 2024. Six Specification Enhancement Proposals, or SEPs, work together to strip statefulness out of the transport layer, according to the Model Context Protocol Blog. Where a client previously established a session through an initialize handshake and then carried a session identifier on every subsequent call, pinning that traffic to whichever server instance issued it, the new specification treats each request as self-contained: any server instance can now handle any request, because the protocol version, client information, and client capabilities that used to travel once at connection time now ride inside a metadata field on every call.

The practical effect reaches production infrastructure immediately, according to the Model Context Protocol Blog. A remote MCP server that previously needed sticky sessions, a shared session store, and deep packet inspection at the gateway can instead run behind an ordinary round-robin load balancer, routing traffic by inspecting a new Mcp-Method header rather than the request body. Clients can also cache tools/list responses for as long as a server's declared time-to-live value permits, removing the need for a long-lived event stream just to learn that a list of tools has changed.

Two Specification Enhancement Proposals accomplish the removal directly. SEP-2575 eliminates the initialize and initialized handshake that opened every session; capability negotiation moves into per-request metadata instead, and a new server/discover method lets a client fetch a server's capabilities on demand rather than only once at connection time. SEP-2567 removes the Mcp-Session-Id header along with the protocol-level session it created. According to the Model Context Protocol Blog, with both gone, any MCP request can land on any server instance, and the sticky routing and shared session stores that horizontal deployments previously required at the protocol layer are no longer necessary.

None of this forces application-level statelessness on developers who still want it, the blog post is careful to note. A server that needs to track state across calls can mint an explicit handle, such as a basket identifier, and have the calling model pass that handle back as an ordinary argument on later calls - the same pattern HTTP APIs have used for years. The maintainers describe this as more than a workable substitute for session state: because the model can compose handles across different tools and reason about them directly, it is, in their account, often a more powerful mechanism than the externally managed, transport-hidden session state it replaces.

Server-initiated prompts get rebuilt too

A stateless protocol still needs a way for a server to interrupt a call and ask the client something mid-request, such as confirming a destructive action before it runs. Two further proposals rebuild that flow without a persistent connection. SEP-2260 makes explicit what earlier spec versions only recommended: a server may only initiate a request while it is actively processing something the client asked for, so a person is never prompted out of nowhere and every such prompt traces back to an action they or their agent actually started.

SEP-2322, described in the specification as Multi Round-Trip Requests, changes how those mid-call prompts get delivered. Rather than holding a Server-Sent Events stream open and waiting, the server now returns an input_required result carrying the prompt and an encoded requestState token. The client gathers the requested input and reissues the original call, attaching the answer and the echoed state token - and because everything needed to resume the operation travels in that payload, any server instance can pick up the retry, not only the one that issued the original prompt.

Three smaller proposals make the resulting traffic easier to operate at scale, according to the Model Context Protocol Blog. SEP-2243 requires the Streamable HTTP transport to carry Mcp-Method and Mcp-Name headers, so load balancers, gateways, and rate limiters can route traffic by operation without inspecting the request body, and servers now reject requests where the headers and body disagree. SEP-2549 adds ttlMs and cacheScope fields to list and resource-read results, modeled on HTTP's Cache-Control header, telling a client how long a response stays fresh and whether it can be shared across users. SEP-414 documents W3C Trace Context propagation inside the protocol's metadata field, fixing the traceparent, tracestate, and baggage key names so a distributed trace can follow one tool call from a host application through the client SDK, the MCP server, and whatever the server calls downstream, appearing as a single span tree in an OpenTelemetry-compatible backend.

Extensions gain a formal governance track

Extensions existed in the November 2025 release, but they had no formal process behind them. SEP-2133 changes that by giving extensions reverse-DNS identifiers, a negotiation mechanism through an extensions map exchanged between client and server capabilities, dedicated repositories with delegated maintainers, and a versioning cycle that runs independently of the core specification. A new Extensions Track inside the SEP process now gives an extension a defined path from experimental status to official status.

Two extensions ship as official in this release. MCP Apps, tracked as SEP-1865, lets a server ship interactive HTML interfaces that a host application renders inside a sandboxed iframe. Tools declare their UI templates in advance, according to the Model Context Protocol Blog, so a host can prefetch them, cache them, and security-review them before anything actually executes. Every action a user takes inside that rendered interface travels back to the host over the same JSON-RPC base protocol used everywhere else in MCP, so a UI-initiated action passes through the identical audit and consent path as a direct tool call.

Tasks, which shipped as an experimental core feature in the November 2025 release, graduates into an extension rather than remaining part of the base specification. Production use surfaced enough required redesign, according to the Model Context Protocol Blog, that an extension became the more appropriate home for it than the core spec. The reshaped lifecycle fits the stateless model: a server can respond to a tools/call request with a task handle instead of an immediate result, and the client drives that task forward using tasks/get, tasks/update, and tasks/cancel calls. Task creation is server-directed - the client can advertise support for the extension, but the server decides whether a call actually runs as a task. The tasks/list method, present in the experimental version, is removed entirely, because the specification's authors concluded it cannot be scoped safely once there is no session to scope it against, and anyone who built against the November 2025 experimental interface will need to migrate.

Authorization moves closer to standard OAuth practice

Six further proposals harden the authorization specification to match how OAuth 2.0 and OpenID Connect actually get deployed in production, according to the Model Context Protocol Blog. SEP-2468 requires clients to validate the iss parameter on authorization responses per RFC 9207, closing off a class of mix-up attack the specification's authors describe as more prevalent in MCP's deployment pattern - one client, potentially many servers - than in typical OAuth usage; a future version is expected to require clients to reject any response that omits iss, so authorization servers should begin supplying it now.

SEP-837 requires clients to declare their OpenID Connect application_type during dynamic client registration, avoiding a common failure mode where an authorization server defaults an unfamiliar client to a web application type and rejects its localhost redirect URI. SEP-2352 binds registered client credentials to the specific authorization server that issued them and requires re-registration when a protected resource migrates elsewhere. The specification also documents how to request refresh tokens from OpenID Connect-style authorization servers under SEP-2207, clarifies scope accumulation during step-up authentication under SEP-2350, and formalizes the .well-known discovery suffix under SEP-2351.

A formal deprecation policy and other changes

Three existing core features - Roots, Sampling, and structured Logging - move into deprecated status under a new feature lifecycle policy defined in SEP-2577, though the Model Context Protocol Blog is explicit that these remain annotation-only deprecations for now: the relevant methods, types, and capability flags continue to function in this release and in every specification version published within twelve months of it, and removing any of them will require a separate proposal filed under the same policy. Roots is expected to be replaced over time by tool parameters, resource URIs, or server-side configuration; Sampling by direct integration with large language model provider APIs; and Logging by stderr output for stdio transports or OpenTelemetry for structured observability.

Tool input and output schemas are lifted to the full JSON Schema 2020-12 standard under SEP-2106, gaining composition keywords such as oneOf, anyOf, and allOf, along with conditionals and references, while output schemas and the structuredContent field can now hold any JSON value rather than only an object. Implementations must not automatically dereference external reference URIs and must bound schema depth and validation time, guarding against maliciously deep or slow-to-validate schemas. Separately, SEP-2164 changes the error code returned for a missing resource from the MCP-specific value -32002 to the JSON-RPC standard value -32602, Invalid Params; any client matching on the literal -32002 value will need to update that check.

Three governance-focused proposals accompany the technical changes and are designed, according to the Model Context Protocol Blog, to prevent future revisions from requiring the kind of breaking change this release contains. The feature lifecycle policy gives every feature an Active, Deprecated, and Removed status with a minimum twelve-month gap between deprecation and the earliest possible removal. The Extensions framework lets new capabilities ship as opt-in additions and prove themselves there before, if ever, moving into the base specification. And a Standards Track proposal can no longer reach Final status until a matching test scenario lands in the protocol's conformance suite under SEP-2484 - the same suite that scores official software development kits under a newly introduced tier system.

What the roadmap said was coming

The specification released today follows a public roadmap that the Model Context Protocol Blog published on March 9, 2026, under lead maintainer David Soria Parra. That document ranked four priority areas for 2026 - transport evolution and scalability, agent communication, governance maturation, and enterprise readiness - and explicitly flagged the transport and session problems that this release now addresses. According to the roadmap post, running Streamable HTTP at scale had surfaced a consistent set of gaps: stateful sessions fighting with load balancers, horizontal scaling requiring workarounds, and no standard way for a registry or crawler to learn what a server does without first connecting to it. The document also previewed the Tasks primitive's move toward a more mature lifecycle, citing retry semantics for transiently failed tasks and expiry policies for completed results as open gaps, and it reorganized how the project plans its own work, shifting from release-driven milestones toward Working Groups organized around those priority areas.

Enterprise readiness was described in the roadmap as the least defined of the four priorities, deliberately left open for the people experiencing configuration, audit-trail, and single sign-on problems in production to help define the work themselves. Today's release delivers substantially on the transport and agent-communication priorities named in March; enterprise readiness and governance maturation remain areas the roadmap flagged as continuing beyond this release.

An early adopter's account

Daniel Jaye, whose LinkedIn profile identifies him in ad-martech and big data roles, published a post on LinkedIn describing the release as the protocol's most significant rewrite since launch and arguing that the advertising technology sector needed to pay attention. Jaye's post ties the specification changes to Aqfer, a data infrastructure company, describing Aqfer Fusion - the company's cloud-native processing framework, built in Go, according to the post - as having already adopted stateless, scale-out execution ahead of the protocol's own move in that direction. According to Jaye's post, Aqfer's AI agents and its governed Private AI Chat Environment, referred to in the post as PAICE, run inside customer virtual private clouds with MCP support, removing what the post frames as any need for Aqfer to retrofit its architecture around the specification's new statelessness, hardened authorization, and audited interface rendering.

Jaye's post also frames the MCP Apps extension as giving Aqfer a standards-backed, auditable way to render interactive interfaces inside its agent environment, with every action passing through what the post describes as the same review and consent path as a direct tool call. Jaye's post names the Extensions framework as the piece he finds most significant, describing a vision for an industry set of MCP extensions aimed at reducing friction across advertising and marketing technology. The post drew responses from commenters including Anthony Katsur, whose account is separately identified elsewhere as chief executive officer of the IAB Tech Lab, among more than thirty reactions and several comments discussing the architectural implications for smaller-scale deployments as well as enterprise ones.

Why this matters for advertising and marketing technology

MCP has moved rapidly from a general-purpose AI integration standard into infrastructure that a large share of the programmatic advertising sector now depends on. Anthropic introduced the protocol as an open standard in November 2024 and later donated it to the Linux Foundation, and PPC Land has tracked its spread across the sector closely since Google's Ads API team first floated an MCP server in July 2025, followed by Google's open-source release for the Ads API on October 7, 2025. Amazon Ads opened its own MCP server in closed beta on November 13, 2025 and moved it into open beta on February 2, 2026, while Meta opened its ad system to Claude and ChatGPT through MCP connectors on April 29, 2026, supporting write access from the first day of availability - a materially different governance posture than the read-only pattern Adform and Microsoft's Advertising MCP server have followed.

The stateless rework matters for a structural reason rather than a stylistic one. Platforms that expose MCP servers - a group that now includes Snap, Pinterest, DoubleVerify, Wistia, Pacvue, and FreeWheel - have generally had to run the sticky-session, shared-store infrastructure the new specification eliminates. Lowering that operational cost matters most for smaller publishers and vendors who lack the engineering resources that PPC Land's coverage of the Ad Context Protocol launch noted was already a barrier to participation.

The agent-to-agent pattern that AdRoll and PubMatic demonstrated on April 23, 2026, where a demand-side agent queries a supply-side agent's deal diagnostics directly without custom integration code, depends on servers being reachable and stateless enough to scale under real production load. So does the cross-platform coordination that the IAB Tech Lab's Agentic Advertising Management Protocols initiative, formally named on February 26, 2026, and its Agent Registry are built to support; every one of the ten entries the registry held as of March 11, 2026 was classified as an MCP server. Extensions becoming a formally governed track also answers a question PPC Land's coverage of AdCP has raised repeatedly: how an advertising-specific specification built on top of MCP relates to the base protocol's own evolution.

Authorization hardening carries its own weight in a sector where AI-agent access to advertiser data has already become a governance question. Usercentrics' acquisition of MCP Manager on January 14, 2026, timed to EU AI Act enforcement, signaled that consent frameworks were already extending into agentic workflows before this update tightened OAuth and OpenID Connect alignment. The mix-up-attack mitigation in SEP-2468 and the client-registration fix in SEP-837 address failure modes any deployment running token-based authorization against multiple servers could plausibly encounter.

Timeline

Summary

Who: The Model Context Protocol project, led by maintainers David Soria Parra and Den Delimarsky, published the specification. Daniel Jaye, an ad-martech industry figure, publicly connected the release to Aqfer's existing infrastructure choices.

What: The 2026-07-28 specification removes protocol-level sessions from MCP entirely, replacing sticky-session routing with self-contained requests, while formalizing Extensions as an independently versioned track and shipping MCP Apps and Tasks as the first two official extensions under that track.

When: The release candidate was published and locked on May 21, 2026, opening a ten-week validation window; the final specification shipped today, July 28, 2026.

Where: The specification is maintained by the Model Context Protocol project, now under Linux Foundation governance, and published through the Model Context Protocol Blog and the project's specification repository.

Why: Running the previous, session-based transport at scale had surfaced consistent operational problems - sticky sessions fighting with load balancers and no standard way to discover server capabilities without connecting first - that the project's March 2026 roadmap flagged as a top priority for the year, problems that carry direct cost implications for the advertising and marketing technology companies now running MCP servers at production scale.