MCP: AI’s “USB-C” moment

How a protocol got adopted this fast

In November 2024, Anthropic released an open standard called the Model Context Protocol (MCP). Thirteen months later, in December 2025, Anthropic handed governance of it over to the Agentic AI Foundation under the Linux Foundation, meaning MCP stopped being one company’s specification and became a community-owned standard, the same way Linux, Kubernetes and other critical infrastructure eventually did. By March 2026, monthly SDK downloads had gone from 100,000 to 97 million (source: Knak), and OpenAI, Google, Microsoft and Amazon had all shipped support for it.

The problem it was actually solving

Before MCP, every AI model that needed to talk to an external tool or data source needed its own bespoke integration for that tool. If you have N models and M tools, that’s N × M custom integrations to build and maintain, since every new model needs a fresh build against every tool it wants to use, and every new tool needs a fresh build against every model that wants to use it. It’s the classic “everyone invents their own adaptor” problem, and it scales badly: add one more model or one more tool and the number of integrations you owe doesn’t grow by one, it grows by however many models or tools already exist on the other side.

Without MCP, 3 models and 3 tools need 9 custom integrations; with MCP they need 6 reusable connections.

MCP collapses that into N + M. A model implements MCP once; a tool implements MCP once; from then on, any MCP-speaking model can talk to any MCP-speaking tool with zero custom work in between. That’s the whole USB-C comparison: different manufacturers, different devices, one shared interface instead of one cable per pairing.

What foundations actually do here

Handing a protocol to a foundation isn’t a branding exercise. It changes who gets to decide what MCP becomes next. Under the Linux Foundation, the Agentic AI Foundation runs an open governance process, with proposals, working groups and public specification drafts, rather than one vendor unilaterally deciding the roadmap. That’s what let Google, Microsoft and AWS ship input into the July 2026 specification (2026–07–28) alongside Anthropic: a shift to a stateless architecture, an MCP Apps extension for server-rendered UIs, a Tasks extension for long-running work, authorisation aligned more closely with OAuth/OpenID Connect, and a formal deprecation policy so future changes don’t break what’s already deployed. A foundation is what makes a spec “trustworthy enough to build a business on” instead of “trustworthy enough for a hobby project.”

What the ecosystem actually looks like

MCP has three moving parts: clients (the AI application, like Claude Desktop, an IDE, or a custom agent) that request context and tools; servers (thin adaptors in front of a database, SaaS tool or internal system) that expose what’s available; and the protocol itself, the shared language that lets any client talk to any server without a bespoke integration. As of mid-2026 there are reportedly 5,800+ public MCP servers and 300+ clients. That’s the ecosystem: not one company’s product, but a marketplace of interchangeable pieces.

An MCP client such as Claude Desktop, an IDE or a custom agent connects to a database, a SaaS tool and an internal system through the same protocol.

Every arrow in that picture is the same protocol call: the client sends a tools/call (or tools/list, or resources/read) request over JSON-RPC, and the server answers in the same shape whether it's fronting a Postgres database or a Salesforce instance. That uniformity is what lets one client swap between servers, or one server serve many clients, without either side knowing anything about the other's internals.

How fast is “fast,” really?

Here’s the comparison worth sitting with. TCP/IP, the protocol the entire internet runs on, was first drafted around 1974, formally standardised in RFCs 791/793 in 1981, and only became the ARPANET’s mandatory protocol on “flag day,” 1 January 1983. That’s roughly nine years from first design to universal cutover, inside a small, closed research network. HTTP took longer to formalise (1991 to RFC 1945 in 1996, about five years) but had a comparably small starting user base. MCP went from a single-company release to multi-vendor foundation governance in 13 months, and to a mature, versioned, backward-compatible specification in 20 months, across an open, competitive, commercial market, not a government-funded research network.

Years each protocol took to become the standard: TCP/IP 9 years, HTTP 5 years, USB 2 years, MCP 20 months.

That speed is the story. It’s also the risk. TCP/IP and HTTP had years of small-scale, low-stakes use before they carried the world’s traffic. MCP is being asked to carry enterprise data at global scale before its governance curve has caught up with its adoption curve, which is exactly where the trouble shows up: over 30 CVEs filed against MCP implementations in early 2026 alone, a cross-tenant data leak at Asana, a path-traversal flaw at Smithery that exposed thousands of apps, and tool-poisoning attacks against open-source servers.

Illustrative chart: MCP adoption rising faster than governance and security maturity from November 2024 to August 2026, leaving a gap.

The real concern isn’t the integration, it’s the opacity

Most write-ups frame MCP’s challenge as “will bespoke integrations become obsolete.” That’s the smaller problem. The bigger one: once an AI agent can reach into a dozen systems through a dozen MCP servers, you often can’t fully account for what data it touched, what it retained, or what shaped its answer. Tool calls happen inside the model’s reasoning, not in a place most teams are logging or reviewing by default. You’re not just worried about whether the integration works; you’re worried about whether you can explain, after the fact, what your AI actually did with the data it saw.

Why this matters for a PM, concretely, not abstractly

Take GDPR as the simplest, most immediate example, since almost any business with EU customers already has to think about it.

From a purely business angle, this is a first-mover edge hiding in plain sight: whoever architects their MCP layer with compliance built in gets to close enterprise deals faster, because “show me your AI audit trail” stops being a scary question. Right now most competitors are still bolting AI features onto products without touching this layer at all, which is a real gap. The businesses that treat MCP governance as a selling point rather than a cost centre will win the procurement conversations the others are quietly losing.

The opportunity:

MCP standardises how an AI agent requests data, which also standardises where you can insert a compliance checkpoint.
A single MCP gateway in front of your CRM, HRIS or support tooling can enforce field-level data minimisation.
It can log every tool call for an audit trail.
It can apply a documented lawful basis per data field, once, centrally, instead of per integration.
Done well, this makes GDPR compliance easier to demonstrate than a patchwork of custom API integrations, because the access pattern is uniform and inspectable.

The problem:

MCP itself doesn’t handle data protection, it’s a thin protocol for tools/list and tools/call, with no built-in controls against exfiltration, retention or cross-border transfer.
If your MCP server routes an EU customer record through a US-hosted server to a US-hosted model, you’ve triggered a cross-border data transfer with all the Schrems II baggage that implies.
If that server caches the payload along the way, you’ve quietly expanded your compliance exposure without writing a single line of “new” code.
From the outside, it still just looks like “the AI answered a question.”

Same protocol, same feature: opportunity and liability depending entirely on how deliberately it’s architected. That’s the actual decision in front of a PM evaluating MCP: not whether to adopt it, but whether your organisation is treating the governance layer as seriously as the integration layer.