Vouchity vs Smithery: which MCP directory should you trust?

Smithery and Vouchity get compared because people searching for "is this MCP server safe" land on both, but they answer different questions. Smithery is a registry and hosting platform — it helps you find and run an MCP server. Vouchity is an independent scoring layer — it helps you decide whether you should. You can use one, the other, or — the workflow most people actually land on — find a server on Smithery and check its Trust Score on Vouchity before you connect it to anything that can take real actions.

What Smithery actually is

Smithery is a searchable registry of Model Context Protocol servers, built with a CLI (npx @smithery/cli) for installing servers locally and a hosted deployment path for running them on Smithery's own infrastructure instead of yours. Publishers submit a server, Smithery scans it for the tools, prompts and resources it exposes, and — for hosted servers — Smithery's gateway can proxy calls and handle OAuth and credential injection so a caller doesn't have to wire up auth by hand. It was founded in December 2024 and has grown into one of the largest MCP catalogues, listing well over 15,000 servers at the time of writing.

Each server listing shows usage counts (Smithery calls out tool-call volume, e.g. "43k uses"), and publishers can complete an automated "official-vendor verification" checklist to earn a verified badge. Smithery has also partnered with Invariant Labs to run MCP-Scan, a security scanner, across servers in its registry. What we could not find in Smithery's own documentation is a published, per-server score — a single number combining multiple signals into one trust rating, with a public formula for how it's calculated. The verification badge and usage counts are real signals; they answer "is this an official vendor" and "is this popular," not "how well-maintained, licensed and provenanced is this, on a scale I can compare across servers." If that's incorrect or has changed, we'd rather be corrected than guess — see Smithery's own publishing docs for the current state of verification.

In August 2026, Smithery was acquired by Arcade.dev, an agent-tool execution and authorization platform. Smithery co-founder Anirudh Kamath framed it as bringing the registry's "one click to find a server, one click to run it" simplicity to Arcade's enterprise security and governance layer. Practically, that means Smithery's registry is now part of a company that also sells the execution runtime those same servers run on — a detail worth knowing if independence from any single vendor's commercial interests matters to how you evaluate a listing. We cover this in more depth, alongside mcp.so, Glama and PulseMCP, in our full MCP directory comparison.

What Vouchity actually is

Vouchity doesn't host, run or accept submissions for MCP servers. It ingests public data — the official MCP community registry, the GitHub API and the npm registry — for every server it tracks, and computes a Trust Score from five weighted signals: maintenance (25%, recency of commits, releases and registry updates), adoption (20%, stars and weekly downloads), transparency (20%, license, public source, versioned releases), security (20%, declared auth on remote servers, tool-description red flags, attack surface) and provenance (15%, official/registry status and publisher identity). Every score is a weighted mean over only the signals that are actually verifiable for that server — nothing is guessed or defaulted when data is missing. The full formula, including exactly how each signal is computed and what triggers a flag like no-auth or archived, is public in our methodology.

As of this snapshot (refreshed 2 months ago), Vouchity tracks 320 servers across 11 categories, with a registry-wide average Trust Score of 63/100 and 269servers carrying at least one real risk flag. That last number is the point: a listing existing somewhere doesn't mean it's safe to connect, and Vouchity exists specifically to make that gap visible, server by server, with a public grade (A through F) rather than a raw number you have to interpret yourself.

How the two actually differ, attribute by attribute

Where they're genuinely complementary

A concrete scenario: you're building an agent that needs to read and write GitHub issues. You search Smithery, find three candidate servers, and Smithery's CLI gets one of them running against your repo in a couple of minutes — that part of the job, Smithery does well, and Vouchity doesn't try to replicate it. Before you give that server write access to your issue tracker, though, you look it up on Vouchity's registryand see its full signal breakdown: when it was last published, whether it declares a license, whether the maintainer is a verifiable namespace or an anonymous handle, and whether anything in its tool descriptions reads like an injection risk rather than a plain description. That's the check a usage counter and a vendor badge don't answer on their own.

The same workflow works unattended, too. If you're building an agent that needs to evaluate servers itself — not just have a human eyeball a badge — Vouchity exposes a hosted MCP endpoint (see the API docs) with search_mcp_servers, get_trust_score and check_server_safety tools, so the agent can query a Trust Score programmatically before it ever calls the tool in question, regardless of which registry it found the server on.

Where the differentiators are real, not just marketing

Two differences are worth being specific about rather than glossing over. First, independence: Vouchity doesn't host servers, doesn't sell execution infrastructure, and doesn't profit from a server being listed — the Trust Score has no commercial incentive pointing toward a higher number. Smithery's registry, as of August 2026, sits inside a company (Arcade.dev) that also sells the runtime those servers execute on; that's a legitimate business model, but it's a different structural position than a scoring layer with nothing to sell the servers it scores.

Second, transparency of method: every component of a Vouchity Trust Score is documented — you can see exactly why a server scored 62 instead of 85, down to the specific flag (say, no-license or stale) that dragged it down. That's the same checklist covered step by step, without the scoring math, in how to vet an MCP server. If Smithery publishes an equivalent public formula for its usage-based signals in the future, this comparison should be updated to reflect it — we're describing what's documented today, not asserting it will always be this way.

A decision framework

• Need to find and run a server fast, with managed auth?Smithery's CLI and hosted deployment are built exactly for that.
• Need to know whether a server is actually maintained, licensed and reasonably scoped before you connect it? That's what a Trust Score is for — check the registry or scan the leaderboard for the highest-scoring options in your category.
• Want to track a server over time, not just at the moment you install it?Vouchity's watchlist alerts you if a Trust Score drops or a new risk flag appears — useful for a server you've already wired into production, wherever you found or run it.
• Not sure which local vs. hosted setup fits your risk tolerance? See remote vs. local MCP servers for how the trust model changes between the two.
• Comparing more than these two? Our directory comparison covers mcp.so, Glama and PulseMCP alongside Smithery.

In practice, most serious setups end up using both: a catalogue like Smithery to find and deploy a server, and an independent Trust Score to decide whether it deserves the access you're about to give it. For the protocol fundamentals behind either approach, see modelcontextprotocol.io or our own plain-English explainer.