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 ships its largest revision since launch — a release candidate that makes the protocol layer stateless, introduces first-class extensions, and deprecates three features that added complexity without earning their keep in production.

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 release candidate 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 release candidate 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 release candidate 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.

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 release candidate is the version to target. Designing for explicit handles from the start avoids the migration from session-based state later.

---

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. That build is Phase 2-3 of the four-step method and is typically live in 5-8 weeks.

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