MCP VERSIONING
VERSIONMCP Specification Status: What Changed in 2026-07-28 and What Teams Should Review
A current MCP version guide for engineering teams moving from the 2025-11-25 baseline to the 2026-07-28 specification.
Current status
The Model Context Protocol project published the 2026-07-28 specification on July 28, 2026. It supersedes the 2025-11-25 revision as the current authoritative specification. XTIANZ previously carried an older production-baseline statement on some pages; this release corrects that inconsistency across the site.
Changes worth an engineering review
The official changelog is the best source for exact requirements. At a system level, the 2026 release moves toward a stateless core suitable for ordinary HTTP infrastructure, formalizes an extensions mechanism, evolves long-running and application interaction patterns, strengthens authorization, and gives implementers a clearer deprecation path.
These changes can affect assumptions embedded in homegrown clients, server middleware, authorization proxies, retry behavior, and observability. The more custom protocol code you have, the more important a compatibility test becomes.
A safe migration sequence
| Step | Action | Exit condition |
|---|---|---|
| 1 | Inventory protocol versions, SDK versions and custom middleware | No unknown dependency |
| 2 | Read changelog and relevant specification sections | Document expected behavior change |
| 3 | Run client/server compatibility suite | No silent capability loss |
| 4 | Re-test authorization and token audience | Protected resources still reject invalid tokens |
| 5 | Stage with production-like traffic | Observe errors, retries, latency and tool results |
| 6 | Pin and promote | Rollback path remains available |
Version policy for production teams
Do not automatically float to the newest SDK in production. Pin versions, review protocol changes, and upgrade on a planned cadence. Conversely, do not stay on an old protocol indefinitely because it “still works.” Security and interoperability improvements can make old assumptions increasingly expensive.
Record the protocol version in your run telemetry. When an incident crosses multiple MCP servers, knowing which protocol and SDK each component used can shorten diagnosis significantly.
Compatibility tests worth automating
Protocol upgrades are safer when compatibility is executable rather than documented only in a migration ticket. Build a small matrix that connects the oldest supported client to the newest supported server, the newest client to the oldest supported server, and the production client/server combination. Exercise initialization, capability discovery, resource listing, tool listing, tool invocation, cancellation, errors, authentication failure, token refresh, and any extensions your environment depends on.
Include negative tests. A protected server should reject a token for the wrong audience. A client should handle an unavailable capability without silently assuming it exists. A server should return useful errors for invalid arguments. If your environment uses gateways or proxies, include them in the test path because headers, streaming behavior, timeouts, and authentication discovery can change at those boundaries.
Support a version because you have tested it, not because the SDK happens to install. Publish the supported protocol range for internal platform users and give server owners a deprecation window before removing an older version.
Review history
August 9, 2026 — Reworked as a flagship XTIANZ guide with current primary sources, original decision frameworks, and technical review.
Suggest a correction ↗Disclosure
AI tools may assist research organization, drafting, code, and quality checks. The final structure, claims, frameworks, and publication decision are manually reviewed. XTIANZ does not accept payment to change technical conclusions.