Blog

The New MCP Spec Is a Breaking Change — And Your Ikanos Capabilities Don't Need Recertifying

Jerome Louvel ·July 24, 2026

Table of contents

The release candidate for MCP 2026-07-28 is out, and it is the largest revision of the protocol since launch. The maintainers are candid about it: “This release contains breaking changes.” Emmanuel Paraskakis’ walkthrough of the spec makes the same point from the practitioner’s side — there’s a lot here, and a good chunk of it will force a migration.

We called this in beta1: “MCP itself is a moving target. A major, largely stateless transport revision is expected this summer, and it will force every MCP framework into a new major version — and then force every hand-built or generated server to be regenerated or migrated onto it.” That summer is now. This post is the first of two: today, what actually changed and why it matters for governance at scale; a follow-up will land the day Ikanos ships support and walk through a real fleet upgrade.

What changed in `2026-07-28`

The RC is locked as of May 21, 2026, with the final spec due July 28. Six themes stand out.

MCP is now stateless at the protocol layer. Six SEPs remove the initialize/initialized handshake and the Mcp-Session-Id header. Protocol version, client info, and capabilities now travel in _meta on every request, and a new server/discover method fetches capabilities on demand. Any request can land on any server instance — no sticky routing, no shared session store. State that used to hide in transport metadata becomes an explicit handle (a basket_id, a browser_id) the model threads from one call to the next.
Extensions become first-class. Extensions get a real process: reverse-DNS IDs, negotiation through an extensions map, their own ext-* repositories, and independent versioning. Two ship official in this release — MCP Apps (server-rendered HTML in a sandboxed iframe) and Tasks, which graduates out of the core spec into an extension and gets a new stateless lifecycle (tasks/get, tasks/update, tasks/cancel; tasks/list is gone).
Authorization hardening. Six SEPs align auth with real OAuth 2.0 / OpenID Connect deployments: iss validation per RFC 9207, application_type in Dynamic Client Registration, credentials bound to the issuing server, documented refresh-token requests, and clarified scope accumulation.
Full JSON Schema 2020-12 for tools. inputSchema and outputSchema are lifted to full 2020-12 — oneOf/anyOf/allOf, conditionals, $ref/$defs. structuredContent can now be any JSON value. And the missing-resource error code moves from the MCP-custom -32002 to the standard JSON-RPC -32602.
Roots, Sampling, and Logging are deprecated. Annotation-only for now, under a new feature-lifecycle policy — they keep working for at least twelve months, but the direction is set.
Routable, cacheable, traceable traffic. The Streamable HTTP transport now requires Mcp-Method and Mcp-Name headers so gateways can route without reading the body; list/read results carry ttlMs and cacheScope modeled on HTTP Cache-Control; and W3C Trace Context (traceparent, tracestate, baggage) in _meta is documented so a trace follows a call across SDKs and gateways.

The maintainers are explicit that this is not the future norm — a feature-lifecycle policy (twelve months minimum from deprecation to removal), the extensions framework, and a conformance-gated Standards Track are all designed so future revisions won’t break core capabilities. But this one does. As they put it: “The stateless rework in this release is the kind of foundational change that needed a clean break.”

The migration nobody’s pricing in

Read the changelog through an enterprise lens and the cost isn’t the spec — it’s the fan-out.

Every hand-built or generated MCP server in your estate now faces the same list: rip out the handshake and session handling, adopt the new headers, restructure server-to-client requests around InputRequiredResult instead of a held-open SSE stream, migrate any Tasks usage to the extension lifecycle, and re-check every auth flow against the hardened rules. That’s real work per server. Multiply it by the number of MCP surfaces a large organization has already stood up — one per team, one per vendor integration, one per proof-of-concept that quietly went to production — and the transport revision becomes a fleet-wide migration program.

And migration is only half of it. In a governed environment, code that touches the wire is code that has to be reviewed. Every one of those servers embeds its own transport, session, and auth handling. Change that handling and you’ve changed the security-relevant surface of every server — which means every server goes back through review, sign-off, and recertification. The spec revision lands once; the compliance cost lands N times.

This is exactly the “governance duplication” we flagged in beta1: a new transport their gateway and identity tooling don’t yet understand, re-run across every surface at once.

Why an Ikanos fleet rides through it as one review

Ikanos capabilities are declared entirely in YAML. The spec describes what the capability does — the upstream APIs it consumes, the tools it exposes, the shapes, the auth intent. It says nothing about how bytes move on the MCP wire. The handshake, the session header, the InputRequiredResult flow, the Mcp-Method routing header, JSON Schema 2020-12 validation, the auth mechanics — all of that lives in the engine, not the spec.

So the separation the spec’s own authors are reaching for — a protocol you can “adopt future revisions without rewriting your transport or lifecycle code” — is the separation Ikanos already draws by construction:

The transport revision is an engine concern. Statelessness, the new headers, the restructured elicitation flow, JSON Schema 2020-12, the auth hardening — the common engine implements 2026-07-28 once. The capability spec is 2026-07-28-shaped the moment the engine is, because the spec never spoke transport in the first place.
Your YAML is untouched. No capability author edits a file. The tools, the fusion logic, the upstream bindings, the exposed contract — all identical before and after. The upgrade is a version bump on the engine dependency, exactly as promised in beta1: “a one-line engine bump — with no change to your YAML.”
You recertify the engine, not the fleet. This is the governance payoff. The transport, session, and auth handling that a reviewer cares about now lives in one artifact shared across every capability. Certify that engine build once, and every capability running on it inherits the certification. A hundred capabilities don’t trigger a hundred reviews — they trigger zero, because none of them changed. The one thing that did change is the one thing you sign off.

The spec’s new extensions framework strengthens the same argument going forward. When MCP Apps or the Tasks extension matures, or the deprecated Roots/Sampling/Logging features are eventually removed, that’s again an engine-level negotiation — the extensions map, the lifecycle handling — not a rewrite of every capability that happens to run on the engine. The fleet stays on its own release cadence while the engine absorbs the protocol’s.

What this means at enterprise scale

The number that matters isn’t “how hard is one migration.” It’s “how many times do we pay for it.”

One migration, not N. The engine team adopts 2026-07-28 once. Every capability in the fleet moves with it.
One recertification, not N. The security-relevant transport/auth surface is a single reviewed artifact. Sign off the engine; the fleet inherits it.
Zero YAML churn. Capability authors keep shipping business logic. They don’t stop to learn the difference between a session header and a _meta field.
A repeatable pattern for the next one. 2026-07-28 won’t be the last revision. The feature-lifecycle policy and extensions track mean future changes should be smaller — but “smaller” still fans out across a hand-built estate. With Ikanos it stays a single engine upgrade every time.

The spec authors built 2026-07-28 so implementers “targeting 2026-07-28 will be able to adopt future revisions without rewriting their transport or lifecycle code.” That’s the right goal. Owning the spec rather than the server is how you get it for your whole fleet at once — and how a protocol revision that recertifies half the industry’s MCP servers becomes, for you, a single engine build to review.

Next up

The common engine upgrade to 2026-07-28 is in progress. When Ikanos ships support, the follow-up post will take a real fleet — the Notion→GitHub capability, the voice-assistant capability, and more — bump the engine, and show the diff: green on the engine, empty on every YAML file, one certification instead of many.