As of late June 2026, the Model Context Protocol is downloaded 97 million times a month. Nineteen months after Anthropic published the spec, MCP isn't a debate — it's a dependency. Every frontier-model vendor, every major IDE, and one Pinterest team booking seven thousand engineering hours of monthly savings all ship against it. The interesting question is no longer should you use MCP — it's what fails at this scale.
The numbers
| Metric | Value | As of |
|---|---|---|
| Monthly MCP SDK downloads | 97 million | May 2026 |
| Registry server records | ~10,000 latest (9,652 / 28,959 with versions) | May 24, 2026 |
| Pinterest production invocations | 66,000 / month across 844 active users, ~7,000 eng hours saved | April 2026 |
Three numbers, one story. A protocol launched in November 2024 now ships in nine-figure download counts; its public registry holds ten thousand canonical servers and three times that when you count version records; and at least one large engineering organisation has put a hard, audited number on what MCP is actually saving them. None of these are speculative — they are pulled from upstream registries, Anthropic's own telemetry, and a Pinterest engineering post — and together they describe a protocol that crossed the gap from "interesting standard" to "load-bearing infrastructure" without an obvious tipping point. The growth is the story; the absence of a competitor in the same chart is the subtext.
What MCP actually is
stdio or HTTP ↔ servers ↔ real-world targets.An MCP host is the program with the model in it — Claude Desktop, Cursor, VS Code, the OpenAI Agents SDK, your own application. Inside the host, one MCP client talks to each MCP server through a JSON-RPC session. The server fronts a real-world capability: a Postgres database, a GitHub repo, a filesystem, a SaaS API. The model never touches the target directly; the server exposes a typed surface — tools the model can call, resources it can read, prompts it can summon — and the host marshals that surface into whatever its model expects to see.
The transport is where MCP stays small. The spec defines exactly two transports: stdio for local processes (the host spawns the server as a child and pipes JSON-RPC through stdin/stdout) and HTTP with optional Server-Sent Events for remote servers. Both layers are intentionally boring. The interesting work happens above the transport — capability discovery, typed tool I/O, lifecycle handshakes — which is also why the protocol could land cleanly into existing tool-calling stacks rather than requiring a parallel runtime. See MCP: hosts, clients, servers for the participant model in detail.
What MCP is not is the model's tool-calling API. The model still does function calling in its own dialect — OpenAI tools, Anthropic tools, Gemini function declarations — and the MCP client translates between that dialect and the server's typed schema. MCP is the wire between the host and the tool provider, not the wire between the model and the host. That separation is why the same MCP server can serve a Claude session in Cursor, a GPT-5 session in the OpenAI Agents SDK, and an agent loop you wrote yourself, without any of the three knowing what the others are running. For the broader interop story, see tools, actions, and environments.
Why it won
Neutral specification with first-mover advantage
Anthropic published a spec, not a product. The November 2024 release shipped the wire format, a reference implementation, and an SDK in three languages — and then stopped. There was no "MCP Cloud," no proprietary registry, no Anthropic-only capability that other implementers had to negotiate around. The spec was also good enough on its first iteration that the early servers built against the pre-1.0 draft mostly still work; the protocol didn't go through a public reformat. First-mover advantage in standards is largely about avoiding the second-mover's fork, and a spec that doesn't need its own rewrite is the cheapest way to deny that fork.
Cross-vendor uptake
Within eighteen months the protocol was supported by every party that mattered. Anthropic shipped it first; OpenAI added MCP support to the Agents SDK and ChatGPT; Google integrated MCP into Gemini's tooling and Vertex; Microsoft built MCP into Copilot Studio and the Windows agent surface; GitHub published a first-party MCP server and added MCP to Copilot; Vercel exposed MCP through its AI SDK; VS Code and Cursor both became MCP hosts. Nine vendors — Anthropic, OpenAI, Google, Microsoft, GitHub, Vercel, VS Code, Cursor, ChatGPT — now ship MCP as a first-class integration. None of them gain anything by forking it, and that absence of incentive is what locks the protocol in. The vendor-support matrix below is the comparison artifact; the prose treats the protocol as one subject because that is what it has become.
Linux Foundation handover
In 2026 MCP moved under the Linux Foundation's new Agentic AI Foundation, joining LF AI & Data's portfolio of neutrally governed protocols. The handover did the work that the spec's permissiveness only suggested: it removed single-vendor risk on paper. An OpenAI engineer working on the spec now contributes to the same governance process as an Anthropic one; a Microsoft platform team can ship MCP as a load-bearing dependency without the political reading that Anthropic gets a veto. Foundations don't make protocols better technically — they make them politically safe to depend on, which is what an infrastructure protocol needs.
var(--accent)) means a first-party shipping integration; medium means partial or preview; weak means external/community-only. The row is what matters; the absence of an empty row is the story.What still breaks at scale
Transport scalability
The stdio transport is fine for one server and a developer machine. It is not fine when a host wants to keep ten or twenty servers warm at once — each one is a long-lived child process, holding its own runtime, its own connection pool, its own memory pressure. The HTTP transport solves the process count but not the connection model: long-lived JSON-RPC sessions over HTTP+SSE pin a server-side connection per active client, and registries with ten thousand servers cannot economically host stateful sockets at that fan-out. What breaks in practice is the host's startup time and the registry operator's bill — neither failure shows up as a protocol error, both as user-visible latency and unit-economics pain. The 2026 roadmap names transport scalability as the single largest open problem, and it is.
Registry trust and supply chain
An MCP server is an executable that the host runs with the user's privileges and the user's data. The registry holds roughly ten thousand of them. There is no built-in signing, no canonical publisher identity, and no organic mechanism to retire abandoned packages. Typo-squatting on the registry — github-mcp versus github-mcp-server versus mcp-github — is exactly the npm failure mode reproduced one ecosystem later, and the consequences are worse because an MCP server's natural surface is "read your files, call your APIs, write your data." Until the registry ships package signing and publisher identity (work the maintainers have flagged but not landed), the safest production posture is to pin to a known commit hash from a known organisation and treat the registry as a discovery aid, not a trust root.
Server sprawl and discoverability
Fifteen thousand nine hundred GitHub repositories carry the mcp-server topic. The registry holds about ten thousand canonical entries. For any non-trivial task — "give me a Postgres MCP server with read-only mode and audit logging" — there are eight plausible candidates, four of them last updated in 2025, two of them forks of forks. Semantic search over server descriptions narrows the field but doesn't actually solve the problem, because the question the user is asking is "which of these will still be maintained in six months." That is a social signal, not a textual one, and the registry doesn't yet expose the signals — download trends, recent commits, maintainer activity — that would let a host present a meaningful default. See capability discovery for the runtime side of the same problem.
Governance and auth
The spec defines what a server can do; it says far less about who is allowed to make it do that. Server-side permissions are an implementation detail of each server; OAuth flows for remote servers are still being standardised in the 2026 spec drafts; capability delegation — "this agent may read GitHub but not write" — has no canonical wire representation. What breaks at scale is enterprise rollout: a security team that would happily approve a single audited server cannot approve "any of ten thousand," and the protocol gives them no leverage to gate at the host level. The 2026 roadmap calls this enterprise readiness; the practical word is authorisation.
The 2026 roadmap
Transport scalability. The roadmap's top priority is making the HTTP transport hold up at registry-scale fan-out: better streaming semantics, optional stateless session modes, and clear guidance on when to use which transport. The intent is to retire stdio as anything but a local-development affordance.
Agent-to-agent communication. MCP today is host-to-server. The next layer is agent-to-agent — one agent calling another as a peer rather than as a tool — with its own discovery, identity, and task lifecycle. The work is happening alongside Google's A2A protocol rather than against it; the convergence question is open. See agent-to-agent communication for the design space.
Governance maturation. Package signing, publisher identity, and a deprecation lifecycle in the registry; standardised OAuth flows in the spec; clearer rules for capability delegation. None of this is technically novel — it is the work every package ecosystem has had to do, on the schedule MCP's adoption is forcing.
Enterprise readiness. Audit logging conventions, RBAC patterns, secret-handling guidance, deployment recipes for the host-as-policy-enforcement-point pattern. Less protocol work than documentation and convention work, but the kind of convention work that decides whether MCP ships inside a Fortune 500 or stays at the team-experiment layer.
FAQ
Is MCP just function calling?
No. Function calling is the model-side primitive — the model emits a structured request, the host runs the function, the result comes back. MCP is the wire between the host and the tool provider: it lets a single server expose its tools to any MCP-compatible host without per-model bindings. The function-calling layer still exists; MCP sits one box to its right.
Do I have to write a server in TypeScript?
No. The reference SDKs cover TypeScript, Python, Rust, Go, Java, C#, Swift, and Kotlin at the time of writing, and the wire protocol is JSON-RPC, so a server in any language with an HTTP or stdio toolkit is trivially possible. Most production servers are Python or TypeScript because that is where the maintainer mindshare is, not because the protocol demands it.
Can I use MCP with non-Anthropic models?
Yes — that is the entire point of MCP being a protocol rather than a Claude feature. GPT-5, Gemini, Mistral, Llama, Qwen, and DeepSeek all run inside hosts that speak MCP. The host translates between the model's native tool-calling dialect and the MCP server's typed surface; the model itself does not need to know MCP exists.
What's the difference between MCP and OpenAPI?
OpenAPI describes an HTTP API for humans and code generators. MCP describes a typed, stateful session between a model host and a capability provider, with first-class concepts the model needs — tools, resources, prompts, lifecycle, capability discovery. You can put an OpenAPI service behind an MCP server, and many do; the inverse rarely makes sense because MCP carries semantics that OpenAPI doesn't.
Is MCP secure by default?
No. An MCP server runs with the privileges of the host process and has access to whatever the host hands it. Treat every server like an executable from npm: pin to a known publisher and version, scope its access (filesystem roots, API keys) as narrowly as possible, and assume the registry is a discovery aid, not a trust root. The 2026 spec work on signing, OAuth, and capability delegation is closing this gap, but the gap is real today.
Will Google or OpenAI fork it?
They have had eighteen months and neither has. Both ship first-party MCP support in their flagship products and both contribute to the spec process under the Linux Foundation's Agentic AI Foundation. The incentive to fork — controlling a key piece of agent infrastructure — is dwarfed by the cost of fragmenting the registry, which is the asset that makes MCP valuable to their own users. Convergence is the equilibrium; a fork would be a self-inflicted wound.
Further reading
On this wiki:
- MCP: hosts, clients, servers — the participant model, JSON-RPC lifecycle, and transports in detail.
- Why interop matters: the M×N problem — the structural argument MCP solves.
- Building an interoperable agent — when to reach for MCP vs A2A vs raw tool calling.
- Capability discovery and negotiation — the runtime side of the discoverability problem.
- Tool calling explained — the model-side primitive MCP sits next to.
Project sources:
- modelcontextprotocol.io — the canonical spec site, SDKs, and reference servers.
- github.com/modelcontextprotocol — the spec repository, the SDKs, and the 2026 roadmap discussion threads.
- MCP Registry — the canonical server registry; the source for the ~10,000-server count.
- Pinterest Engineering — publisher of the April 2026 MCP production write-up cited above.
- Anthropic — Introducing the Model Context Protocol — the November 25, 2024 launch post.
- Linux Foundation — home of the Agentic AI Foundation; the neutral governance handover announcement is hosted here.