Dora NodaOn December 9, 2025, Anthropic did something most companies never do with their most successful product: it gave the governance away. The Model Context Protocol — the standard now embedded in Claude, ChatGPT, Gemini, Copilot, Cursor, and over 10,000 registered servers, with 97 million monthly SDK downloads — moved out of Anthropic's hands and into a new Linux Foundation body called the Agentic AI Foundation (AAIF), alongside Block's goose and OpenAI's AGENTS.md.
Three weeks from now, that new governance gets its first real stress test. The MCP spec's 2026-07-28 release candidate eliminates the protocol's session concept entirely — client metadata, capabilities, and protocol version move from a stateful handshake into a _meta field on every request. It's the kind of architectural change that, under the old single-vendor cadence, arrived with three months' notice and no formal deprecation path. This time, there's a foundation, a steering group, and a written policy standing between "Anthropic decided" and "your production MCP server breaks." Whether that structure actually holds is the concrete question this post answers — not whether vendor-neutral governance sounds good in a press release.
What actually changed: three mechanisms, not a vibe
"Vendor-neutral" is doing a lot of work in most of the coverage of this move. Stripped to mechanics, three concrete things changed.
A Specification Enhancement Proposal (SEP) process replaced one company's roadmap. Any breaking change to the spec — defined as anything not backwards-compatible — now requires a SEP: a written design document, public discussion, and sign-off from the maintainer group, not a single company's internal planning cycle. It's the same shape as a PEP or an RFC, and it's the mechanism the 2026-07-28 session removal is running through right now, as SEP tracking on the modelcontextprotocol/modelcontextprotocol repo shows.
A semantic-versioning proposal (SEP-1400) is trying to fix a documented instability problem. Before the foundation, MCP versioned by date (2025-03-26, 2025-06-18) and broke compatibility inside those three-month windows without much warning — most concretely, message batching was added in the 2025-03-26 spec and removed again in 2025-06-18, a genuine reversal, not a deprecation. SEP-1400 proposes replacing date-stamped versions with SemVer 2.0.0 specifically so a MAJOR/MINOR/PATCH bump tells an integrator upfront how much is at risk, instead of finding out by diffing two dated specs.
A deprecation policy (SEP-2596) puts a number on how much warning you get. As of 2026, individual spec features move through a formal lifecycle — Active, Deprecated, Removed — with a minimum twelve-month window between deprecation and earliest removal, a required @deprecated schema annotation, and a changelog entry. Deprecation and removal are each their own SEP, so removal can't ride in silently on the same proposal that deprecated a feature.
None of this touches who actually writes the spec day to day. The AAIF Governing Board — one seat per Platinum member (AWS, Anthropic, Block, Bloomberg, Cloudflare, Google, Microsoft, OpenAI) — controls strategic investment, budget, and new-project approval. It does not write MCP's technical spec. That stays with the MCP Steering Group: Lead and Core Maintainers guided by community SEPs, the same people who were stewarding the protocol before the donation. As the MCP project's own announcement puts it: "the governance model introduced earlier this year continues as is." The foundation changed who owns the org chart around MCP. It did not, by itself, change who decides what ships in MCP.
The live test case: does the new process actually cushion a real breaking change?
This is where the abstraction gets to be concrete. The 2026-07-28 release candidate is a genuinely major break: removing sessions from the protocol layer means any server or client that assumed a stateful handshake — negotiate a protocolVersion once, keep capabilities pinned for the connection's lifetime — has to be rewritten to read _meta per request instead. Guidance for Tier 1 SDK users (the official TypeScript and Python SDKs) is explicit: expect RC-compatible releases before the 28th, pin to the RC build once it ships, and run your test suite against it — don't wait for the final spec date to discover what broke.
Compare that to the batching reversal from a year earlier. That change landed inside a routine three-month dated-spec cycle, with no SEP, no deprecation window, and no advance RC to test against — it was just different in the next dated spec. The 2026-07-28 change is arguably a bigger architectural break (an entire protocol-layer concept removed, not one feature), and it's shipping with an RC period and public tracking that the batching change never had. That's the actual, falsifiable improvement: not that MCP stopped making breaking changes — foundations don't stop that, and a young, actively-evolving protocol still needs to — but that a breaking change now arrives with a named process and a runway to test against, instead of landing fully-formed in the next dated spec.
What the SEP/deprecation machinery does not yet do: SEP-2596's twelve-month deprecation window is a policy applied going forward to individual features reaching end-of-life, not a retroactive guarantee that covers a protocol-layer rewrite like session removal, which is being handled as its own major-version-shaped SEP rather than a deprecation cycle. A platform building against MCP still needs to track SEPs directly — the foundation gives you a process to watch, not an alert system that watches it for you.
What "vendor-neutral" doesn't buy: the platinum paywall
The governance shift has a real limit, and it's not subtle. Platinum membership — the only tier with a Governing Board seat and real voting power — costs $350,000, matching the going rate for other Linux Foundation directed funds. Every current Platinum member (AWS, Anthropic, Block, Bloomberg, Cloudflare, Google, Microsoft, OpenAI) is a large, well-capitalized company. One critic's framing, quoted in coverage of the launch, was blunt: "not openness, this is a country club wearing an open-source hoodie."
The same critique extends to project selection. Block's goose — "simply an MCP client like thousands of others," per the same critique — sits in the same founding-project tier as MCP itself, arguably because Block could write the $350,000 check and other, more widely-used MCP clients couldn't. That's a real asymmetry: strategic influence over the foundation's budget and roadmap priorities is gated by capital, even though MCP's day-to-day spec decisions stay with the maintainer/SEP process described above.
So the honest version of "reduced single-vendor risk" is narrower than the announcement implies. What genuinely changed: no single company can unilaterally rewrite the spec anymore, and there's a public process for breaking changes. What didn't change: the same handful of large AI vendors still hold the strategic levers, just now formalized as board seats instead of one company's product roadmap — and a smaller player without $350,000 to spend has no more say in AAIF's strategic direction than it had in Anthropic's roadmap a year ago.
What this means for a platform's own MCP server
For a self-hosted platform betting its deploy-from-chat surface on MCP as the interface, the practical question isn't "is the foundation good" — it's "what do I target, and how do I not get broken by the next SEP." Four concrete moves follow directly from the mechanics above:
- Target the foundation's numbered spec, not a vendor's SDK release cadence. The spec and the reference SDKs can drift independently now that governance sits outside one company. Pin your server's
protocolVersionsupport to specific dated specs (soon: SemVer ranges, once SEP-1400 lands) rather than "whatever the latest@modelcontextprotocol/sdkdoes." - Build a version negotiation matrix now, not after
2026-07-28ships. If your MCP server needs to serve both stateful legacy clients and stateless post-RC clients during the transition, that's two code paths, not a flag — the RC's own guidance is to pin and test before the deadline, not after. - Subscribe to the SEP tracker, not just the changelog. A deprecation notice under SEP-2596 comes with a twelve-month clock once a feature is formally deprecated — but only for features going through that lifecycle from here forward. Architectural shifts like session removal are moving as their own major SEPs on their own timeline, so watching SEPs directly, not just waiting for deprecation notices, is what actually gives you lead time.
- Don't treat "Linux Foundation" as a substitute for reading the SEP. The foundation changed the process, not the fact that a young protocol will keep changing underneath you. The improvement is that the change now comes with a name, a discussion thread, and often an RC — use those, because the foundation itself won't page you when one lands.
None of this makes MCP a finished, stable target — a protocol with a formal deprecation policy less than a year old and a major architectural rewrite three weeks out is still visibly a protocol being built in public. What the Linux Foundation handoff buys a platform betting on MCP is narrower and more useful than "vendor risk solved": a documented process to track instead of a single company's changelog to guess at.
Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own, with an MCP-native deploy surface built to track the spec, not a single vendor's SDK. Star the repo on GitHub or deploy your first app today.