What 97 Million Downloads a Month Actually Tells You

Ninety-seven million. That's roughly how many times the Python and TypeScript MCP SDKs get pulled every month, combined, as of mid-2026. It's the kind of number that gets dropped into a slide deck or a tweet as proof of arrival — MCP made it, case closed. I want to slow down on that number instead of using it as a mic drop, because download counts are one of the least trustworthy adoption signals in software, and MCP's case is a good teaching example of why.

Start with the obvious confound: a "download" isn't a decision. It's an artifact of how modern package managers work. Every CI run that installs dependencies from a lockfile triggers a download. Every fresh Docker build without layer caching triggers a download. Every developer who pip installs a package to try it once, hates it, and never touches it again triggers a download indistinguishable from one made by a team running it in production at scale. Multiply any of those by the number of repos with MCP in their dependency tree and you get a number that inflates fast without a single new production deployment happening.

The number that actually matters is different

If you're trying to gauge whether MCP is durable infrastructure or a hype cycle, downloads are the wrong metric. The registry count — 9,652 latest server records as of May 24, 2026 — is closer to the right one, because publishing and maintaining a server in a public registry is a much higher-commitment act than running npm install. Someone had to build the thing, document it, register it, and presumably keep it working. That's a stickier signal.

Even better than the registry count is composition. Of those 9,652 servers, more than 950 are business application servers — customer service, sales automation, internal operations tooling built by companies wiring MCP into their actual products. A download tells you someone was curious. A maintained business-application server tells you someone bet revenue on it. Those are very different claims, and only one of them predicts whether MCP is still standard practice in three years.

The same pattern shows up in every hype cycle you've already lived through

If this feels familiar, it should. Every major developer-tooling wave produces a version of the same misleading headline number, and MCP is simply the current instance. Docker Hub pull counts were treated as an adoption proxy for years, until enough people pointed out that a single CI pipeline running on every commit could generate more "pulls" in a month than an actual company's entire engineering org. npm weekly download counts get cited constantly despite being trivially inflated by transitive dependencies nobody chose directly — installing one popular framework can silently rack up download counts for dozens of packages a developer never consciously decided to adopt. GitHub star counts get gamed outright, and even organically, they measure a moment of interest, not sustained use.

None of those caveats stopped any of those numbers from being widely cited, because big numbers make better headlines than careful ones. The useful habit isn't refusing to cite adoption numbers — it's pairing the easy, inflatable number with the harder, stickier one every time, which is exactly the move this piece has been making with MCP's download count against its registry composition.

Why the number is still worth citing, carefully

None of this means 97 million is meaningless. Sustained high download volume across two separate language ecosystems, over many months, rules out the "this is a novelty that a few hundred people are playing with" hypothesis. If MCP were a dead-end experiment, the SDK pulls would have cratered after the initial curiosity wave — the way most GitHub-trending projects fade within a quarter. They haven't. Adoption breadth (Python and TypeScript both sustaining volume, not just one ecosystem carrying the number) is a real and useful signal.

The mistake is treating the raw figure as the finish line instead of as one input among several. Reading adoption numbers well means asking what behavior actually produced the number, whether that behavior correlates with the thing you actually care about, and what a second, harder-to-fake metric says about the same claim.

A framework for reading any adoption stat like this

When a vendor or an ecosystem throws a big download or install number at you, run it through three questions before you let it change your mind about anything:

What action produced this number, and how automatable is that action? CI pipelines, Docker builds, and dependency resolvers can all inflate download counts without a human ever making a considered choice. Registry listings, GitHub stars with meaningful READMEs, and production deployment counts are harder to automate into existence.

Is there a second, independent metric that should move in the same direction if the first one is real? For MCP, that's the registry growth curve and the enterprise-server share. Both climbing alongside the download number is much stronger evidence than the download number alone.

Who benefits from you believing the big number, and does their incentive change how the number was measured or reported? Anthropic and the Agentic AI Foundation both have reasons to want MCP's adoption story to sound overwhelming — that's not an accusation of dishonesty, it's just how incentives work, and it means the burden of interpretation sits with the reader, not the publisher.

A quick comparison that makes the point concrete

Think about how differently you'd treat two hypothetical numbers reported about the same underlying reality. "97 million SDK downloads a month" invites you to picture 97 million distinct decisions to adopt MCP — which is not what happened, and not what anyone reporting the number actually believes happened, but it's the intuitive read most audiences will default to unless someone stops them. "9,652 registry servers, of which 950-plus are business-application tooling built by identifiable organizations for production workflows" invites a much narrower, much more defensible picture: a few thousand real, ongoing bets on the protocol, a meaningful fraction of them made by organizations with something operational riding on the outcome.

Both numbers describe the same protocol at the same moment in time. They produce wildly different mental models of how deep the adoption actually goes, and only one of those mental models would survive someone actually going and counting. That gap is exactly why adoption metrics need to be read for what produced them, not just reported as a headline figure — the same underlying reality can be made to sound either overwhelming or modest depending entirely on which number you reach for first.

What this means if you're deciding whether to build on MCP

If your bar for adopting a protocol is "lots of people are using it," 97 million monthly downloads clears that bar easily — maybe too easily, since it would clear it even in a world where most of those pulls are CI noise. The more useful question is the one 9,652 servers and 950+ business-application listings actually start to answer: are other teams building things that depend on this protocol continuing to work, in ways that would be expensive for them to unwind? That's the adoption signal that predicts whether a standard sticks around, and it's a much smaller, harder-won number than the download count — which is exactly why it's more trustworthy.

The stateless rewrite that shipped on 2026-07-28 is itself a data point in this direction: a protocol doesn't get re-architected for cloud-scale load balancing unless real production traffic is hitting real scaling limits. Nobody rewrites core connection handling to placate CI runners.

None of this is a case against MCP — the underlying signals, read correctly, are genuinely strong. It's a case against letting the biggest, easiest-to-cite number do your thinking for you. The 97-million figure is a headline. The registry composition is the argument.

---

Part of the "MCP One Year In" series on aiskill.market.