MCP Crossed 97 Million Installs — Why Every Developer Needs to Know This

If you've been building with AI for the last year, you've probably hit the same wall — you connect your agent to one tool, then rebuild the entire integration when you switch models. A connector that works with Claude breaks with GPT. Something built for Gemini needs to be rewritten for Cursor. The integration layer is chaos.
The Model Context Protocol (MCP) was built to end that cycle.
The idea is straightforward: one universal protocol connects any AI model to any tool, once. You build the server once, it works everywhere. If a model supports MCP, it speaks your language — no rewrites, no glue code, no vendor lock-in.
What MCP Actually Is
MCP isn't just another API wrapper. It's a standardized, open protocol for connecting AI agents to external data sources and tools — built on JSON-RPC 2.0, designed specifically for agentic workflows, and now governed by the Linux Foundation.
Before MCP, every AI integration was a one-off. A connector built for OpenAI wouldn't work with Claude or Gemini without a full rebuild. MCP standardized the interface, so a tool integration built today works with every compliant model tomorrow.

The four pillars of MCP
| Pillar | What It Means |
| Universal Interface | One server implementation works across all MCP-compatible AI clients |
| Open Standard | MIT-licensed, no fees, no vendor lock-in — anyone can build without asking permission |
| Agentic-First Design | Built for streaming, lifecycle management, and capability discovery that agentic workflows need |
| Dual Transport | stdio for local development, Streamable HTTP for production cloud deployments |
The last point matters more than it sounds. Traditional API integrations are synchronous and stateless. MCP's design handles the long-running, multi-step workflows that real AI agents actually run — not just a single function call, but a conversation between a model and a live system.
The Number That Defines a Standard
MCP launched in November 2024 with roughly 2 million monthly SDK downloads. By March 2026, that figure had crossed 97 million — a growth rate of 4,750% in 16 months.
For context, Kubernetes — now considered foundational cloud infrastructure — took nearly four years to reach comparable deployment density. MCP did it in 16 months.
But raw download counts tell only part of the story. The deeper signal is ecosystem convergence:
- OpenAI adopted MCP in March 2025 across the Agents SDK, Responses API, and ChatGPT Desktop
- Google DeepMind followed in April 2025
- Microsoft integrated it in May 2025 across Windows 11 and Copilot Studio
- 10,000+ active MCP servers now cover databases, CRMs, cloud providers, developer tools, and enterprise platforms
When every major AI lab ships MCP-compatible tooling, building anything else means fragmentation. The protocol war is over.
The Governance Shift That Made Enterprises Commit
Adoption numbers matter, but what convinced enterprise architects to go all-in was what happened on December 9, 2025.
Anthropic donated MCP to the Agentic AI Foundation, a directed fund under the Linux Foundation. Co-founders include Anthropic, Block, and OpenAI. Platinum members include AWS, Google, Microsoft, Cloudflare, and Bloomberg.
Before this, any enterprise evaluating MCP had one rational hesitation: what happens if Anthropic pivots, gets acquired, or changes its priorities? The Linux Foundation's track record — stewarding Linux, Kubernetes, Node.js, and PyTorch — answers that question with decades of precedent.
MCP is no longer Anthropic's protocol. It's the industry's protocol.
For regulated industries, this distinction is critical. For Bloomberg's financial services infrastructure, the governance shift was specifically about compliance — as an open standard governed by the Linux Foundation, MCP can now be deployed in compliance with regulated financial services requirements. A single-vendor protocol could never credibly clear that bar.
How the Ecosystem Is Structured
Understanding MCP requires understanding its three moving parts:

