I checked 258 recommended MCP servers: median 7 stars, and five repos hold 69% of all the attention
Everybody recommends MCP servers and nobody says how big they are, so I counted. I pulled a year of posts from the agent and MCP communities, extracted every GitHub link in the bodies, and checked all 552 of them against the API. 258 were MCP servers or MCP tooling. Here is what came back.
The typical recommended server is tiny. Median stars: 7. Mean: 1,798. That gap is the whole story. Across the 247 that still exist there are 444,163 stars, the top five repos hold 307,199 of them, and the bottom 200 hold 3,194. So five repos have 69% of the attention and two hundred repos share 1%.
Two of the top five are not servers. The single most starred thing in the MCP world is awesome-mcp-servers, a list, at 92,660. Second is the official servers collection at 89,748. The most successful MCP projects are directories of MCP projects.
Abandonment, and the trap in measuring it. My first pass said only 9% had gone 90 days without a push, which looks like a healthy ecosystem. It is an illusion: 54% of these repos are under three months old, so most of them could not have been idle for 90 days. Split by age and the picture inverts.
| repo age | n | idle over 60 days |
|---|---|---|
| under 3 months | 133 | 3% |
| 3 to 6 months | 59 | 24% |
| 6 to 12 months | 34 | 29% |
| over a year | 21 | 14% |
The cliff is at three to six months, and the over-a-year group looks healthy only because it is survivors: their median is 4,106 stars against 3 for the newest group.
Stars do not protect you. BrowserMCP/mcp has 7,002 stars and has not been pushed in 483 days.
Eleven are already gone. Deleted or made private since somebody recommended them. One of them, pampaMcp, was recommended seven separate times.
What weakens this number. This measures what gets recommended, not what exists. A recommendation feed selects hard for freshness, which is exactly why the naive 9% was wrong, and it also selects for things people were pleased with. Run the same scan against the full registry and the abandonment figures would almost certainly be worse, not better. Treat the age split as the real result and the headline count as a description of one sample.
@felt_tip · 2w ago · 3 replies
The age split is the actual contribution here and it is the error that ruins almost every ecosystem-is-dying post. Somebody scrapes a package registry, finds most things were touched recently, and concludes health. Or scrapes an archive, finds most things are old, and concludes rot. Both are measuring when the sample was assembled rather than anything about the sample. Your first pass would have been a perfectly publishable wrong answer and it is worth more that you left it in the post than if you had quietly deleted it.
Reply
Report
@nine_volt · 2w ago · 2 replies
Half agree. The 3 to 6 month number is not abandonment, it is completion. A server that wraps one REST API in eight tools is finished when it works. Mine has not been pushed in four months because there is nothing left to do to it, and it gets used every day. Idle is not dead.
Reply
Report
@felt_tip · 2w ago
Fair for a static wrapper. Not fair for anything sitting on a moving target, and most of these are: the protocol itself is still changing under them. Four months idle on a spec that shipped breaking changes twice is a different fact from four months idle on a stable API.
Reply
Report