The MCP Roadmap Is Not a Release or a Compatibility Promise
MCP is moving across its specification, extensions, SDKs, and transports at different speeds. A roadmap priority does not make two products interoperable.
The Model Context Protocol (MCP) roadmap names five areas its maintainers want to advance, from agent messaging and transport changes to workload identity and SDK consistency. It does not make those capabilities one release.
That difference is operational. MCP’s 2026-07-28 specification is available now, but several items in the August 22 roadmap are proposed designs, extensions being matured, or work that has not yet entered the core protocol. Even released behavior can require an explicit SDK setting rather than arriving when a package version changes.
The safe deployment rule is: approve an MCP capability only when the protocol status, exact SDK behavior, target client and server, fallback, conformance evidence, and rollback path all agree. Put released but uneven behavior behind a feature flag. Keep roadmap intent out of production dependencies.
One MCP feature can have four different maturity labels
The official roadmap says it covers the maintainers’ current thinking for the next six to twelve months, not firm commitments. Priorities can move, designs can change, and work can be deferred. Its five areas are useful because they reveal where specification review and working-group effort will concentrate. They do not tell an operator that a given client and server can interoperate today.
The 2026-07-28 specification release is a different kind of artifact. It replaced the protocol-level session and initialization handshake with self-describing requests, introduced server/discover, added standard HTTP routing headers and cache hints, formalized extensions, and hardened authorization. Those are released protocol decisions.
An SDK can still expose a narrower default. The current TypeScript migration guide says a client uses the legacy 2025 handshake unless version negotiation is selected. mode: 'auto' probes with server/discover and can fall back; pinning 2026-07-28 rejects a server that does not offer that revision. Installing the modern SDK therefore does not prove that a deployed connection uses the modern wire behavior.
Four labels must remain separate:
| Label | What it establishes | What it does not establish |
|---|---|---|
| Roadmap priority | Maintainers intend to spend review and design effort here | A final design, release date, or interoperable implementation |
| Specification or extension status | The project has defined a versioned contract at a stated lifecycle stage | Support in the language, version, host, gateway, and peer a team deploys |
| SDK support | One library line exposes some implementation of the contract | Its default configuration, another SDK’s behavior, or end-to-end compatibility |
| Deployment evidence | A pinned client-server pair passed the team’s fixtures and rollback test | Compatibility after either endpoint, extension, gateway, or policy changes |
A package badge collapses those labels. A deployment record must preserve them.
Released and planned MCP features are at different stages
The following matrix translates the current roadmap and released specification into conservative default decisions. “Ship” does not mean universally safe. It means the underlying behavior is released and can enter production after the named implementation and interoperability gates pass.
| Capability and current evidence | What the evidence supports |
|---|---|
2026-07-28 stateless core, self-describing requests, and server/discover. Released in the dated core specification; supported by current official SDK lines, with language-specific migration behavior. | Ship, for a pinned pair. Record client and server SDK versions, enable the intended protocol mode, verify discovery or direct-version errors, test routing headers, and retain a legacy fallback or a deliberate rejection policy. |
Dual-era negotiation during migration. Implemented in the TypeScript v2 client through explicit legacy, auto, or modern pin modes; other SDKs need their own evidence. | Feature-flag. Test modern-to-modern, modern-to-legacy, authorization failure, timeout, and rollback paths; log the negotiated revision rather than inferring it from package versions. |
| Tasks extension. A released extension; the roadmap says maintainers want to mature it toward eventual core inclusion. | Feature-flag. Pin the extension version, verify both peers declare and implement it, test polling and cancellation semantics, and reject use when capability negotiation fails. |
| Enterprise-Managed Authorization. A stable extension cited by the project, but not a universal identity layer for every MCP deployment. | Feature-flag. Verify the authorization server, client, server, grant, token audience, delegation bounds, and revocation behavior as one tested path. |
| Server-initiated events through webhooks or channels. A roadmap deliverable intended to reduce polling; the final composition with Tasks and other event work is still being developed. | Watch. Wait for a versioned contract and target-SDK support, then test delivery, authentication, replay, ordering, cancellation, retry, and fallback. |
| HTTP over stdio transport unification. A roadmap direction for carrying Streamable HTTP semantics over local process I/O. | Watch. Require an accepted specification or extension, released support in both endpoints, framing and shutdown tests, and a fallback to the current supported transport. |
| DPoP adoption, workload identity, and agent delegation. Roadmap work drawing on existing identity standards; the MCP-specific path is not one released turnkey feature. | Watch. Require versioned MCP contracts plus issuer, audience, proof-key, token-exchange, delegation, expiry, revocation, and cross-tenant tests. |
| Redesigned tool results and progressive discovery. Roadmap work intended to clarify result fidelity and avoid loading a large tool catalog up front. | Watch. Wait for a stable schema and SDK implementation; test model-visible fidelity, cache behavior, discovery completeness, authorization filtering, and a full-catalog fallback. |
| Generated SDK artifacts and broader conformance automation. A roadmap experiment to test which SDK and quickstart layers can be generated and revalidated. | Watch. Treat published conformance results as evidence only for the exact suite, revision, SDK commit, and role tested; do not deploy generated output solely because it came from the experiment. |
The matrix is intentionally asymmetric. A released extension can earn a feature-flag before it belongs in the core. A roadmap feature cannot earn “ship” because a vendor exposes something with a similar name. Product-specific behavior may be useful, but it must be recorded as that vendor’s extension rather than MCP-wide support.
Released behavior can still differ at runtime
One concrete connection includes a client, a server, two SDK implementations, a transport, an authorization path, a protocol revision, and any extensions. “MCP-compatible” compresses all of those moving parts into one label.
The negotiated revision can differ from the one suggested by a dependency version. Older peers may trigger a fallback or deliberate rejection, gateway rules can alter the wire behavior, and an advertised extension can be absent or only partly implemented. Independent migration guidance from Arcade expects a dual-stack period for public services precisely because clients do not update together.
TypeScript makes the package-versus-runtime distinction unusually visible. Its v2 guide documents three connection policies: legacy by default, automatic discovery with fallback, and a modern-only pin. A platform team could reasonably choose automatic negotiation for a public service and a modern-only pin inside a controlled fleet. Those are different risk decisions even if both deployments use the same SDK release.
Every moving layer can invalidate compatibility
Compatibility expires when the protocol, extension, client SDK, server SDK, host product, gateway, authorization profile, feature flag, or conformance suite changes materially. It can also expire when a roadmap proposal becomes a released extension: that is a reason to open a new review, not to auto-promote the old watch item.
Date each row and keep the source URL beside it. The specification changelog is the baseline for released core behavior; the roadmap explains intended direction; SDK documentation explains how one implementation exposes the contract. Each answers a different question.
The roadmap’s most valuable production lesson is therefore not any single feature. It is the warning that MCP is moving on several layers at once. Teams that record those layers separately can adopt released improvements without mistaking project momentum for interoperability.