MCP 2026-07-28 is the latest stable specification as of July 30, 2026. Final specification status does not make it an automatic production upgrade: SDKs and hosts adopt revisions at different speeds. Inventory session-dependent behavior, add explicit version negotiation, migrate state into tool arguments, test routing headers and authorization changes, and preserve a 2025-11-25 compatibility path until every deployed client and server is aligned.
Tech
MCP 2026-07-28 is the latest stable specification as of July 30, 2026. Final specification status does not make it an automatic production upgrade: SDKs and hosts adopt revisions at different speeds. Inventory session-dependent behavior, add explicit version negotiation, migrate state into tool arguments, test routing headers and authorization changes, and preserve a 2025-11-25 compatibility path until every deployed client and server is aligned.
Reviewed July 30, 2026: The official MCP release list marks 2026-07-28 as the latest stable release and lists 2026-07-28 RC separately as a prerelease. The public versioning page now resolves to the 2026-07-28 documentation.
At a glance
• Record 2026-07-28 as stable, while tracking SDK and host support separately.
• Run the 2025 and 2026 lifecycles as distinct compatibility paths.
• Replace protocol-managed sessions with explicit application state handles where needed.
• Test request metadata, discovery, routing headers, caching, errors, and multi-round-trip interactions.
• Review OAuth and OpenID Connect behavior independently of transport changes.
• Keep production rollback available until conformance and real workflow tests pass.
What changes in the 2026 architecture
The largest change is the move from a session-oriented protocol lifecycle to a stateless protocol core. Under 2025-11-25, a client initializes a connection, negotiates capabilities, receives a session identifier, and carries that session across later Streamable HTTP requests. This can make a deployment depend on sticky routing or shared session storage.
The final 2026 key changes remove the initialize and notifications/initialized handshake for the new era. A client can use server/discover to inspect capabilities, while protocol version and relevant client metadata travel with requests. The revision also removes the protocol-level Mcp-Session-Id. A request should be self-describing enough for any compatible server instance to process it.
Stateless protocol transport does not mean stateless business logic. A server that creates a browser, cart, report job, or approval case can return an explicit identifier such as browser_id or job_id. The model then supplies that identifier to later tools as an ordinary argument. This makes state visible and testable, but it also moves responsibility for authorization, expiry, tenancy, replay protection, and cleanup into application design.
The revision adds standard HTTP routing information, cache hints for list and read results, documented W3C trace-context propagation, and multi-round-trip requests for cases where a tool needs additional input. Extensions become a formal mechanism. MCP Apps and long-running Tasks sit outside the core as extensions.
The final changelog is the change inventory for this revision. Do not build a migration solely from an announcement; field names and normative requirements belong to the dated specification and SDK documentation.
Migration decision table
Current condition: Local stdio server with no session assumptions; Recommended action: Test the stable revision; migrate when benefits justify it; Why: Horizontal HTTP scaling benefits may not apply
Current condition: Remote server relies on Mcp-Session-Id; Recommended action: Design explicit state handles before enabling the new era; Why: The 2026 revision removes protocol sessions
Current condition: Client and server use different SDK families; Recommended action: Keep 2025-11-25 compatibility until both support 2026; Why: SDK adoption is asynchronous
Current condition: Gateway parses JSON bodies for routing; Recommended action: Test Mcp-Method and Mcp-Name handling; Why: New headers support routing without body inspection
Current condition: Tools use Roots, Sampling, or Logging; Recommended action: Build a replacement plan and monitor lifecycle notices; Why: These features are deprecated, not immediately removed
Current condition: Long-running tools use experimental Tasks; Recommended action: Rework against the extension lifecycle; Why: The Tasks extension changes creation and management
Current condition: Regulated workflow has no dual-version tests; Recommended action: Stay on its tested version; Why: Migration must not weaken evidence or rollback
Compatibility mechanics
Start with a capability matrix for every deployed client, server, gateway, inspector, SDK, and hosted platform. Record the exact protocol versions each component can negotiate, whether support is stable or preview, and what happens when discovery fails.
The official TypeScript SDK migration guide says the new wire behavior requires explicit opt-in; upgrading a package does not automatically emit 2026 traffic. Other SDKs can follow different schedules. That is why “our SDK supports MCP 2026” is not enough. Verify the version sent on the wire and fallback behavior in an integration test.
Build tests for both directions:
1. A modern client talks to a modern server using the 2026 lifecycle.
2. A modern client falls back to a 2025-11-25 server.
3. A legacy client reaches a dual-era server without receiving 2026-only responses.
4. An unsupported protocol version fails explicitly rather than silently changing semantics.
5. A gateway preserves required headers and trace metadata.
Also inspect application code for hidden coupling to connection lifetime. Common examples include per-session tool lists, in-memory approval state, user identity attached only during initialization, subscriptions tied to a socket, and cleanup that runs only when a session closes.
Security and governance
A stateless transport can simplify infrastructure, but it does not reduce the need for identity and policy. Explicit state handles must be unguessable or separately authorized. A server must validate that the authenticated principal can use a handle on every call. Never treat possession of a cart, browser, task, or file identifier as sufficient authorization.
Review the authorization changes against the current MCP authorization specification. Validate token audience, authorization-server issuer, redirect URIs, PKCE, protected-resource metadata, step-up scope behavior, and credential isolation. Do not pass the client’s bearer token through to an upstream API.
Governance records should include:
• protocol version and SDK version for each environment;
• approved extensions and their independent versions;
• tool owner, data classification, and allowed identities;
• destructive or externally visible actions requiring confirmation;
• retention and deletion rules for explicit state handles;
• trace correlation and security-event destinations;
• tested downgrade and rollback procedures.
Deprecation is not removal. If Roots, Sampling, or Logging remains operational in a 2026-compatible SDK, document that it is deprecated and identify its replacement. Avoid deleting controls merely because their protocol primitive is changing.
Implementation checklist
• [ ] Confirm the latest stable revision and each component’s support on implementation day.
• [ ] Record every client, server, SDK, gateway, and protocol version.
• [ ] Find dependencies on initialization, session IDs, sticky routing, and connection cleanup.
• [ ] Replace hidden cross-call state with explicit, authorized, expiring handles.
• [ ] Add 2026 discovery and version-negotiation tests.
• [ ] Verify required routing headers and body/header consistency checks.
• [ ] Test cache scope and expiry for tools, prompts, and resources.
• [ ] Migrate long-running work to the documented Tasks extension shape where appropriate.
• [ ] Test multi-round-trip input and human-confirmation paths.
• [ ] Review OAuth issuer, audience, PKCE, scope, and token-isolation controls.
• [ ] Propagate trace context without leaking sensitive arguments.
• [ ] Keep a tested 2025-11-25 fallback and production rollback.
• [ ] Run conformance tests plus representative end-to-end business workflows.
• [ ] Update runbooks, diagrams, inventories, and incident procedures.
Limitations and change risk
This guide describes the stable 2026-07-28 specification and the TypeScript SDK’s documented migration direction as of the review date. Stable specification status does not mean every SDK, hosted client, gateway, or server has adopted the revision.
SDK support does not arrive simultaneously. One language may require an option while another remains preview-only. Hosted clients may support only a subset of extensions or authorization flows. Test actual behavior instead of inferring compatibility from an MCP logo.
For a broader choice between agentic integration and conventional automation, read AI agents vs RPA vs Zapier.
FAQs
Is MCP 2026-07-28 final?
Yes. The official release list marks 2026-07-28 as the latest stable MCP release. The earlier 2026-07-28 RC entry remains visible separately as a prerelease.
Must every MCP server migrate immediately?
No. A local stdio server or a stable remote integration may gain little from an immediate migration. Upgrade when the architectural benefits matter and all components have compatible, tested support.
Does stateless MCP eliminate application state?
No. It removes protocol-managed session state. Applications can retain state through explicit identifiers passed as tool arguments, but they must secure, expire, and audit those identifiers.
Can a client support both protocol eras?
Yes, if its SDK and implementation provide version negotiation or explicit fallback. Test the exact downgrade behavior; do not assume a 2026-capable client automatically interoperates with every legacy server.
Are deprecated capabilities already removed?
No. The 2026 specification describes Roots, Sampling, and Logging as deprecated. Deprecation signals a replacement path and possible future removal, not immediate disappearance.
Get a 20-Minute AI Workflow Audit
Map one real workflow across protocol versions before changing production infrastructure. AI Operator can review tools, state, identity, confirmation points, traces, and rollback as one operational system.