There are eleven thousand MCP servers. The #1 server has roughly twice the adoption of the #2 server. And when you look at what makes it different, it’s not technical sophistication. It’s not more features. It’s that it solves exactly one problem, stated with surgical precision.

The server is called Context7. What it does: injects version-specific library documentation into AI context so the model stops hallucinating deprecated methods.

That’s it. One problem. One sentence description that every developer immediately recognizes as their own problem.

What the Description Actually Does

Context7 doesn’t call itself a “documentation server” or a “library reference tool.” Those are capability descriptions. They describe what the server is.

Context7 describes what it fixes: you ask an AI how to use a library, it gives you code from two major versions ago, and that code doesn’t work. You’ve spent fifteen minutes debugging something that was never going to work. Context7 exists to eliminate that specific fifteen minutes.

When a developer reads that description, there’s no translation step. They don’t have to figure out whether this applies to them. They’ve already experienced the problem. The server sells itself.

The 95% Positioning Gap

Here’s the part that surprised me. Of eleven thousand MCP servers, roughly 95% generate no revenue. Most of them are technically functional. Many are technically impressive. They just can’t explain why someone should use them.

This isn’t a capability gap. It’s a positioning gap.

The most common failure mode is describing what a server does instead of what problem it solves. “GitHub integration server” versus “automates PR review so you stop context-switching during code review.” Same underlying capability, completely different clarity about value.

The developers who earn $3k–$10k+/month from MCP servers aren’t building more sophisticated software than everyone else. They’re describing their software in terms of the pain it removes.

The Browser Automation Cluster

Three of the top ten MCP servers are browser automation tools. This seems counterintuitive — why would the same general category dominate three spots?

Because they’re not competing with each other. Each one has staked out a different specific pain:

  • One solves the “scrape structured data from pages that block traditional scrapers” problem
  • One solves the “automate repetitive browser workflows without writing Selenium” problem
  • One solves the “test UI interactions as part of an AI agent loop” problem

Same underlying technology. Completely different problems. Different customers who all feel like the tool was built specifically for them.

The lesson isn’t “build browser automation.” It’s that a single technology surface contains multiple distinct problems, and each problem is its own opportunity if you describe it specifically enough.

The Question to Ask First

When Context7 was designed, someone must have asked: “What is the single most specific problem we can solve for developers using AI?”

Not: “What should an MCP documentation server do?”

The first question leads to a product that fits one pain exactly. The second question leads to a product that partially addresses many pains and dominates none of them.

The eleven thousand servers mostly started with the second question. The ones that win mostly started with the first.

If you’re building an MCP server — or any developer tool — the useful exercise is to write one sentence describing the outcome your target user gets, in terms of something that currently frustrates them. Not what your tool does. What the user stops experiencing.

If you can’t write that sentence, you haven’t found the problem yet.