The whole formula, in the open
Most registries give you a grade and hide the math. Here is ours, in full. Every number below is exactly what the code computes, so you can check our work on any server.
Quality grade (0 to 100)
Quality measures one thing: how much you can depend on a server. It is built from three signals, each computed from the server's own data. It deliberately does not include popularity (see below).
Points by time since the last real activity (a repo push or registry update): under 30 days = 45, under 90 = 36, under 180 = 26, under a year = 14, older = 5. Unknown = 16 (neutral-low).
A real description (40+ chars) = 11, a working install method (package or remote) = 11, a license = 7, a source link = 6.
The share of reviewers who said it worked, times 20. With no reviews yet it sits at a neutral 11, neither rewarded nor punished.
Why popularity isn't in the quality grade
Stars measure attention and age, not whether a tool is well-built. Baking them into quality punishes a brand-new, excellent server for being new, and lets a popular but mediocre one coast. So popularity lives on its own, as an adoption stat you can see and sort by, and it never touches the grade. A great tool published last week can earn an A on day one.
Trust tiers (provenance)
Separate from quality, this is who published it and what the official MCP registry proved, read straight from the namespace.
A company's own verified domain (like com.stripe/…). The registry confirmed they control the domain. The strongest first-party signal.
A proven GitHub or GitLab identity (like io.github.owner/…). You know exactly who published it.
Found on a public source with no verified ownership. Fine to use, but check the source first.
Safety
A separate flag for a known security advisory in the tool's dependencies. Green means none known, which is not a guarantee, so the permissions panel always shows exactly what a tool can reach before you run it.
Tool-definition quality
For servers we can connect to, we score the actual tools from their schemas. Unlike an LLM's opinion, every check here is a structural fact, so the score is reproducible and we show it per tool. Each tool is scored on four things:
Present and substantive. A no-parameter tool is scored almost entirely on this, since it's all an agent has to go on.
The share of parameters that declare a type (or enum, ref, or union).
The share of parameters that carry a description an agent can read.
Whether required fields are declared, so an agent knows what it must provide.
The server's score is 60% of the average plus 40% of the worst tool, so one poorly described tool pulls it down. This is an added signal shown on servers we can reach, not part of the universal quality grade above.