The Host is any AI application — Claude Desktop, Cursor, VS Code, ChatGPT. It creates MCP client sessions and connects to servers on behalf of the model.
The Client lives inside the host and maintains a stateful JSON-RPC channel with each MCP server. One host can run multiple isolated clients simultaneously.
The Server is where the actual tool logic lives. It exposes capabilities — tools, resources, and prompts — that the model can discover and invoke. Your GitHub server, your Postgres server, your Slack server. Each one built once, usable by any MCP-compatible model.
A clean MCP server architecture looks like this:
mcp-server/
├── src/
│ ├── tools/
│ │ ├── query.ts
│ │ ├── write.ts
│ │ └── search.ts
│ ├── resources/
│ │ └── schema.ts
│ └── index.ts
├── package.json
└── README.md
Authentication — The Most Common Stumbling Block
You cannot expose sensitive tools without authentication. Here's how production MCP deployments handle it:
OAuth 2.1 with PKCE — the current normative standard for remote MCP servers. MCP servers operate as OAuth Resource Servers and advertise their authorization server location through .well-known endpoints. Your existing Auth0, Okta, or Microsoft Entra ID stays as the source of truth — MCP plugs in without replacing your IdP.
STDIO with local trust — for local MCP servers running on a developer's machine, stdio transport inherits the process trust model. No auth needed, because the server only accepts connections from the same machine.
API key scoping — simpler MCP servers (internal tools, dev environments) commonly use environment-variable API keys with read/write scope separation. Fast to implement, adequate for lower-risk use cases.
Don't defer authentication. The most common MCP security mistakes happen when teams launch quickly with no auth and never go back to add it.
Drift Detection — The Overlooked Superpower
One of MCP's underappreciated capabilities is capability discovery. An MCP client doesn't need to know in advance what a server can do — it asks. The server advertises its tools, resources, and prompts at connection time.
This means two things in practice:
- Your AI agent can navigate a dynamic tool ecosystem without hardcoded function lists
- Adding a new capability to a server immediately makes it available to every connected agent — no redeployment, no config update
Most production deployments combine this with observability tooling. New Relic, among others, now offers MCP-specific monitoring. You can track which tools are being called, by which agents, with what frequency — exactly the visibility you need when an agent starts making unexpected tool calls at 2 AM.
Multi-Model and Environment Promotion
Most serious AI deployments in 2026 span multiple models and multiple environments. MCP handles this cleanly.
Cross-model portability — the same MCP server works identically whether your agent runs on Claude, GPT-4o, Gemini, or any other compliant model. Switch models without touching your tool integrations.
Environment promotion — the cleanest pattern runs separate MCP server instances per environment (dev, staging, production) with identical interfaces but different backing systems. Your dev server points to a test database. Your production server points to the real one. The agent code is unchanged.
Capability versioning — as your MCP servers evolve, maintain backward compatibility in capability schemas. Agents depending on your server shouldn't break when you add new tools.
Security — What the Growth Curve Missed

MCP's explosive adoption hasn't been without security debt. Security researchers have documented real vulnerabilities that developers need to understand:
Authentication gaps — many MCP server implementations still default to no authentication. Session IDs appearing in URLs violate basic security hygiene.
Prompt injection via tool descriptions — a compromised or malicious MCP server can inject instructions into the model's context through tool descriptions, potentially hijacking agent behavior.
Supply chain risk — CVE-2025-6514 in the mcp-remote package compromised over 437,000 developer environments through a shell command injection vulnerability embedded in a widely-used npm package.
Most teams configure their MCP environment to audit tool calls before they execute, rather than letting the agent call tools autonomously without logging. Build operational visibility first, then expand autonomy as you gain confidence in your server implementations.
Why It Matters: The Business Case
| Benefit | What It Looks Like in Practice |
| Faster agent deployment | One MCP server serves all compliant models — no per-model rebuilds |
| Lower integration costs | Multi-tool agent deployments estimated 60–70% faster to build with MCP vs. custom integrations |
| Better auditability | Every tool call is a structured, loggable event — exactly what compliance teams need |
| Ecosystem leverage | 10,000+ existing MCP servers — your stack is probably already covered |
Gartner forecasts that by end of 2026, 75% of API gateway vendors will include MCP support. Organizations that haven't built MCP familiarity into their engineering teams will spend 2027 catching up.
How to Get Started
1. Start with a local server. Pick one internal tool — a database, a Slack channel, a GitHub repo. Build a minimal MCP server using the TypeScript or Python SDK. Connect it to Claude Desktop or Cursor. Get comfortable with the client-server model before scaling.
2. Understand the transport layer upfront. Local development uses stdio. Production deployments need Streamable HTTP. Decide your deployment target early — switching transports later means redesigning your server.
3. Solve authentication on day one. Don't ship an MCP server to production without auth. OAuth 2.1 if you have an existing IdP. API key scoping if you need something simple fast.
4. Use the existing ecosystem. Before building a custom server, check the MCP server registry. Over 10,000 servers exist — Google Drive, Slack, GitHub, Notion, Jira, Postgres, Salesforce. There's a good chance yours is already there.
5. Add observability early. Instrument your MCP servers with structured logging from day one. Knowing which tools get called, by which agents, with what inputs is invaluable when debugging unexpected agent behavior.
6. Expand to multi-model once your first server is stable. Once you've validated your server with one model, test it against others. MCP compliance is high but not perfect — finding edge cases early is much cheaper than finding them in production.
Final Thoughts
MCP in 2026 is not a niche protocol for AI researchers — it's the integration layer that serious engineering teams are converging on. The tooling is mature. The governance is solid. The ecosystem has real breadth. The business case is clear.
The real shift is architectural: your AI integrations are built once and owned by the tool, not rebuilt for every model you evaluate. "Which AI can work with our stack?" becomes "our stack works with any AI."
If your team is still building model-specific integrations and one-off connectors, 2026 is the year to change that. The protocol that makes AI interoperable is already here — and 97 million developers are already using it.
Written by
