A study of 928 GitHub issues asking for MCP servers
In short
- 928 issues from five GitHub searches over twelve months, read for what people actually ask an MCP server to do.
- The largest cluster, ≈397 accounts, wants fewer tools in context — lazy loading, on-demand connection, per-agent scoping. That is a client feature, not a server anyone can sell.
- The next, ≈222 accounts, wants an official server for a named product, which only that product's vendor can credibly build.
- Our own idea, web fetch, drew ≈56 and already exists officially. The median small fetch-type package gets 58 downloads a month against 702 for other small servers.
- A need had to clear three tests to be worth building for — ≥20 distinct accounts asking, no official equivalent, and the biggest free implementation under 1 000 downloads a month. Nothing cleared them, and we dropped the product.
- 613 of the 928 stayed uncoded, and every theme count is an upper bound.
We were going to build a free URL-to-markdown MCP server and fund it with one sponsored line per result. Before writing any code we checked whether anyone needed it. They didn't, and the data says something more useful than that. The loudest unmet demand in MCP is for fewer tools in context, which is the opposite of what an ad-carrying tool adds.
Three tests decided it. A candidate need had to have ≥20 distinct GitHub accounts asking for it, not already exist as an official server or a built-in, and the biggest free implementation had to be under 1 000 downloads a month — a need already served by something free and popular is not a gap. Nothing cleared all three.
What follows from it. An ad-supported MCP server is the wrong product, and not because advertising inside a tool is unwelcome. The scarce thing in an agent's context is room, and every tool result that carries a sponsored line spends the exact resource operators are asking to get back. If you are building a tool for agents and funding it with attention, this is the demand signal to check first. It cost us a weekend of searching and saved the build.
What was counted
928 issues from five GitHub searches over twelve months, each capped at 300 results and
sorted by reactions: new-server requests in
modelcontextprotocol/servers, plus
"is there an mcp", "looking for … mcp" and "mcp server feature request" across public
GitHub. Demand per theme is issue authors plus 👍, which double-counts anyone who filed
twice, so every number below is an upper bound. 613 of the 928 stayed uncoded.
| theme | accounts (upper bound) | issues | verdict |
|---|---|---|---|
| MCP client features | ≈397 | 133 | not a server anyone can sell |
| "official server for product X" | ≈222 | 128 | only X's vendor can build it |
| web fetch / browse / search | ≈56 | — | official server exists, and the harnesses have it |
| memory | ≈32 | — | official server-memory exists |
| verification / provenance | ≈25 → 0–6 | — | mostly submissions, not requests |
| payments | ≈10 | — | too few accounts asking |
The client-features cluster is lazy loading, connecting servers on demand, scoping servers per agent, reducing context overhead, and auth. Read as a sentence, that is I have too many tools in my context and I want control over which ones are there.
The coding error, which nearly saved the project
Verification and provenance looked like the one open niche at ≈25 accounts. Reading the titles instead of counting keywords showed they were mostly people submitting verification servers, plus SSL-verify options in unrelated tools. Real demand is somewhere between 0 and 6.
The failure mode is general. Keyword coding cannot tell supply from demand. "MCP server for X" is written both by the person who wants X and by the person announcing X. It inflated the only theme that would have justified building.
And clones don't get installed
Separately, we measured what a new entrant in a crowded niche actually gets. The median
small fetch-type MCP package on npm sees 58 downloads a month, against
702 for other small MCP servers, while the official
mcp-server-fetch has 484 810 a month on PyPI. Being the
twentieth implementation of a solved problem is not a distribution strategy, even with a
free tier.
What we did about it
Dropped the server. The reasoning that killed it is the finding itself. An ad line in every tool result adds to the context bloat that the largest group of requesters is filing issues to escape. A placement that makes its host's product worse is not a placement, it is a tax, and the host eventually removes it.
Limits
- GitHub requesters are developers, not agents. What a developer asks for and what an agent does are different measurements, and this is the first.
- 👍 is a cheap signal, and accounts are not deduplicated across issues, so demand is an upper bound throughout.
- Search recall is unknown. Five queries are not the population of people who want an MCP server; they are the people whose phrasing matched.
- 613 issues were never coded, so the themes are a floor on diversity, not a partition.
- Not run: deduplicating reaction accounts, the MCP registry's own search logs, Smithery usage, GitHub Discussions.
If you are deciding whether to build an MCP server, the useful version of this study is the one run on your own question, not on ours. That is what we do for other people now.