MCP 2026-07-28 migration: what to check before upgrading

The MCP 2026-07-28 release candidate is not just a new SDK import path. It changes how hosts and servers agree on protocol version, state, discovery, server-to-client input, auth, and deprecated features.

Start With A Compatibility Lane

Keep production on the supported SDK line until the host and server both pass a compatibility check. Use a small non-production server to test v2 beta behavior, and list every host, server, transport, SDK, and auth path before changing defaults.

Prove The Protocol Era

Modern MCP requests carry protocol version, client identity, and capabilities in metadata, while servers advertise capabilities through discovery. Logs should make it obvious whether a request used the legacy or modern path.

• Can the host and server name the same protocol version?
• Can the gateway route without body inspection?
• Can traces show which era handled the request?

Replace Hidden Session State

The stateless core removes protocol-level sessions. Any workflow that needs continuity should use explicit handles such as task ids, browser ids, or workspace ids, with lifetime, ownership, revocation, and redaction rules.

Review Input Required As Approval

Server-to-client input now belongs in a request-scoped approval path. Treat delete, account, browser, credential, or production actions as explicit prompts with schemas, request state, retry behavior, and audit evidence.

Stop New Work On Deprecated Features

Roots, Sampling, and Logging still work during the deprecation window, but new product flows should not depend on them. Prefer explicit tool parameters, resource URIs, direct model-provider integration, stderr, and OpenTelemetry.

Promote Only With Proof

Before production rollout, capture a modern request, discovery output, a state-handle round trip, an input-required approval flow, issuer-aware auth behavior, and a trace that follows the host, SDK, MCP server, and downstream call.