Half of the MCP packages on npm are used fewer than a thousand times a week

We measured 343 packages. The median gets 634 downloads a week, 55% are under 1,000, and 41 recorded none at all. What that distribution means for anyone choosing a server.

2026-11-03 2 min read The avbbc desk mcpdatanpm

Every directory ranks. Almost none publish the shape of what they are ranking. So here is ours, measured across the 343 npm packages that currently pass our evidence rules.

The numbers

**Median: 634 downloads a week.** The 25th percentile is 107. The 75th is 5,260. The 90th is 21,614.

**190 of 343 (55%) are under a thousand downloads a week.** **41 (12%) recorded zero** in the last seven days. **16 (5%) clear a hundred thousand.** The largest is 2.27 million.

That is not a healthy pyramid. It is a long tail with a spike at the end — the same shape as the rest of npm, and the same shape as most open-source ecosystems once a protocol becomes cheap to implement.

Why the tail is this long

An MCP server can be a wrapper around an existing CLI. That is the point of the protocol and also the reason the population is enormous: publishing one takes an afternoon, and there is no reviewer at the door.

Compare with a plugin store: the listing fee, the review queue, and the compatibility testing all filter the tail before you see it. npm does none of that, so what you see is the real distribution, not a curated one.

What the number does not mean

Low downloads do not mean a package is bad. A server that wraps an internal API might be used by twelve people and be exactly right. A library that is always installed as a dependency never appears as a direct download.

High downloads do not mean it works. A package can be pulled in transitively and never used directly, which inflates the count without telling you anything about the tool.

**Download counts measure installs. They do not measure maintenance, correctness, or fit.**

What actually predicts a working install

Three things, and they are checkable in ten minutes:

**A commit or release in the last six months.** Old code with no issues is often finished; old code with unanswered issues is abandoned. You have to look at both.

**Documentation that names the transport.** A stdio server and an HTTP server are installed differently, and a README that does not say which one is a README that will cost you an hour.

**An install command that still resolves.** Run it before you configure anything. Renamed and unpublished packages are not rare.

Those three are the difference between the two tiers on our MCP index: reviewed entries had a person do them, and the package table is the population without that check.

The honest caveat

This is a snapshot of one week in one registry. Packages move; a quiet package can become the dependency everyone adopts next quarter. That is why the dataset carries a generation timestamp instead of a permanent ranking.

Keep reading

All notes