What the 2026 stateless MCP protocol changes for clients

Start with the real meaning of stateless MCP

MCP 2026-07-28 removes protocol-level sessions rather than banning all durable application state. A client no longer opens a modern connection with `initialize` and `notifications/initialized`, and Streamable HTTP no longer uses `Mcp-Session-Id`. Instead, every request identifies its protocol version and client capabilities in `_meta`; HTTP mirrors required metadata in headers. List results such as `tools/list`, `resources/list`, and `prompts/list` no longer vary according to hidden connection state.

The practical client change is to make every call understandable on its own. Send the version and capabilities required for that request, keep ordinary business handles in explicit arguments, and never assume that a previous call on the same socket prepared the server. The official changelog specifically directs servers that need cross-call state to mint handles and receive them later as normal tool arguments.

Discovery also moves out of initialization. Modern servers must implement `server/discover`, which reports supported versions, capabilities, and identity. A client may call it before other work, or send a normal request and handle `UnsupportedProtocolVersionError`. This is a wire-era migration, not a reason to erase job IDs, OAuth grants, account history, or provider queues.

Removed

Implicit protocol sessionDo not infer capabilities, version, or request state from an earlier exchange on the same connection.

Added

Per-request metadata and server/discoverChoose a supported version explicitly and repeat the modern request envelope on each call.

Still valid

Explicit application handlesA generation ID or other server-minted handle remains appropriate when it is passed as an ordinary argument.

Preserve the evidence boundary while the ecosystem migrates

This page owns “mcp stateless protocol 2026”: the July 28 core changes, what a client must stop assuming, how transport recovery changes, and how explicit Studio generation handles fit the new model. It does not own a branded-client compatibility matrix, promise that every MCP host has rolled out 2026-07-28, or claim that protocol statelessness removes product retention and authorization responsibilities.

Community retrieval was used only to identify possible migration questions, not to substantiate protocol or product behavior. Partial and unavailable source lanes are recorded as evidence gaps in the accompanying research brief and are not interpreted as proof that discussion was absent. Automated review text and uncorroborated social summaries were excluded from the claim ledger.

The factual migration guidance therefore rests on the official July 28 changelog, current versioning, discovery, stdio, Streamable HTTP, and deprecation documentation. Product statements are limited to the public npm and UNPKG artifacts; protocol-era acceptance remains unverified because no reproducible transcript was retained. Recheck the protocol revision, SDK behavior, published package, and remote deployment before editorial review under the semiannual cadence.

Change transport assumptions, not only the version string

For Streamable HTTP, removing the session header is only one part of the migration. The old standalone GET stream and the resource subscribe and unsubscribe methods are replaced by `subscriptions/listen`, a long-lived POST response used for opted-in change notifications. Progress and message notifications that belong to one request remain on that request's response stream. A client should therefore separate request-scoped streaming from a deliberately opened subscription stream.

SSE resumption also changes. The modern transport removes event IDs, `Last-Event-ID`, and redelivery. If a response stream breaks, the specification requires the client to reissue the request with a new JSON-RPC request ID. Treat replay safety as a separate application-design review: before reissuing a side-effecting operation, consider whether the application offers an explicit idempotency control or a status-reconciliation path. The transport rule alone does not establish whether a particular Studio operation is safe to repeat.

On stdio, framing remains one UTF-8 JSON-RPC message per line. The important difference is the opening behavior: a dual-era client should probe with `server/discover`, treat a recognized modern error as modern evidence, and fall back to `initialize` only after a non-modern error or bounded silence. Cache the era for the server process instead of probing before every call.

HTTP notifications

subscriptions/listenUse one opted-in POST response stream for list and resource changes; keep request progress on the originating response.

Broken response stream

Reissue with a new request IDFirst classify whether replay is safe at the application layer; transport loss does not prove the operation never started.

stdio compatibility

Probe, classify, then pin the eraDo not key fallback to one guessed JSON-RPC error code.

Rebuild capability, result, and notification handling

Modern clients should stop treating capability negotiation as a one-time initialization artifact. Client capabilities travel with each request, and server capabilities are available through discovery. Optional extensions are identified in the capabilities `extensions` map. Core requests must still have a useful fallback or a clear error when only one side supports an extension.

Result parsing also needs a deliberate compatibility rule. In 2026-07-28, every result carries `resultType`: ordinary results use `complete`, while the new multi-round-trip pattern can return `input_required`. A client must interpret an older server's missing `resultType` as `complete`. List and resource methods also add `ttlMs` and `cacheScope`; those values are cache guidance, not permission to reuse private data across users or authorization contexts.

Remove calls that no longer exist in the modern core. `ping`, `logging/setLevel`, and `notifications/roots/list_changed` are gone. Roots, Sampling, and Logging remain documented but are deprecated for new implementations, and HTTP+SSE is deprecated in favor of Streamable HTTP. Logging level now travels per request in `_meta`, and the changelog directs stdio servers toward `stderr` and implementations toward OpenTelemetry for observability.

Legacy result

Missing resultType means completePreserve this compatibility rule instead of rejecting every response from an initialization-era server.

Modern cache hint

ttlMs plus cacheScopePartition private cache entries by the relevant identity and authorization boundary.

Removed utility calls

ping and logging/setLevelDo not carry connection-lifecycle health checks or session log settings into the stateless wire.

Keep privacy and application state explicit

Stateless protocol processing does not mean a server stores nothing. It means one MCP request cannot depend on invisible protocol state established by a previous request. Authentication systems can still validate bearer tokens, generation services can still retain jobs, and a tool can still accept a handle that authorizes or identifies the next application operation. Document those layers separately so “stateless MCP” is not rewritten as a zero-retention or zero-logging promise.

OfflineCreator's published package illustrates that distinction without requiring a production call. Its generation tools pass `generationId` explicitly to status, wait, download, and eligible cancellation operations. That handle names Studio application state; it is not `Mcp-Session-Id`, and it does not depend on the same stdio process or HTTP connection remaining open. A migrated client should preserve the handle after a transport failure and reconcile status before starting replacement work.

Per-request capabilities also deserve privacy review. They expose what the client says it can do on each call, while `clientInfo` and `serverInfo` provide implementation identity. Treat self-reported identity as display and diagnostic data, not an authorization decision. Keep account authorization, ownership checks, and scope enforcement independent from protocol discovery.

Protocol state

Must not be inferred across callsVersion, capabilities, and request behavior come from the current request.

Application state

May persist behind explicit handlesRetention, access control, and deletion need their own documented product rules.

Identity metadata

Diagnostic, not authorizationDo not grant access because a client or server self-reports a familiar name.

Route the next question to the right owner

Use the learning center for the broader MCP image-generation architecture. Use the client-schema page when the migration problem is how one named client stores a URL, command, headers, or transport type. Use the privacy-myths page when “stateless” is being confused with claims about prompt storage, provider processing, logs, or local execution. This page owns the 2026 protocol delta and migration decisions, not every client configuration or product data-flow claim.