What Is MCP (Model Context Protocol)? Who Runs It and Why That Matters

Model Context Protocol, or MCP, is an open standard for connecting AI apps to tools and data. Anthropic released it in November 2024. A neutral foundation now governs it, not one company. Any AI app that speaks MCP can talk to any MCP server, without custom glue code per pairing.

That's the short version. The interesting part is what "protocol" means here, and why a vendor-neutral one changes what you can safely build on. See the MCP-connected AI page for what that unlocks in practice. For a CMS like Draftbase, it's the difference between shipping an AI feature that outlives a single vendor's roadmap and one that doesn't.

What Does "Protocol" Actually Mean Here?

A protocol is a shared set of rules for exchanging messages. It's not code you install. It's not one company's SDK. MCP defines message shapes and semantics in JSON-RPC 2.0. Any party that follows those rules can talk to any other party that follows them too.

That distinction matters more than it sounds. An SDK is one vendor's implementation. A protocol is the agreement the SDK implements. You can write your own MCP server without touching Anthropic's SDK at all. Your messages just have to match the spec. See what an MCP server is for the mechanics: tools, resources, prompts, and the JSON-RPC message shape.

Who Governs MCP?

Not Anthropic alone, as of December 2025. Anthropic gave MCP to a new group, the Agentic AI Foundation (AAIF). AAIF is a vendor-neutral body under the Linux Foundation. OpenAI and Block co-founded AAIF alongside Anthropic, and Google, Microsoft, AWS, and Cloudflare back it too (MCP Blog).

Day-to-day technical decisions still sit with MCP's own maintainer group. AAIF handles budget, membership, and strategic direction, not code review. The stewardship model mirrors Kubernetes, PyTorch, and Node.js, three projects that outlived the single company that started them.

Why the governance model is the real story

Most integration standards die a specific way. One vendor builds it. One vendor controls the roadmap. Every dependent product inherits that vendor's incentives. A pricing change, a deprecated feature, a licensing shift: everyone downstream scrambles.

A foundation-governed protocol removes that single point of control. No one company can break MCP on its own to serve its own product roadmap, since no one company owns it. That's worth weighing before you build product infrastructure on any AI-adjacent standard: who can change the rules, and what happens to you when they do?

How Fast Has MCP Grown?

Fast enough that the growth curve is itself part of the story. One year after launch, MCP passed 97 million monthly SDK downloads and roughly 10,000 live servers (MCP Blog). Every major AI app now ships first-class support: Claude, ChatGPT, Gemini, Cursor, Microsoft Copilot, and VS Code among them.

That's unusual for a protocol this young. Most integration standards take years to reach cross-vendor adoption, if they get there at all. MCP got competing AI labs to implement the same spec inside fourteen months.

How Has the MCP Spec Changed Since 2024?

Three times, each one a real shift, not a patch release.

2025-03-26 added structured OAuth-style authorization, replaced the original HTTP-with-SSE transport with Streamable HTTP, and introduced tool annotations. 2025-11-25 stabilized that work into what most production servers still run today. 2026-07-28 is the largest revision since launch. It made the protocol fully stateless. Every request now carries its own version and capabilities, so a server can run as a plain serverless function with no session state to manage (Model Context Protocol docs).

That last change is why "MCP servers need a long-running process" is now outdated advice. It was true in 2024. It stopped being true in mid-2026.

MCP vs Function Calling vs A2A: What's the Actual Difference?

These three get lumped together, and they solve different problems.

Standard	What it connects	Governed by
Function calling	A model to a single app's own tools	Each AI vendor, separately
MCP	A model to any tool or data source, across vendors	Agentic AI Foundation (Linux Foundation)
A2A (Agent-to-Agent)	One AI agent to another AI agent	Linux Foundation, separate project

Function calling came first. Every provider built its own version: OpenAI's function calling, Anthropic's tool use, Google's function declarations. A connector written for one didn't work with another. MCP standardized that layer so one server works everywhere.

A2A solves a different problem: agent-to-agent coordination, not agent-to-tool access. The two aren't competitors. A2A handles how agents talk to each other. Each agent still uses MCP to reach its own tools. Multi-agent systems commonly run both at once.

Is MCP Secure?

Not automatically. The protocol defines message shape and semantics. It doesn't vet what a given server does with the access you grant it.

The specific risk has a name: tool poisoning. A server hides instructions inside a tool's description text, and the model reads and follows them (OWASP). Treat any third-party MCP server like a dependency with write access to your systems. Check who ships it. Scope its token to the minimum it needs.

When Is MCP the Wrong Tool?

When you're integrating with exactly one AI provider and don't expect that to change. A direct API call or that provider's own function-calling format is less machinery for a single, fixed integration. MCP earns its overhead when multiple AI apps, or multiple tools, need to talk to each other without custom glue for every pair.

It's also overkill for a purely internal script with no AI model in the loop at all. MCP solves the model-to-tool handoff specifically. A cron job calling your database doesn't need a protocol built for letting a language model discover and call tools it's never seen before.

The Underused Angle: Vendor Neutrality Is a Build Decision, Not a Values Statement

Most explainers frame AAIF governance as a nice-to-have, a detail for the standards-committee crowd. It's actually a build decision with a concrete failure mode attached.

Pick a protocol one vendor fully controls. Your integration's lifespan ties to that vendor's incentives. Pick a protocol a neutral foundation stewards, backed by direct competitors who all have a reason to keep it fair, and that failure mode mostly disappears. When you're picking what to build AI integrations on, ask one question. Who can change the rules on you later, and do they have a reason not to?

Is There a Formal MCP Specification I Can Read?

Yes, and it's dated, not versioned like most software. Each release carries a calendar date instead of a number: 2025-03-26, 2025-11-25, 2026-07-28. The full text lives at modelcontextprotocol.io/specification, with every past dated version still published and browsable.

That dating scheme is deliberate. A client and server can name the exact spec revision they speak, in the _meta field of every request, with no ambiguity about what "MCP 2" would even mean. Read the spec itself before trusting a third-party summary, this one included. Standards drift in the retelling. The primary document doesn't.

Conclusion

MCP is an open, JSON-RPC-based protocol for connecting AI apps to tools and data, now governed by the vendor-neutral Agentic AI Foundation rather than any single company. It grew to 97 million monthly downloads in its first year and now ships in every major AI app. For a CMS, that governance model matters as much as the wire format: an MCP integration built today isn't tied to one vendor's product roadmap. Draftbase ships a 26-tool MCP server built against the current spec, with a hard draft-to-live wall so an agent can edit content without accidentally publishing it. See how MCP clients and servers work together for the connection mechanics, or check pricing to try it.