The MCP Server Discovery Problem: Why Finding AI Tools Is Hard

The Paradox of Abundance

There are over 10,000 MCP servers available right now, spread across GitHub repositories, npm packages, dedicated registries, and community directories. On one hand, this is great. Whatever you want to connect your AI assistant to, there's probably an MCP server for it.

On the other hand, trying to find the right one feels like searching for a specific book in a library with no catalog system. Multiple servers might do similar things with different quality levels, different security practices, and different maintenance trajectories. The problem isn't availability. The problem is evaluation.

The Fragmentation Issue

MCP servers live in many different places. Some are listed on mcp.so. Others are on Smithery. Some exist only as GitHub repositories that you might find through a search. A few are distributed through npm. And new community directories pop up regularly.

Each directory has its own way of categorizing servers, its own quality thresholds (or lack thereof), and its own update cadence. A server might be listed in three directories with different descriptions, different version numbers, and different metadata. For a developer trying to make a decision, this fragmentation adds unnecessary friction.

The fragmentation isn't anyone's fault. It's the natural result of a rapidly growing ecosystem where the infrastructure for discovery hasn't kept pace with the production of tools. Solving it requires aggregation across sources, not replacing existing directories but layering a unified view on top of them.

Quality Signals Are Scattered

When you evaluate a traditional software package, you have several quality signals available. npm download counts tell you about adoption. GitHub stars indicate interest. Issue trackers show maintenance activity. Dependency analysis reveals supply chain health.

For MCP servers, these signals exist but they're scattered and incomplete. A server published as an npm package has download stats, but one distributed as a Python script on GitHub doesn't. A well-starred repository might have been abandoned months ago. A server with few stars might be excellent but new.

No single signal tells you whether an MCP server is trustworthy, well-maintained, and suitable for your use case. You need to look at multiple signals together: maintenance recency, dependency health, author reputation, community adoption, and security characteristics. Doing this manually for every candidate server is time-consuming, which is why automated scoring and cross-referencing matter.

The Trust Question

Installing an MCP server means running code that will interact with your AI assistant and potentially with your data and systems. This is a trust decision, and making trust decisions about software from unknown authors is inherently difficult.

The open-source nature of most MCP servers helps here. You can read the code. But realistically, most people don't audit every dependency they install. This is true for npm packages, pip packages, and MCP servers alike.

What helps is having intermediary trust signals. Does the author maintain other well-known projects? Has the server been reviewed by security researchers? Is it listed in a curated directory that has quality standards? Is it used by organizations that have their own security review processes? These proxy signals don't replace code auditing, but they make the evaluation process more practical.

Categories Are Fuzzy

Trying to categorize MCP servers reveals that the boundaries between categories aren't clean. Is a server that queries a Postgres database a "database" tool or a "data analysis" tool? Is an MCP server that generates images an "AI" tool or a "creative" tool? Is a server that reads Slack messages a "communication" tool or a "productivity" tool?

Most directories assign categories, but they often disagree with each other. A user looking for database tools might miss a relevant server because one directory categorized it as "developer tools" instead. Full-text search helps, but it depends on the server's description being comprehensive enough to include the terms the user might search for.

The Role of Aggregation

The discovery problem is solvable, but not by any single directory. It requires aggregating data from multiple sources, normalizing metadata, computing quality signals, and presenting the result in a way that helps developers make quick, informed decisions.

Cross-referencing is particularly valuable. If a server appears in multiple curated directories, that's a stronger signal than appearing in just one. If a server's GitHub metrics, npm metrics, and directory presence all tell a consistent story, you can be more confident in your evaluation.

This is ultimately what drove the creation of tools like Skillful.sh. The individual directories each solve part of the problem, but the full picture only emerges when you bring those pieces together and add analysis on top.

Why MCP Server Discovery Is Harder Than It Looks