MCP 2026-07-28 explained: what the stateless protocol means for server builders

The Model Context Protocol (MCP) is the open standard that lets AI applications such as coding assistants and chat clients connect to external tools and data through small "servers". If you have built or deployed an MCP server in the last year, the specification revision dated 2026-07-28 is the most significant change since the protocol appeared: it removes the connection handshake and protocol-level sessions and makes every request self-contained.

This explainer covers what MCP is, what changed from the previous revision (2025-11-25), what was deprecated, and what it means in practice for teams running MCP servers, especially remote ones behind load balancers. It also explains the SDK situation for TypeScript developers, where the package you install now determines which protocol revision you speak.

All details come from the official specification and changelog at modelcontextprotocol.io and the npm registry, checked on 7 October 2026.

MCP in one paragraph

MCP uses JSON-RPC 2.0 messages between three roles. A host is the AI application the user works in. Inside it, each client is a connector with a one-to-one relationship to a single server. Servers offer three kinds of features: tools (functions for the model to execute), resources (context and data) and prompts (templated messages and workflows). The specification describes its inspiration as the Language Server Protocol: one standard so that any AI host can use any compatible server, instead of every vendor building its own plug-in format.

The big change: MCP is now stateless

Earlier revisions began every connection with an initialize request and an notifications/initialized reply, after which the session carried the negotiated version and capabilities. Over HTTP, that state was tied together with an Mcp-Session-Id header. The architecture page of the new revision states it directly: "MCP is a stateless protocol: every request is self-contained and carries its own protocol version and capabilities."

The changelog lists the concrete changes:

• No handshake. The initialize/notifications/initialized exchange is removed. Every request carries its protocol version and client capabilities in _meta (io.modelcontextprotocol/protocolVersion and io.modelcontextprotocol/clientCapabilities). Clients should identify themselves per request, and servers should identify themselves in each result's _meta.
• No protocol sessions. The Mcp-Session-Id header is gone from Streamable HTTP, and list endpoints such as tools/list no longer vary per connection. Servers that need state across calls should mint explicit handles and pass them as ordinary tool arguments.
• New server/discover. Servers must implement it to advertise supported versions, capabilities and identity. Clients may call it first, or use it as a compatibility probe over stdio.
• One subscription stream. The HTTP GET endpoint and resources/subscribe/unsubscribe are replaced by subscriptions/listen, a single long-lived POST response stream for change notifications the client opts in to.
• Multi round-trip requests. Servers no longer send requests to clients (such as sampling/createMessage or elicitation/create). Instead a server returns an InputRequiredResult, and the client retries the original request with the requested input. All results now carry a resultType of "complete" or "input_required".
• No resumable streams. SSE event IDs and the Last-Event-ID header are removed; if a response stream breaks, the client must re-issue the request with a new ID.
• Removed methods. ping, logging/setLevel and notifications/roots/list_changed are gone. Log level is set per request in _meta.

Transports after the change

Two standard transports remain. stdio is newline-delimited JSON-RPC over the standard streams of a subprocess the client launches; it suits local tools. Streamable HTTP sends each message as an HTTP POST to a single MCP endpoint, with replies arriving as a JSON object or a request-scoped SSE stream. Standard request headers Mcp-Method and Mcp-Name are now required on Streamable HTTP POSTs, mirroring body fields so that proxies and gateways can route and inspect traffic without parsing JSON. The body stays the source of truth.

Topic	2025-11-25	2026-07-28
Connection setup	initialize handshake	None; metadata on every request; optional server/discover
HTTP sessions	Mcp-Session-Id header	Removed; explicit handles in tool arguments
Server-to-client requests	Sampling, elicitation, roots sent as requests	InputRequiredResult and client retry
Notifications	HTTP GET stream, resources/subscribe	subscriptions/listen
Stream resumption	Last-Event-ID	Removed; re-issue the request
Long-running tasks	Experimental, in core	Official extension io.modelcontextprotocol/tasks

What is deprecated

