MCP 2026-07-28: the stateless core and its compatibility boundaries

What it is

Status as of 25 October 2026. MCP revision 2026-07-28, announced on 28 July 2026, changes the protocol lifecycle. Re-check the versioned changelog, compatibility rules, extension specifications and deprecation registry before upgrading; the release announcement is an overview, not the complete wire contract.

The revision removes initialize, notifications/initialized and protocol-level HTTP sessions, including Mcp-Session-Id. Each request declares its version and client capabilities in _meta. Servers must implement server/discover; clients may call it for advance discovery or send another request directly. “Optional discovery” describes the client's choice, not a server exemption. These distinctions follow the versioning specification.

Why it matters

Connection establishment no longer supplies context for subsequent operations. A deployment must distinguish transport state from application state, such as a long-running job. Existing clients using the earlier handshake need a compatibility path; changing only a version string does not convert their messages.

The release announcement describes the operational motivation: requests can reach different server instances without session affinity. That benefit does not remove the application's responsibility for storing its own durable state.

How to apply

• Inventory lifecycle assumptions. Replace implicit connection context with request metadata. For state spanning calls, expose explicit application handles as tool arguments. Keep a separate legacy path when supporting earlier clients.
• Handle intermediate results. Multi Round-Trip Requests replace independent server-initiated requests. An input_required result asks for input; the client repeats the original operation with inputResponses. Ordinary results use resultType: "complete". Earlier-version responses lacking the field are treated as complete.
• Update HTTP integration. Implement method and applicable name headers, and use subscriptions/listen for opted-in change notifications. Request progress remains on its originating response stream. SSE resumption and redelivery are removed: recovery requires a new request with a new ID, with application-level safeguards against repeating side effects.
• Implement cache metadata. The changelog requires ttlMs and cacheScope on specified list and resource results. Treat freshness and permission to share as separate decisions; neither means that every response is publicly cacheable.
• Declare extensions explicitly. Extensions advertise support through capability maps, are disabled by default, and require developer opt-in. Tasks move from the experimental core into an official extension. Confirm support on both sides instead of inferring it from the core version.
• Track feature lifecycles. Active, Deprecated and Removed are separate states. The normal minimum deprecation window is twelve months; the policy permits an approved security exception with at least ninety days. Check the particular feature's record before scheduling removal.

Pitfalls

Do not interpret statelessness as prohibiting streaming responses or durable application records. Do not assume every extension ships with every conforming SDK: extension support is optional and evolves separately. Finally, the removal of the old handshake in this revision does not authorize deleting compatibility behavior while older clients still depend on it.