Most of the MCP coverage this year has been about the protocol: the stateless core in the 2026-07-28 revision, the roadmap published in August. Those are the changes that touch your code.
The change that touches your contracts got much less attention: MCP is no longer a protocol one vendor publishes. It’s a project under the Agentic AI Foundation at the Linux Foundation, alongside goose and AGENTS.md, with a technical steering committee, a contributor ladder, working groups, and — as of this year — a formal project lifecycle policy with Growth, Impact, and Emeritus stages that lets outside projects join.
If you write code against MCP, none of that shows up in your diff. If you’re the person who has to justify betting a platform on it, all of it matters. This post is for the second person.
Why the governance question is a real question
Every platform team that has been doing this a while has a scar from adopting a “standard” that turned out to be one company’s product decision with a spec attached. The pattern is familiar: a vendor publishes an open protocol, the ecosystem builds on it, and then the vendor’s commercial priorities and the ecosystem’s technical priorities diverge. The spec goes where the vendor needs it to go, because there is no venue in which anyone can argue otherwise.
That was a legitimate risk for MCP through 2025. It was a protocol Anthropic wrote, published, and controlled. The technical merits were real and the adoption was real, but so was the single point of governance failure. “What happens when their roadmap and my roadmap disagree?” had no good answer, because there was no forum in which the question could even be asked.
The donation to the Agentic AI Foundation changes that answer. Not to “you get what you want” — that’s not what neutral governance means — but to “there is a documented process, a committee that isn’t a single vendor, and a public record of the argument.” For anything you plan to build a decade of infrastructure on, that’s the difference between a dependency and a bet.
What neutral governance actually gives you
Be precise about this, because it’s easy to oversell. Foundation stewardship is not a guarantee of stability, quality, or good decisions. Plenty of foundation projects have stagnated. What it does provide is four concrete things:
A venue for disagreement. Working groups triage proposals in their own area, and specification changes go through a public process rather than an internal one. When your use case conflicts with the direction, there is somewhere to make the case — and a public record when you lose.
A contributor ladder. This sounds like community-management trivia and isn’t. A documented path from contributor to maintainer is how a project survives its founding team moving on. Projects without one are one reorg away from unmaintained.
A deprecation policy. A feature lifecycle with defined stages means “this is experimental” and “this is stable” are statements with consequences, not vibes in a changelog. That’s what lets you decide which parts of the protocol are safe to build load-bearing infrastructure on — the same judgment you apply to any model or dependency with an end-of-life.
A neutral trademark and IP home. Boring, and the reason the Linux Foundation exists. It means no single company can relicense the thing under you.
What it does not give you
It does not make MCP secure. The protocol’s governance and your deployment’s security are unrelated problems, and the second one is in worse shape than the first — OWASP now maintains a dedicated MCP Top 10, and the NSA has published guidance on the protocol as a centralized funnel for prompt injection and trust-boundary abuse. Neutral stewardship of a spec does nothing about the anonymous inference endpoints in your own network.
It does not slow the protocol down in a way that saves you work, either. The 2026 revision was the largest since launch. Governance maturity and specification churn are independent variables, and right now both are high.
And it does not settle the competitive layer above MCP. Agent-to-agent coordination is still contested ground; the two-layer stack is a reasonable model, not a settled standard.
What to actually do with this
Three things, none of which are code changes:
Update the risk register. If MCP appears in an architecture decision record with a “single-vendor protocol” risk noted — and it should, if the ADR was written before this year — that entry needs revising. The risk didn’t vanish; it changed shape from “vendor control” to “foundation velocity and design-by-committee.” Write down the new one.
Read the lifecycle stages before you depend on a feature. The useful discipline is to know, for every MCP capability you rely on, whether it’s stable or still moving. That’s now a question with a documented answer. Ask it before, not after.
Send someone. MCP Dev Summit Seoul ran August 13–14 alongside Open Source Summit Korea, and the foundation has a full 2026 events program anchored by MCPCon and AGNTCon. If your platform’s agent story depends on this protocol, the working groups are where its direction is decided, and participation is the cheapest influence you will ever buy. The teams that shaped Kubernetes’ extension points were in the room; the teams that later fought them were not.
The protocol news is what gets read. But the reason MCP is a defensible platform bet in 2026 and was only a promising one in 2025 has almost nothing to do with the stateless core, and almost everything to do with the fact that there is now somewhere to file the complaint.
Related: MCP goes stateless · MCP’s 2026 roadmap · What is Model Context Protocol?
Comments