MCP Server Registries Compared: Smithery vs Glama vs mcp-get

Where You Actually Go to Find MCP Servers

If you've spent any time building with Model Context Protocol, you've probably noticed that the ecosystem is fragmented across at least four or five different places. There's no single canonical registry, which means developers end up bouncing between Smithery, Glama, mcp-get, and a handful of GitHub awesome lists depending on what they're looking for and who they trust.

Each of these registries has a distinct philosophy about what belongs in it and how much vetting is worth doing. Understanding those differences saves you from installing something sketchy or spending an afternoon evaluating a tool that's been abandoned since January.

Smithery: The Package Manager Approach

Smithery positions itself closest to what you'd expect from a traditional package registry. It has a web interface for browsing, but the real focus is on installability. Servers listed on Smithery are expected to work with a consistent installation flow, which means there's at least a baseline of structural consistency across listings.

As of mid-2025, Smithery lists several thousand MCP servers and has become one of the more frequently cited sources in Claude and other agent integration documentation. The submission process requires a working server with a defined schema, which filters out the most half-finished projects before they ever appear in search results.

The quality floor is real, but it's not especially high. Smithery verifies that a server is installable and has a valid manifest, but it doesn't do deep security review or audit what the server actually does with the permissions it requests. A server that requests filesystem access and then does something unexpected with it would pass Smithery's current checks without issue.

Where Smithery stands out is tooling integration. It has direct hooks into Claude Desktop configuration and publishes structured metadata that other tools can consume programmatically. If you're building something that needs to enumerate available MCP servers or automate installation, Smithery's API is the most developer-friendly of the bunch.

Glama: Curation With a Security Lens

Glama takes a noticeably different approach. Rather than optimizing for breadth, it leans into curation and has invested more explicitly in security review as part of the listing process. Servers on Glama go through a review that includes checking for obvious prompt injection risks, evaluating what permissions are requested versus what the server's stated purpose requires, and flagging tools that have suspicious dependency chains.

This makes Glama's catalog smaller than Smithery's, but the signal-to-noise ratio is better. If you're evaluating MCP servers for use in a production environment or an enterprise context, starting with Glama's listings gives you a shorter list of things to worry about.

Glama also publishes security metadata alongside listings, which is genuinely useful. You can see at a glance whether a server has known dependency vulnerabilities, what permissions it declares, and whether the review flagged anything worth investigating. That transparency is something most other registries don't offer at all.

The tradeoff is coverage. Newer servers, experimental tools, and community projects often appear on Smithery or the awesome lists weeks or months before they show up on Glama, if they ever do. If you're trying to stay current with what's being built, Glama alone will leave gaps.

mcp-get: The CLI-First Registry

mcp-get is the most developer-tool-native of the major registries. It's built around a command-line interface, and the experience is deliberately similar to using npm install or brew install. You run npx mcp-get install <server-name> and it handles configuration injection into your Claude Desktop or other client setup automatically.

The registry backing mcp-get is community-maintained via pull requests to a central repository. Anyone can submit a server by opening a PR with the required metadata, and maintainers review and merge. This keeps the process transparent and auditable, since you can look at the git history to see exactly when something was added and who approved it.

The review quality on mcp-get PRs is variable. Some PRs get thorough review from active maintainers; others get a quick look and a merge. There's no automated security scanning in the pipeline, so the safety of any given listing depends heavily on how much attention the reviewing maintainer paid that day.

What mcp-get does well is the installation experience. The automatic config injection is genuinely convenient, and the CLI makes it easy to manage multiple servers across different projects. For developers who live in the terminal and want to get something running quickly, it's often the fastest path from zero to working integration.

The Awesome-MCP Lists: GitHub's Wild West

There are now at least a dozen repositories following the awesome-mcp-servers naming convention on GitHub, with a few having accumulated thousands of stars. The most prominent ones, including punkpeye/awesome-mcp-servers and appcypher/awesome-mcp-servers, have become de facto aggregation points for the community.

The format is familiar if you've used any awesome list before: categorized links with brief descriptions, maintained via pull requests, no installation tooling, no structured metadata. The value is discoverability and community signal. A server with 500 GitHub stars that appears on three different awesome lists is probably worth a closer look, even if no formal review has happened.

