Enterprise Readiness Guide for the July 2026 MCP Spec Update

How to assess, migrate, and validate internal MCP servers for the July 28, 2026 specification revision.

MCP is becoming stateless. Your applications may not be.

On July 28, 2026, the Model Context Protocol is scheduled to publish its largest specification revision since launch. The new protocol removes the initialization handshake and protocol-level sessions, shifts version and capability data into every request, and introduces new behaviors for discovery, subscriptions, server-to-client interactions, caching, tasks, authorization, schemas, and tracing.

What changes on July 28

Change	Operational implication
Protocol sessions are removed	Mcp-Session-Id and protocol-managed sessions go away. Any request can land on any server instance.
Initialization is removed	Clients no longer establish a session with initialize/initialized. Protocol version, identity, and capabilities travel with each request.
Discovery becomes explicit	Modern servers must implement server/discover to advertise versions, capabilities, and identity.
HTTP becomes easier to route	Mcp-Method and Mcp-Name headers become required for Streamable HTTP POST requests.
Cross-call state becomes explicit	Stateful applications can still work, but state should be represented by server-minted handles passed as normal tool arguments.
Server-to-client flows change	Multi-round-trip requests replace persistent, out-of-band server-initiated patterns; subscriptions move to subscriptions/listen.
Tasks move to an extension	Implementations using the experimental Tasks API must migrate to the redesigned extension lifecycle.
Results and list responses change	Results require resultType; list and read responses add ttlMs and cacheScope; schemas gain full JSON Schema 2020-12 support.
Authorization and observability harden	The revision adds OAuth/OIDC requirements and formalizes W3C Trace Context propagation for OpenTelemetry-compatible tracing.

Who is most likely to be affected

• Remote servers that rely on Mcp-Session-Id, sticky routing, or shared protocol session stores.
• Servers or clients that assume initialize/initialized is required before every other method.
• Implementations using the 2025-11-25 experimental Tasks API.
• Workflows built around resource subscriptions, HTTP GET/SSE behavior, or resumable SSE event delivery.
• Servers that issue out-of-band requests to clients or depend on persistent bidirectional connections.
• Clients that match literal legacy error codes or do not understand required resultType and cache fields.
• Authorization deployments that do not handle issuer validation, application_type, or issuer-bound credentials.

A critical compatibility distinction

The new specification defines “modern” implementations as 2026-07-28 and later, “legacy” implementations as 2025-11-25 and earlier, and “dual-era” implementations as those that support both. Modern-only clients do not automatically work with legacy-only servers, and legacy-only clients do not automatically work with modern-only servers. Compatibility requires both sides to share a supported protocol era, or for one side to implement deliberate fallback or translation.

The six-step readiness plan

Readiness checklist

Use this as a working artifact across your platform, security, and application teams. A server is ready only when every applicable row is satisfied under realistic routing and failure conditions.

Area	Ready when…	Status
Protocol and transport	server/discover implemented; per-request protocol metadata present; required HTTP headers validated; no hidden dependency on Mcp-Session-Id.
State management	Cross-call state is represented with explicit, scoped handles; state authorization and expiration are defined.
Methods and lifecycle	Removed methods are eliminated; Tasks extension lifecycle is updated; MRTR and subscriptions/listen are handled where relevant.
Schemas and responses	resultType is present; cache fields are returned where required; JSON Schema 2020-12 behavior is bounded and tested; error-code assumptions are updated.
Authorization	Issuer validation, application type, credential binding, refresh-token behavior, and registration strategy are reviewed.
Observability	traceparent, tracestate, and baggage propagate through clients, servers, gateways, and downstream calls.
Compatibility	Target clients and servers share a supported era; fallback behavior is tested rather than assumed.
Operations	Round-robin load balancing works; no session affinity is required for modern traffic; retries and failure behavior are documented.

Can a compatibility layer avoid rewrites?

Potentially, but only for well-defined patterns. A useful compatibility layer must do more than strip or add headers. It may need to detect protocol era, translate initialization and discovery behavior, preserve client identity and capabilities per request, map session state safely, transform method and result shapes, handle subscriptions and multi-round-trip interactions, and preserve authorization and audit semantics.

Good candidates for translation

• Servers with limited, deterministic session usage that can be represented by explicit handles.
• Simple tool servers whose primary gap is protocol framing rather than application semantics.
• Organizations that need a staged migration while internal owners update implementations.

Poor candidates for transparent translation

• Complex state hidden in persistent connections or shared sessions.
• Out-of-band server-to-client behavior with no clean retry or request-scoped equivalent.
• Experimental Tasks or subscription designs whose semantics changed materially.
• Authorization models where translation would obscure user identity, consent, or policy enforcement.

How Stacklok helps

1. Assess your internal server portfolio and identify concrete compatibility risks.
2. Produce a prioritized migration plan with effort and business-impact scoring.
3. Update high-priority servers and translate stateful patterns to the modern protocol model.
4. Validate behavior against the clients and infrastructure you actually run.
5. Evaluate dual-era support or proxy compatibility where it can safely reduce migration effort.
6. Create ongoing visibility and governance so the next protocol change is easier to absorb.

Questions to ask your team this week

• Which clients will we upgrade first, and do they support legacy fallback?
• Which internal servers are business-critical but have no active owner?
• Where is state stored today: protocol session, process memory, shared store, or explicit application object?
• Which servers use features that are removed, redesigned, or deprecated?
• What evidence proves a server works under round-robin routing without affinity?
• Can you trace a tool call end-to-end across the client, gateway, server, and downstream system?

About the specification status

This guide is based on the release candidate locked on May 21, 2026 and the draft specification available before the scheduled July 28, 2026 final release. Teams should verify final wording and SDK behavior at launch, especially before making production compatibility claims.