What changed in MCP 2026-07-28?

The revision removes protocol-level sessions, Mcp-Session-Id, and the initialize/initialized handshake. Requests carry protocol version and client capabilities in _meta.

How should MCP servers preserve cross-call state?

The changelog says servers that need cross-call state should use explicit server-minted handles passed as ordinary tool arguments.

Can old and new MCP clients be migrated at once?

A staged compatibility rollout is safer. Inventory current SDK and transport behavior, test discovery and version errors, canary the new path, and retain a measured rollback.

AI Agent - Aug 6, 2026

MCP 2026-07-28 Stateless Migration Guide

Quick answer

The MCP 2026-07-28 revision makes the protocol core stateless. It removes protocol-level sessions, Mcp-Session-Id, and the initialize / notifications/initialized handshake. Each request carries protocol version and client capabilities in _meta; clients should send client identity, and servers should return server identity.

This removes transport session pinning. It does not remove application state: long-running work, authorization, idempotency, and cross-call context still need explicit designs.

Legacy vs stateless request model

Boundary	2025-11-25 style	2026-07-28 revision
Startup	`initialize` then `notifications/initialized`	No protocol handshake
Session	`Mcp-Session-Id` on later requests	No protocol-level session
Version and capabilities	Negotiated once	Sent per request in `_meta`
Server identity	Initialization response	Server result `_meta`
Cross-call state	Often attached to session	Explicit server-minted handle in ordinary arguments
Up-front discovery	Initialization	Required `server/discover` RPC is available

Migration sequence

Inventory clients, servers, SDK versions, transports, gateways, and session stores.
Separate application state from transport session state.
Implement and test server/discover plus unsupported-version behavior.
Add required per-request _meta and standard Streamable HTTP headers.
Replace server-initiated exchanges with MRTR or the appropriate subscription path.
Move long-running work to the Tasks extension where supported.
Test mixed-version clients, retries, duplicate requests, authorization, and rollback.
Canary the stateless path before removing legacy infrastructure.

Use the compatibility guide for mixed estates and the server discovery guide for version selection.

Release and SDK boundary

Google’s August 5 engineering post describes 2026-07-28 as a release candidate and points to beta SDK support. Pin exact prerelease SDK versions in staging; do not assume a beta API or codemod is stable production authority.

Frequently asked questions

What changed?

Protocol sessions and initialization are removed; version, capabilities, and identity metadata travel with requests and results.

Is every server now stateless internally?

No. The protocol is stateless. Application state can use explicit handles and durable storage.

Should migration be all at once?

No. Use version probes, compatibility tests, a canary, and rollback.

Official sources

Source check: August 6, 2026. Verify final specification status, SDK versions, transport requirements, and migration notes before production rollout.