What 156 MCP packages on npm actually look like

We compiled every npm package that declares an MCP server, then measured the distribution. The median package gets 4,517 downloads a week. Thirty-four get none.

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

Directories rank. They rarely tell you what the population looks like. So we measured ours: every npm package we could verify declares an MCP server executable and carries an mcp keyword, 156 of them at the time of writing.

The distribution, in one paragraph

The median package gets **4,517 downloads a week**. The 25th percentile is **193**. The 75th is **31,068**, and the 90th is **110,135**. Fifty packages — almost a third — are under a thousand downloads a week. Eighteen clear a hundred thousand. And **thirty-four have zero recorded downloads in the past week**.

That last number is the interesting one. A package with zero weekly downloads is not necessarily broken or abandoned. It is more often a package that was published, announced once, and never picked up — or one that is a dependency of something larger and never installed directly.

Why the tail is this long

Three mechanisms produce it, and none of them are unique to MCP.

**The protocol is cheap to implement.** An MCP server can be a hundred lines wrapping an existing CLI. That lowers the barrier to publishing, which is good, and lowers the barrier to publishing something nobody needed, which is the tail.

**npm publishes are one command.** There is no review, no listing fee, no gate. Contrast with a plugin store, where the friction filters the tail before you see it.

**Keyword squatting is real but small.** Some packages tag themselves mcp without being servers. We filter those out — a package with no executable is not a server, whatever its keywords say — but the filter only removes the obvious cases.

What this means if you are choosing

Download counts measure installs, not quality. A high number can mean a popular tool or a transitive dependency pulled in by something else. A low number can mean a new project or an abandoned one. Neither number tells you whether the server works with your client today.

What actually predicts whether a package works is narrower: does the repository have commits this quarter, does the README document the transport, and does the install command still resolve. We check those three before anything goes in the reviewed tier, and the difference between reviewed and listed in our directory is exactly that check.

The honest caveat

These numbers are a snapshot of one query against the npm registry at one moment. They move weekly, and a package that is quiet today can be the dependency everyone adopts next month. That is why the dataset carries a generation timestamp and the pages carry verification dates rather than a permanent ranking.

If you want to check the current shape yourself, the JSON is open: the dataset has every package with its version, license, and download count.

Keep reading

All notes