MCP Just Went Stateless: What It Means for Your Agentforce Connectors

What changed in the MCP 2026-07-28 spec?

The Model Context Protocol's 2026-07-28 release, published as final on July 28, replaces the stateful bidirectional protocol with a stateless request/response model. It drops the initialize/initialized handshake and session IDs, makes requests self-describing, and adds header-based routing, cacheable lists, and OAuth 2.0/OIDC-aligned authorization. All four Tier 1 SDKs ship it now.

Every request now carries its own context. The old flow opened a session, negotiated capabilities through initialize, then held that session across calls. The new flow sends a self-describing request that any server instance can answer without a prior handshake. Routing moves to headers (Mcp-Method, Mcp-Name), list results become cacheable through ttlMs and cacheScope, and mid-call confirmations use Multi Round-Trip Requests instead of a persistent stream. Apps and Tasks are versioned extensions now, not part of the core.

What's the actual difference between stateful and stateless MCP?

Stateful MCP kept a live session open: the client introduced itself once through a handshake, and every later request assumed the server still remembered that setup. Stateless MCP drops the memory. Each request carries its own context, so any server instance can answer it cold. Same shift as server-side sessions versus JWTs.

If you have built a web app, you already know this trade-off under a different name. Server-side sessions store login state in memory on one box; the browser holds a session cookie, and every request has to come back to the box that remembers you. JWTs flip that: the token itself carries who you are and what you can do, so any server can validate it without looking anything up. Stateful MCP was the session-cookie model. Stateless MCP is the JWT model, applied to the whole protocol, not just auth.

Concretely, in the old spec a client sent initialize, the server replied with its capabilities, the client sent initialized, and only then could tool calls flow, all pinned to one Mcp-Session-Id. In the new spec a tool call arrives with its method and target in headers and everything it needs in the body, and it gets answered. No opening round-trip, no session to keep alive.

Is it a big difference? Depends on where you stand. For the logic inside a single tool, the handler that reads a Data 360 record or posts to Slack, almost nothing changes; you write the same function. The difference is entirely operational. Statefulness was never about your code, it was about which server instance had to receive the request. Removing it changes how you deploy and scale, not what your tools do. So it is a small change to write and a large change to run, which is exactly the kind of shift that looks minor in the changelog and reshapes your infrastructure diagram.

Why does a stateless MCP matter for Agentforce connectors?

Stateless requests let an MCP server sit behind a plain round-robin load balancer or run on serverless and edge, because no single instance owns a session. For Salesforce, that removes the sticky-session constraint on connectors wiring Slackbot, Agentforce tool calls, Tableau, and Data 360, so you scale horizontally without session affinity.

With session IDs, any request had to land on the exact instance that opened the session. That forces sticky routing, an in-memory session store, or a shared cache, and it complicates blue-green deploys because draining an instance kills live sessions. Stateless removes that. You can autoscale the connector on Heroku, a container platform, or a Function, and a cold start no longer means re-running a handshake. For a connector fronting an Agentforce tool call under bursty load, that is the difference between provisioning for peak and scaling on demand.

What's deprecated, and how long do you have?

The spec deprecates session IDs, the legacy HTTP+SSE transport, Dynamic Client Registration, and the Roots, Sampling, and Logging features. Each gets a deprecation offramp of at least 12 months. Nothing breaks on July 28, but any custom connector using those features needs a migration plan inside that window, not a same-week rewrite.

The offramp length is the number to plan against. If your Agentforce or Data 360 integration runs a custom MCP server, inventory it against the deprecation list first. HTTP+SSE is the transport most connectors actually use for streaming, so check whether you depend on it for long tool calls. Roots, Sampling, and Logging move out of core; if you built anything on Sampling, where the server asks the client to run a model call, that pattern has to change. Twelve months covers a quarter of planning plus a controlled rollout across sandboxes, which is the realistic shape of the work against a large org carrying legacy connectors.

How does the OAuth/OIDC hardening map to your identity provider?

The 2026-07-28 spec aligns authorization to production OAuth 2.0/OIDC: RFC 9207 issuer validation on every token, and a shift from Dynamic Client Registration to Client ID Metadata Documents. That maps cleanly to Entra or Okta as the connector's identity provider, so you validate the issuer instead of registering clients at runtime.

DCR let clients register themselves at runtime, which is convenient and a governance problem in a regulated org. Client ID Metadata Documents flip it: the client publishes its metadata at a known URL and the server reads it, so identity is declarative and auditable. RFC 9207 adds the issuer identifier to the authorization response, so a client cannot be tricked into accepting a token minted by the wrong issuer. If your connectors authenticate against Entra or Okta, standardize on this pattern now. Anthropic's Claude rollout shows the reference shape: enterprise-managed auth provisioned through the identity provider, observability dashboards for published connectors, and private MCP tunnels that avoid public endpoints, across a directory Anthropic puts at 950+ servers.

What should you do this quarter?

Inventory every custom MCP connector in your Salesforce integrations, flag any use of session IDs, HTTP+SSE, DCR, Roots, Sampling, or Logging, and confirm which Tier 1 SDK version you are pinned to. Then stage a stateless-plus-CIMD migration across sandboxes inside the 12-month offramp, before it turns urgent.

Concrete first steps:

1. Pin the SDK. TypeScript, Python, Go, and C# all ship the new spec. Record your current version and the target version.
2. Map identity. Decide on Client ID Metadata Documents against Entra or Okta, and add RFC 9207 issuer checks to token validation.
3. Test streaming. If a tool call streams over HTTP+SSE, prototype the Multi Round-Trip Request replacement before the transport is gone.
4. Load-test stateless. Drop session affinity and confirm the connector answers correctly from any instance behind the load balancer.

The spec is final and the SDKs already implement it, so the clock on the offramp is running from now.