Dora NodaOn March 25, 2026, Anthropic's Model Context Protocol crossed 97 million monthly SDK installs — sixteen months after launch, roughly twice as fast as React's npm package took to reach 100 million. Every major AI provider now ships MCP-compatible tooling, and the protocol has settled the question of how an agent calls a tool.
It has not settled the question of whose computer answers.
That distinction is the whole story behind the number. Ninety-seven million counts client-side SDK downloads — the demand side. It says nothing about the supply side: the actual MCP servers those agents connect to, who operates them, and what trust you inherit when you point an agent at one. An increasing share of the ecosystem's servers run as someone else's hosted endpoint rather than infrastructure a team operates itself. This post is about what the installs number obscures, the two very different server sides behind it, and why running your own MCP server on hardware you control is a meaningfully different trust boundary than pointing an agent at a third party's.
What 97 million installs actually measures
Precision matters because the number gets quoted loosely. The 97-million figure is monthly SDK downloads — the Python and TypeScript client libraries combined — reported alongside Anthropic's March 2026 ecosystem update. It measures how many developers pulled the toolkit for connecting to MCP servers, not how many servers anyone runs. One widely cited retrospective put the comparison bluntly: the React npm package took roughly three years to reach 100 million monthly downloads; MCP did comparable scale in sixteen months, from its November 2024 launch to late March 2026.
The rest of the scoreboard fills in the demand picture. MCP earned 81,000+ GitHub stars, adoption by Anthropic, OpenAI (March 2025), Google DeepMind, Microsoft, Meta, and AWS, and — decisively for its longevity — donation to the Linux Foundation's Agentic AI Foundation in December 2025, co-founded by Anthropic, Block, and OpenAI with backing from Google, Microsoft, AWS, Cloudflare, and Bloomberg. That governance move is what turned "Anthropic's protocol" into vendor-neutral infrastructure, the precondition for every rival lab shipping compatible tooling.
On the supply side, the counts are fuzzier, and the fuzz is informative. One March 2026 guide counted 5,800+ community-built servers; infrastructure writeups the same month cited 10,000+ public servers in production; unofficial registries tracking the long tail counted closer to 17,000. The honest range is "thousands, counted differently by everyone" — and crucially, every one of those counts mixes together two fundamentally different things: a process on your own machine and an HTTPS endpoint on someone else's.
The two server sides: a process you own vs. an endpoint you rent
From the protocol's perspective, an MCP server is anything that answers tool calls. Operationally, servers split along two axes — transport and custody — that combine into very different trust postures.
Transport: local stdio vs. remote Streamable HTTP. A local server is a subprocess your agent client spawns over stdio: npx a package, hand it a token via environment variable, done. A remote server is an HTTPS endpoint speaking Streamable HTTP (the current transport; the older SSE transport is legacy), which any number of clients and teammates can share. The July 2026 specification release candidate pushed this further toward stateless HTTP — no mandatory initialize handshake, each request independently routable — which is exactly the shape that scales behind a load balancer.
Custody: vendor-hosted vs. self-operated. This is the axis the installs number hides. The remote servers most developers actually use are vendor-hosted endpoints: Linear's mcp.linear.app, Slack's and Figma's hosted servers, Azure DevOps' hosted service. You add a URL to mcp.json and you're done — but the server, its code, its update cadence, and its logs belong to someone else. The alternative is operating the server yourself: a container on your own machine serving /mcp behind your own reverse proxy, your own TLS, your own auth.
| Concern | Vendor-hosted endpoint | Self-operated server |
|---|---|---|
| Auth model | OAuth against the vendor's identity system | Your bearer token or your OAuth issuer |
| Token custody | Tokens often held server-side in the vendor's cloud | Tokens never leave infrastructure you control |
| Update control | Vendor ships; behavior can change under you | You pin the image; updates are your deploy |
| Audit trail | Whatever the vendor exposes | Every tool invocation in your own logs |
| Blast radius of compromise | Every tenant on the shared endpoint | Scoped to your deployment |
| Setup cost | One URL in mcp.json | A container, TLS, and auth you run |
Neither column wins on all rows — that is the point. The hosted endpoint wins on setup cost by a mile, which is why the ecosystem drifts toward it by default. The self-operated server wins on every row that matters once an agent's tool calls touch production data, credentials, or infrastructure. The installs number counts the clients making that choice; it cannot tell you how many chose each column.
The trust boundary, with numbers
"Different trust boundary" sounds abstract until you attach the incident data. Three findings from 2026 audits make it concrete.
Your tokens live on their machines. When a hosted connector runs from a vendor's cloud — Anthropic's documentation is explicit that custom remote connectors connect from Anthropic's cloud, not from your device — the OAuth tokens authorizing your agent's tool calls are held server-side, outside your custody. That is not a vulnerability; it is the architecture. But it means the trust boundary for every tool call includes the vendor's token store, their access controls, and their incident response — none of which appear in your threat model unless you put them there.
The servers themselves are frequently hostile or sloppy. A CSA Labs scan published in May 2026 covered 1,899 MCP servers and found a 5.5% tool-poisoning rate — hidden instructions smuggled inside tool descriptions that ride into the agent's context window alongside your system prompt and credentials. Zero percent of scanned servers shipped security documentation. Separately, an Ox Security audit covered by VentureBeat found 200,000 MCP servers exposing a command-execution flaw that Anthropic classifies as intended stdio behavior — which is precisely the problem: a local server you installed is arbitrary code execution by design, and the protocol has no verification layer between "server the developer installed" and "instructions the agent obeys." Add rug pulls — a benign server updating into a malicious one, with no definition hashing to catch the mutation — and the supply-chain picture is one where pointing at a third party's endpoint, or npx-ing a stranger's package, inherits risk you cannot audit from the client side.
The protocol's answer is auth it cannot enforce for you. The current specification treats a remote MCP server as an OAuth 2.1 protected resource with discovery metadata, and the July 2026 candidate adds protocol-level token audience restriction. That is the right direction — scoped, attributable, least-privilege tool calls. But it is a standard, not a deployment: it only protects you if the server you call actually implements it, and a self-operated server where you control the issuer is the one configuration where you can verify that end to end rather than taking a vendor's word for it.
What self-hosting your own MCP server concretely takes
The good news is that the self-operated column of the table is a weekend project, not a platform migration — because a remote MCP server is, at its core, just an HTTPS service. The pattern production deployments converge on:
- Package the server as a container exposing Streamable HTTP on
/mcp, stateless per request per the current spec, so it can sit behind any reverse proxy and scale horizontally. - Terminate TLS at your own reverse proxy (Nginx, Envoy, Caddy — whatever already fronts your services) with org network policies applying unchanged.
- Put real auth in front of it. This is the gotcha that bites everyone: most self-hosted servers default to a static bearer token, which OAuth-only clients reject. Budget for either a proper OAuth 2.1 issuer with dynamic client registration or a small auth gateway that bridges the two. The token that authorizes tool calls against your data deserves the same issuer discipline as any other production credential.
- Treat it as the single source of truth for your team. One deployed instance serves the whole org; a tool update is a container redeploy, not a per-developer
npxupgrade scattered across laptops — which also closes the rug-pull window, since the image hash you deployed is the code that runs.
That is it. No new platform to buy, no control plane to adopt — a stateful-services-shaped deployment your existing infrastructure already knows how to run. The payoff is that every row in the earlier table flips to your column: tokens in your custody, updates on your schedule, invocations in your logs, blast radius bounded by your network policy.
The installs number measures demand; custody is the open question
Ninety-seven million installs in sixteen months means the client side of agent tooling is settled infrastructure — as settled as anything in this industry gets. But clients are only half of a protocol. Every one of those SDK downloads eventually calls a server, and the ecosystem's center of gravity is drifting toward servers operated by someone else: convenient, one URL, tokens in their cloud, updates on their schedule, tool definitions you did not write flowing into your agent's context window.
That is a fine default for prototyping and a questionable one for production. The teams that will operate agents safely are the ones that treat the MCP server as infrastructure they run — pinned, logged, authenticated, and audited — rather than a URL they consume. The protocol won; now go operate your half of it.
Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. An MCP server is exactly that shape: a container behind TLS with real auth. Star the repo on GitHub or deploy your first app today.
