MCP 2026-07-28: What the Stateless Protocol Means for B2B Agent Deployments

Why this release changes the deployment math

The Model Context Protocol (MCP) is an open standard for connecting AI agents to external systems. On July 28, 2026, it shipped as a final specification — the largest revision since launch. The protocol layer is now stateless, first-class extensions are introduced, and three features that added complexity without earning their keep in production are deprecated. All four Tier 1 SDKs (TypeScript, Python, Go, C#) speak the 2026-07-28 protocol version as of publication day, with migration guides for each. Roots, Sampling, and Logging are annotation-only for 12 months, followed by removal in a separate standards process — the 1,227 servers still using the deprecated HTTP+SSE transport are the population most affected by the migration window.

For teams deploying MCP servers behind B2B agent systems, the practical impact is concrete: you no longer need sticky sessions, shared session stores, or session-aware load balancers. State that an agent needs across multiple tool calls becomes an explicit handle — visible to the model, auditable in logs, and cacheable by intermediaries. This article walks through the changes that matter for B2B deployments and how they map to the MCP module pattern we already ship.

The stateless protocol layer

The headline change: the initialize / initialized handshake and the Mcp-Session-Id header are removed. Requests are now self-contained. Protocol version, client info, and capabilities travel in _meta on every request, not in a negotiated session that the server must remember.

What this eliminates in a B2B deployment:

• Sticky-session load balancers. Remote MCP servers can sit behind plain round-robin load balancers. Any server instance can handle any request because no server-side state is required to interpret it.
• Shared session stores. If you scale horizontally today, every MCP server instance needs access to the same session state — typically Redis or a database. The stateless protocol removes that dependency.
• Session-replay infrastructure. When a session drops mid-workflow, the client must re-initialize and re-establish context. The stateless protocol has no session to drop; every request carries what it needs.

The deployment shape becomes simpler: a pool of stateless MCP server instances behind a load balancer, with no shared state tier between them. This is the same shape as any stateless HTTP API — battle-tested, observable, and cheap to scale.

The explicit-handle pattern for stateful workflows

Stateless does not mean state disappears. Workflows that span multiple tool calls — an RFQ intake, a quote negotiation, an availability hold — still need continuity. The final specification replaces hidden session state with the explicit-handle pattern: a tool mints a handle (an order_id, a quote_id, a basket_id) and the model passes it back as an ordinary argument on subsequent calls.

This is a meaningful shift for B2B deployments for three reasons.

State is visible to the model. Today, session state lives in transport metadata the LLM never sees. With explicit handles, the model holds and references the handle in its reasoning. When the model calls get_quote(quote_id="q-7f3a"), it knows which quote it is operating on. This improves tool-selection accuracy in multi-step workflows.

State is auditable in logs. Every request carries its handle in the request body, not in a header the application logger strips. An audit trail can reconstruct the full workflow state at any point by reading the request arguments — no correlation against session-store logs is needed.

State is cacheable by intermediaries. Because the handle is part of the request, a gateway or cache layer can key on it. List and resource results carry ttlMs and cacheScope fields, so a catalog query with a stable handle can be served from cache without hitting the upstream system.

How this maps to an RFQ workflow

Consider a quoting workflow that runs across five tool calls: create request, search catalog, generate quote, hold availability, apply pricing tier. Under the session-based protocol, these five calls share a server-side session. Under the explicit-handle pattern:

1. create_request(buyer_id, line_items) → request_id="r-1042"
2. search_catalog(request_id="r-1042", query="industrial pump 220V")
3. generate_quote(request_id="r-1042", supplier_ids=["s-12", "s-19"])
       → quote_id="q-7f3a"
4. hold_availability(quote_id="q-7f3a", hold_duration="48h")
       → hold_id="h-3391"
5. apply_pricing_tier(quote_id="q-7f3a", tier="volume-3")

Every call carries the handle it needs. No server remembers anything between calls. If the load balancer routes call 4 to a different instance than call 3, it still works — the handle is in the request. If the audit team needs to reconstruct this workflow a week later, the handles in the request arguments tell the full story.

Extensions: first-class and independently versioned

The final specification introduces extensions as a first-class concept. Extensions get reverse-DNS identifiers (e.g., com.example.workflow), own ext-* repositories, have delegated maintainers, and version independently of the core protocol.

The first two extensions are concrete:

• MCP Apps — server-rendered HTML UIs delivered in sandboxed iframes. An MCP server can ship a UI that a client renders, enabling human-in-the-loop approval surfaces without the client building a custom frontend.
• Tasks — long-running work with task handles. A tool can return a task handle immediately and the client polls for completion, rather than holding a connection open for minutes.

For B2B deployments, MCP Apps matter where a human must approve a transaction before the agent proceeds — a purchase order above a threshold, a quote with a non-standard discount. The approval surface can ship with the MCP module rather than requiring a separate frontend. Tasks matter for workflows that exceed a single request timeout: a supplier quote that takes 90 seconds to generate, a catalog sync that runs for minutes.

Deprecations: Roots, Sampling, Logging

Three features are deprecated (annotation-only for 12 months; removal requires a separate standards process):

• Roots → replaced by tool parameters and resource URIs. Roots were a way for clients to tell servers about filesystem locations; the same intent is now expressed as arguments to tools that read files.
• Sampling → replaced by direct LLM provider API integration. Servers that need LLM calls make them directly to the provider, rather than requesting the client to perform a sampling round-trip.
• Logging → replaced by stderr and OpenTelemetry. Server logging moves to standard process output and distributed tracing, not the MCP logging channel.

The deprecation of Logging is the most relevant for B2B deployments. The audit-logging pattern — where every tool call logs request, response, latency, and outcome — now aligns with OpenTelemetry rather than a protocol-specific logging channel. This means MCP server logs integrate with existing observability pipelines (Datadog, CloudWatch, Honeycomb) without a custom transport.

Routable, cacheable, traceable

Three additions that affect production operations:

• Mcp-Method and Mcp-Name headers enable gateway routing without body inspection. A gateway can route by method and tool name at the header level — no JSON parsing in the routing layer.
• ttlMs and cacheScope on list/resource results give intermediaries a standard caching contract. A catalog list response can declare a 5-minute TTL, and any gateway in the path can honor it.
• W3C Trace Context propagation is documented for OpenTelemetry compatibility. A trace started by the agent client propagates through the MCP server and into upstream system calls, so a single RFQ workflow appears as one trace across every system it touches.

For a B2B deployment running MCP servers for NetSuite, HubSpot, and a supplier catalog, this means: a gateway can route by tool name without parsing bodies, cache catalog responses for a declared TTL, and trace a single quote request from agent to ERP to supplier API in one span tree.

Authorization hardening for the one-to-many shape

The final specification improves OAuth and OpenID Connect for the deployment shape that B2B agent systems actually use: one client (the agent) connecting to many servers (NetSuite, HubSpot, BigCommerce, a supplier catalog). Token refresh, scope management, and multi-server credential handling are addressed in the spec rather than left to each integration to solve independently.

This matters because B2B agent systems do not connect to one system. A typical RFQ agent connects to an ERP (NetSuite), a CRM (HubSpot), an ecommerce platform (BigCommerce), and two or three supplier catalogs — each with its own OAuth flow, token lifetime, and scope set. The protocol now provides a standard pattern for managing that complexity, rather than each MCP module implementing its own credential lifecycle.

Update — 2026-08-06: Terraform MCP CVE-2026-16496 (CVSS 10.0) — the stateless thesis validated in production

HashiCorp patched CVE-2026-16496 (CVSS 10.0) in Terraform MCP Server before version 1.1.0 — the first maximum-severity CVE in the MCP ecosystem. The vulnerability is an authorization bypass in the streamable-HTTP stateful transport mode: a user who obtains another user's MCP session ID can have their tool calls executed using that user's Terraform credentials. HashiCorp also patched CVE-2026-16498 (tenant isolation break) and CVE-2026-14869 (SSRF) in the same release. (The Hacker News, SentinelOne vulnerability database)

This CVE is the first production evidence that the stateful transport mode is a security liability, not just an operational complexity — and it validates the core thesis of this article. The stateless protocol layer the July 28 final specification introduced exists precisely to eliminate the server-side session state that this attack exploits. The attack vector (session-ID theft leading to credential reuse) exists only because the server holds a session state that an attacker can steal and reuse. A stateless server has no session to steal. The explicit-handle pattern this article describes — where stateful workflows mint handles that travel in the request body, not in a server-side session — is the architecture that closes this vulnerability class. The vulnerability affects only the stateful streamable-HTTP transport mode; the stateless protocol core is not affected.

For B2B deployments, the implication is direct: if your MCP servers run stateful streamable-HTTP with Mcp-Session-Id, they carry the session-hijacking attack surface that CVE-2026-16496 exploits. Migrating to the stateless protocol core (Control 1 in the MCP Security Hardening Checklist) eliminates the attack surface at the architecture level, not the patch level. The 12-month SSE deprecation window is now a security deadline, not just an operational one.

Security: three new attack surfaces and a defense-in-depth data point

The stateless redesign introduces three new attack surfaces identified by backslash.security in their same-day analysis of the final specification:

• Handle hijacking. Explicit handles replace server-side session state, but a handle is an ordinary argument. If the handle space is predictable or the transport lacks integrity protection, an attacker who observes or guesses a handle can inject it into their own requests — impersonating the workflow owner. The fix is cryptographic handle generation (random, unguessable) and binding handles to the authenticated caller, not just the request body.
• Filesystem scope gap. The deprecation of Roots removes the client-side filesystem boundary declaration. Tools that read files now receive paths as arguments, but without the Roots boundary, a tool may access filesystem locations the client never intended to expose. The fix is per-tool path validation against an explicit allowlist, not reliance on a protocol-level boundary that no longer exists.
• MCP Apps HTML rendering. The MCP Apps extension lets servers ship HTML UIs in sandboxed iframes. The sandbox is a security boundary, but the HTML content comes from the server — a compromised or malicious MCP server can ship UI that attempts to escape the sandbox or phish the user. The fix is treating MCP Apps HTML as untrusted content: strict Content Security Policy, no same-origin access, and user confirmation before rendering app surfaces from new servers.

A defense-in-depth data point: Claude Opus 5 with Auto Mode enabled achieved a 0% browser-based prompt-injection attack success rate across 129 test scenarios — the first concrete data point showing browser-agent prompt injection can be reduced to zero. Auto Mode combines an input-layer prompt-injection probe with an output-layer action classifier. For stateless MCP deployments where browser agents call MCP tools, the input-scanning + task-blocking pattern is a concrete implementation of defense-in-depth that the protocol's stateless design makes easier to enforce: every request is self-contained, so the probe and classifier operate on each request independently, without session state to corrupt.

What changes for existing MCP modules

If you already ship MCP modules — for example, the 38-tool RFQ processor pattern where tools are registered through MCP_CONFIGURATION and domain mixins compose over a shared GraphQL client — the stateless protocol changes the deployment, not the module code.

The module's tool registration, input/output schemas, rate limiting, and audit logging stay the same. What changes:

• No session initialization on startup. The module does not participate in an initialize handshake. It receives requests with _meta carrying protocol version and capabilities, and responds.
• Stateful tools mint handles. If a tool today relies on a server-side session to track a multi-step workflow, it should mint an explicit handle and return it. The client passes it back on the next call. For an RFQ processor, the request_id, quote_id, and hold_id are already the handles — the pattern is natural to the domain.
• Logging moves to OpenTelemetry. If the module logs through the MCP logging channel, migrate to stderr and OpenTelemetry spans. The audit content (request, response, latency, outcome) stays; the transport changes.
• Caching is declarative. List and resource endpoints can declare ttlMs and cacheScope on their responses, letting intermediaries cache without guessing.

The bottom line for B2B teams

The stateless protocol reduces the infrastructure an MCP-based agent deployment requires. You trade sticky sessions and shared session stores for explicit handles in request arguments — a trade that makes the system simpler to scale, easier to audit, and more observable in standard tooling.

If your team is scoping an MCP-based agent deployment, the July 28 final specification is the version to target. Designing for explicit handles from the start avoids the migration from session-based state later. The 12-month deprecation window for Roots, Sampling, Logging, and HTTP+SSE means teams running the old transport should plan the migration now — the 1,227 servers still on deprecated-SSE are the population most affected.

Update — 2026-08-13: MCP Server Cards — the proposed discovery standard

WorkOS's 2026 roadmap proposes a standard for exposing MCP server metadata via .well-known URLs — so browsers, crawlers, and AI agents can discover server capabilities without prior configuration. The proposal is the MCP equivalent of A2A's .well-known/agent-card.json (which the A2A articles already use for agent-to-agent discovery). CData estimates 30% of enterprise application vendors will launch MCP servers in 2026. ServiceNow shipped a GA MCP Server in the same window.

For B2B agent deployments, MCP Server Cards address a discovery gap that the stateless protocol does not solve: the protocol defines how an agent talks to a server, but not how an agent finds the server in the first place. Today, MCP server URLs and capability lists are configured manually — each agent deployment includes a hand-maintained list of server endpoints and their tool schemas. The .well-known proposal would let an agent fetch https://api.netsuite.com/.well-known/mcp-server-card.json and discover the available tools, auth requirements, and protocol version without manual configuration.

The stateless protocol and Server Cards are complementary: the stateless protocol simplified the session layer (removing sticky sessions, making state explicit as handles), and Server Cards would simplify the discovery layer (removing manual server configuration, making capabilities discoverable). For a B2B team scoping an MCP deployment, the combined effect is that the infrastructure burden shifts from configuration (manual server lists) to standards (well-known discovery + stateless transport). The 12-month deprecation window for Roots, Sampling, and Logging aligns with the expected timeline for the Server Cards proposal — teams migrating to the 2026-07-28 protocol should design their server endpoints with .well-known discovery in mind, even before the standard is final.

Update — 2026-08-23: MCP New Roadmap — five priority areas for the next specification cycle

On August 22, 2026, the MCP maintainers published a new roadmap — the first update since March 2026. The roadmap defines five priority areas for the next specification cycle, and three of them directly extend the stateless protocol this article covers:

1. HTTP-native transport unification — the 2026-07-28 release made remote MCP servers "no different from any other HTTP workload." The roadmap extends this to local servers speaking Streamable HTTP over stdio, unifying on one transport model. For B2B deployments, this means the STDIO-vs-HTTP transport choice described in this article's deployment section converges: local servers will speak the same Streamable HTTP protocol as remote servers, just over a local pipe instead of a network socket. The stateless core remains the foundation — the roadmap extends the transport surface, not the session model.

2. Agent identity and enterprise-ready security — the roadmap is explicit: MCP authorization today is "built around a person approving access in a browser," but "more and more of the callers are agents running as cloud workloads with their own identity, acting on a user who isn't present, or delegating narrower authority to sub-agents." The path forward includes DPoP (RFC 9449) to bind OAuth tokens to a client-held key, Workload Identity Federation via the IETF WIMSE working group for workload-level identity, and the Enterprise-Managed Authorization (EMA) extension for central assignment and revocation. For the stateless protocol, this is the identity layer that complements the explicit-handle pattern: handles make state explicit in the request; agent identity makes the caller explicit in the credential.

3. Improved primitives — progressive tool discovery — the roadmap addresses the "hundred tools" problem: "Connecting to a server with a hundred tools means the model pays for that entire surface before the user has asked a single question, and tool selection tends to get worse as the list grows." The 2026-07-28 spec already provides server/discover RPC and tools/list with ttlMs and cacheScope cache hints. The roadmap's progressive discovery effort formalizes the pattern where a server offers a small entry point and reveals more of its catalog as the conversation narrows — keeping the context window lean and tool selection accurate.

The remaining two priority areas — agentic messaging primitives (server-initiated events, Tasks extension maturation via SEP-2663) and improved SDK developer experience (conformance testing, documentation) — are forward-looking and do not change the stateless protocol's deployment shape. The Server Card Working Group continues developing .well-known metadata conventions.

For B2B teams, the roadmap validates the stateless deployment architecture this article describes: the stateless HTTP core shipped on July 28, and the roadmap extends it rather than replacing it. The agent identity priority is the one to watch — it addresses the exact gap (API keys and long-lived tokens) that the MCP Security Hardening Checklist and governance checklist have been flagging. See the MCP Tutorial for a hands-on production walkthrough covering the roadmap's enterprise priorities.

---

A distributor running NetSuite, BigCommerce, and three supplier catalogs gets an agent that receives an RFQ by email or portal, resolves products and substitutes against the catalog graph, prices per customer tier, holds stock with an expiry, and writes the accepted quote back to NetSuite — with every step logged.

Request a scoped build. One-week discovery. You get a system inventory, workflow map, and fixed scope — whether or not you build with us.