The revision also adopts a formal feature lifecycle with a minimum twelve-month deprecation window. Deprecated features still work but new implementations should not adopt them:

• Roots, Sampling and Logging. Suggested migrations: pass directories via tool parameters or configuration instead of Roots, call LLM provider APIs directly instead of Sampling, and log to stderr or OpenTelemetry instead of Logging.
• The old HTTP+SSE transport, deprecated since 2025-03-26, is formally classified as deprecated; migrate to Streamable HTTP.
• OAuth Dynamic Client Registration is deprecated as a registration mechanism in favour of Client ID Metadata Documents, though it remains for compatibility.

Smaller changes worth a look if you maintain a server: list and read results must include ttlMs and cacheScope caching hints; tool schemas may use any JSON Schema 2020-12 keyword; tools should be returned from tools/list in a deterministic order (which also helps LLM prompt-cache hit rates); and the "resource not found" error code changes from -32002 to -32602.

Why the change helps small teams

A stateful protocol is awkward to host. With sessions, every request from a client had to reach the server instance holding that session, which meant sticky load balancing or a shared session store, and a restart dropped every connected client. With self-contained requests, a remote MCP server behaves like any other stateless HTTP API: you can run several instances behind an ordinary load balancer, deploy to serverless platforms, scale to zero and restart freely. Gateways can route on the Mcp-Method header. The cost is that any state you genuinely need, such as a shopping basket or a long-running job, must now be explicit: a handle your server mints, stores and validates.

The SDK situation for TypeScript developers

This is where teams are most likely to trip. On npm, @modelcontextprotocol/sdk (latest 1.32.1) is now the v1.x maintenance line. Its README says it implements the spec up to 2025-11-25 and that support for 2026-07-28 is not planned for v1.x. Support for the new revision lives in v2, released on 2026-07-27, which ships as separate packages: @modelcontextprotocol/server and @modelcontextprotocol/client (both at 2.3.1 on 5 October 2026). The v1 line continues to receive bug fixes and security updates for at least six months after the v2 release.

In practice:

1. Check which package your server imports. If it is @modelcontextprotocol/sdk, you are speaking 2025-11-25.
2. Read the official v2 migration guide before upgrading, and test against the hosts your users actually run, since hosts and servers on different eras must fall back as described in the versioning section of the spec.
3. Remove any reliance on session state, server-initiated sampling or roots as part of the move.

Security still sits with the host and server

The specification is explicit that MCP itself cannot enforce its security principles. It requires hosts to obtain explicit user consent before invoking any tool or exposing user data to servers, and it warns that tool descriptions and annotations should be treated as untrusted unless they come from a trusted server. If you run MCP servers for your business, keep doing the basics: authenticate remote servers, scope credentials to the minimum, review third-party servers before installing them, and log tool calls.

Upgrade checklist for an existing server

1. Inventory your state. Search the code for anything stored per session: authenticated user context, open cursors, caches keyed by session ID. Each item needs an explicit, server-minted handle or must be recomputed per request.
2. Implement server/discover. It is mandatory in the new revision and is how clients learn your supported versions and capabilities.
3. Replace server-initiated requests. If a tool currently asks the user for confirmation through elicitation or calls the model through sampling, rework it to return an InputRequiredResult and accept the answer on the retried request. Sampling is deprecated, so consider calling your LLM provider directly.
4. Move notifications to subscriptions/listen. Drop the HTTP GET stream and resource subscribe methods.
5. Add caching hints. Return ttlMs and cacheScope on list and read results, and sort your tool list deterministically.
6. Update error codes. Resource-not-found is now -32602.
7. Test against real hosts. Confirm the clients your users run can talk to the new server, and keep the old version deployed until they can.

Summary

MCP 2026-07-28 trades connection state for self-contained requests. That makes remote servers far easier to host and scale, but it is a breaking change: no handshake, no sessions, no server-initiated requests, and a new SDK package line for TypeScript. If you maintain a server, plan the move to the v2 packages now and use the v1 support window to test it.