MCP became a standard the ordinary way — by being donated

The Model Context Protocol solved a problem that was going to be solved by somebody: every AI application needed to connect to every tool, and each pairing was bespoke. That is an n×m problem, and it is the same shape as every integration mess in computing history.

MCP turns it into n+m. Build a server once, and any compliant client can use it.

The technical design is unremarkable in a good way — it is JSON-RPC, and it works. The part that determined the outcome was governance.

The donation is why it won

In December 2025, Anthropic donated MCP to the Agentic AI Foundation under the Linux Foundation, making it vendor-neutral and community-governed.

This is the move that separates a standard from a proprietary protocol with good documentation. Nobody wants to build integrations against a format controlled by one vendor whose commercial interests may later diverge from theirs — that is the same governance risk that makes single-vendor open source a liability, applied to a protocol.

Once the copyright and roadmap sit with a neutral foundation, adopting it stops being a bet on one company. OpenAI, Google DeepMind and Microsoft all adopted it, which would have been considerably harder to imagine had it remained a single vendor's protocol.

The numbers followed: 97M+ monthly SDK downloads across Python and TypeScript, and around 41% of surveyed software organisations running MCP servers in limited or broad production.

What it actually gives you

The practical value is that the integration you write is not tied to the client you wrote it for.

Expose your internal system once — a ticketing system, a database, a deployment tool — and it becomes available to whichever assistant or agent your team uses this year and whichever one it uses next year. That decoupling is the entire point, and it is worth more than any individual feature of the protocol.

For teams building products, the mirror is also true: supporting MCP means your product becomes reachable from a large and growing set of AI clients without you building an integration per client.

The part that needs saying alongside this

Adoption at this speed, on infrastructure this young, has a predictable consequence.

Researchers identified the first malicious MCP server in the wild — postmark-mcp shipped fifteen clean versions before adding a line of exfiltration code. CVE-2025-6514, a remote code execution flaw rated 9.6, was disclosed in core MCP infrastructure.

With something like 10,000 public servers in the registry and 15,000+ repositories carrying the topic, this is now a substantial supply chain, and it has the same properties as every other one: the code runs with your permissions, most of it is maintained by people you will never meet, and a compromise upstream reaches you automatically.

The specific risk with MCP is sharper than with a normal library, because an MCP server is usually granted access to something valuable by design — that is what it is for. A compromised logging library is bad. A compromised server holding your database credentials is worse.

So the sensible posture is the one that applies to any dependency, applied more strictly: pin versions, scope credentials narrowly, prefer servers you or a known organisation maintain, and treat an MCP server that requests broad access the way you would treat a browser extension that asks to read all your data.

Why this is still the right direction

None of the above argues against MCP. Standardising the interface between models and tools is obviously correct, and the alternative — every vendor with its own plugin format — was worse in every dimension.

What is worth holding onto is that a protocol becoming a standard does not make its ecosystem trustworthy. Those are separate properties, achieved by separate means, and the second one takes considerably longer.