Curation quality across the awesome lists varies enormously. Some maintainers actively prune dead links and remove servers that have been abandoned. Others merge PRs liberally and let the list grow without much pruning. The punkpeye list has been more actively maintained than most, with periodic cleanup passes and some basic standards around what gets included.

The awesome lists are also where you'll find the most experimental and niche servers. If someone built an MCP server for a specific internal tool or a narrow use case, it probably appeared on an awesome list before it went anywhere else. That makes them valuable for research and for understanding the edges of what people are building, even if you wouldn't blindly install things from them without review.

How Quality Control Actually Differs

If you put these four sources on a spectrum from most permissive to most restrictive, it goes roughly: awesome lists, mcp-get, Smithery, Glama. But that ordering oversimplifies things, because each one is permissive or restrictive along different dimensions.

The awesome lists have no structural requirements at all. A link to a GitHub repo with a README is sufficient. mcp-get requires a working manifest and passes a human review, but that review is lightweight. Smithery requires installability and schema compliance, which catches structural problems but not behavioral ones. Glama adds security review and permission auditing, which catches a different class of problems that the others miss entirely.

None of them currently do runtime analysis. They're all evaluating servers based on their code, metadata, and declared behavior, not based on what they actually do when running in an agent context. That's a meaningful gap, especially as MCP servers start requesting broader permissions and operating in more sensitive environments.

For practical purposes, the combination that makes the most sense for most teams is: use Glama as your primary source for anything going into production, use Smithery for broader discovery and for tools that haven't made it onto Glama yet, and use the awesome lists for research and staying current with what the community is building. mcp-get is worth having in your toolkit specifically for its installation experience, even if you found the server somewhere else.

Cross-Registry Coverage and What Gets Missed

One thing that becomes apparent when you spend time across all four sources is that coverage is uneven in predictable ways. Official and well-resourced servers, things like the Anthropic reference implementations, major SaaS integrations, and tools from established developer tool companies, tend to appear everywhere quickly. Community-built servers for niche use cases are more likely to appear only on awesome lists, or only on mcp-get, and may never make it to Glama.

This creates a real discovery problem. The servers that would benefit most from security review (community-built, less scrutinized, often requesting broad permissions) are the ones least likely to have received it. The servers that have been thoroughly reviewed are often the ones that needed it least.

Platforms like Skillful.sh that aggregate across all these sources and apply consistent security scoring address this gap directly. When you can see that a server appears on three awesome lists and Smithery but not Glama, and that it has a C security grade based on static analysis, that's actionable information. It tells you the server has community adoption but hasn't been vetted to the standard you might want before deploying it.

Adoption Signals Worth Paying Attention To

Beyond security, the other thing these registries help you assess is whether a server is actually maintained and used. GitHub stars are a rough proxy but not a great one, since they accumulate over time and don't reflect current activity. More useful signals include recent commit activity, how quickly issues get responses, and how many different registries have independently listed the server.

A server that appears on five different awesome lists, has active Smithery and mcp-get listings, and shows recent commits is probably in reasonable shape. A server with 800 stars but no commits in six months and listings only on one awesome list is worth being skeptical about, regardless of how good the README looks.

The registries themselves don't always surface these signals well. Smithery shows some metadata, the awesome lists show almost none, and mcp-get's CLI doesn't expose much beyond the install command. Glama is the most informative at the point of discovery, but even it doesn't give you a full picture of adoption trajectory over time.

What to Actually Do With This Information

When you're evaluating an MCP server for real use, a reasonable workflow looks like this: find the server wherever you first encounter it, then cross-reference it against the other registries to understand its adoption footprint. Check whether Glama has reviewed it and what that review found. Look at the GitHub repo directly for recent activity and open issues. If you're going to use it in a context where it has access to sensitive data or systems, read the source code for the relevant permission handlers before you install it.

The registries are useful starting points, but none of them substitute for your own judgment about what you're actually running in your agent stack. The ecosystem is moving fast enough that quality control infrastructure is still catching up to the volume of servers being published. Treating any single registry as a complete seal of approval would be a mistake, but using them together gives you a much better picture than any one of them provides alone.

MCP Server Registries Compared: Smithery, Glama, mcp-get, and the Awesome Lists