How this catalogue works
What the score measures, where every field comes from, and what each claim is and is not. Written so a publisher can check our working and tell us we are wrong.
The score
Out of 100, in two parts. It measures how well documented and verifiable a server is, not how good it is. A high score on a server that does the wrong job is still the wrong server, and nothing here is a security review or an endorsement.
Documentation and verifiability, 88 points
Available to every server today, with no action needed from us.
| Points | Signal | Why it is worth that |
|---|---|---|
| 20 | Verified publisher domain | The namespace is a domain the publisher proved they control, so the entry is traceable to an organisation rather than to an anonymous account. It is the strongest single signal available and is weighted accordingly. |
| 19 | Source repository published | A repository can be read, so a claim about what the server does can be checked. Roughly one server in seven publishes none, and a further group publish one that has since gone. |
| 15 | Registry entry updated in the last 90 days | A stale entry is the most common reason an install fails. This is the one component that decays on its own, without the publisher doing anything. |
| 9 | Hosted endpoint offered | A hosted endpoint means the server can be tried without installing anything, which is the difference between evaluating in a minute and evaluating in an afternoon. |
| 9 | Entry still active rather than deprecated | The registry marks entries deprecated and deleted. An active entry is not a quality claim, only a statement that the publisher has not withdrawn it. |
| 8 | No credentials required | A server needing no API key can be evaluated immediately. One that needs three is a procurement conversation before it is a technical one. |
| 5 | Command line alternative documented | Documented CLI equivalence means the same job can be done without the server at all, which is worth knowing before adopting it. |
| 3 | Tool list published anywhere | Deliberately worth almost nothing. Every MCP server has tools, so having them is not a distinction, the official registry has no field for them, and Docker lets a publisher resolve them when a client connects instead of declaring them in advance, which is a legitimate choice rather than a worse one. This credits only the convenience of the list being written down somewhere. The number of tools is not scored at all: a server with forty tools is not four times better than one with ten. |
Community and reputation, 12 points
Zero until the data exists, and never negative. Most servers score nothing here, so treat it as upside rather than a penalty: a server loses nothing for being new, only for being undocumented.
| Points | Signal | Why it is worth that |
|---|---|---|
| 6 | GitHub stars, sliding scale | Six bands rather than a linear count, because the difference between 10 stars and 50 means more than the difference between 4,000 and 5,000. |
| 3 | G2 rating | Linked, never scraped, and scaled to the rating the publisher's own profile shows. |
| 3 | Trustpilot rating | As G2. A missing profile scores zero and is not a penalty. |
Bands
70 and above is high, 45 to 69 is middle, below 45 is low. A band is a reading aid, not a verdict.
What the score cannot tell you
- Whether the server works. We do not run it.
- Whether it is safe. We never audit code and never connect to a publisher's endpoint.
- Whether it suits your job. Fit is yours to judge.
Where the data comes from
The official MCP Registry is the spine. Everything else is supplementary and ranks below it. Resolution order for a server's identity is registry, then hand written additions, then Docker's MCP catalogue, then Smithery.
| Source | What it supplies |
|---|---|
| Official MCP Registry | Identity, versions, packages, hosted endpoints, transports, environment variables, publish and update dates. It carries no categories and no tool lists, and never has. |
| Docker MCP catalogue | Licence, tags, icons, secrets, OAuth, image and upstream, plus tool lists where a publisher declares them. |
| Smithery | Tool schemas at scale. Joined only on high confidence matches, described below. |
| Public source hosts | Repository presence, stars, last commit. Read from public metadata. |
| Publisher websites | Pricing, privacy, terms, security and compliance pages, linked as claims. |
Claims, and what we never do
We never assert anything on a publisher's behalf. Where a page names SOC 2 or ISO 27001, it is recording that the vendor claims it, with a link to where they claim it. We have not seen an audit report, and a compliance link is not a compliance guarantee. Review ratings are linked and never scraped.
We never connect to a third party server to list its tools. Tool data comes only from sources that publish it. That is a stated position rather than a technical limitation: introspecting somebody's endpoint to enumerate its capabilities is not something a directory should do uninvited.
Absence is not a finding. "Not collected yet" and "the publisher has not disclosed this" are different statements and render differently everywhere on the site. An empty field never implies the thing is missing from the product.
Empty tools does not mean no tools. Docker lets a publisher resolve tools when a client connects instead of declaring them in advance. Those are reported as resolved at runtime, never as no published manifest.
Tool intent
Each of the 68,099 tool definitions we hold, across 3,050 servers, is labelled with what calling it does.
| Intent | Meaning | Share |
|---|---|---|
| answer | Reads and returns information. Changes nothing. | 66.5% |
| act | Changes state somewhere: writes, creates, updates, deletes, sends, deploys. | 18.9% |
| transact | Moves money or commits to something with a real world cost. | 1.0% |
| not classified | The name and description did not settle it. We would rather say so than guess. | 13.6% |
Only 660 of those labels, 0.97 percent, come from the publisher. The protocol defines two hints a publisher may set, one for read only and one for destructive, and almost nobody sets them. Every other label on this site is our inference from the tool's name and description, and each one says which it is on the page. An inferred label is our reading, not a claim by the publisher.
The protocol has no hint for money at all, so a transact label can only ever be an inference. We keep the label narrow on purpose: vocabulary shared between finance and ordinary software, such as transfer, token and swap, is excluded, which means on chain servers are under labelled rather than wrongly labelled as moving money.
Matching, and why it is conservative
Smithery publishes tool schemas but no repository URL, so joining its records to ours is inference. Only two joins are trusted: a repository owner and name equal to the Smithery qualified name, and a vendor domain match that additionally requires the names to agree. A domain claimed by more than one Smithery server is dropped entirely.
The reason is asymmetric cost. A tool list attached to the wrong server is worse than no tool list, because a reader cannot tell it is wrong.
Freshness, and what is incomplete
Every collected field records the date it was read. The score credits a registry entry updated in the last 90 days, which means a score can fall without the publisher doing anything, as that window closes.
Collection is ordered by score, so the pages most likely to be read are filled in first. That leaves gaps, and they are gaps rather than findings:
- Compliance and security links: collected for 17,632 of 29,756 servers.
- Roughly 3,000 servers publish no repository or one that has since gone. That is a ceiling on what repository collection can ever reach, not a backlog.
If something here is wrong
Tell us. A publisher correcting their own entry is the highest quality signal we can get, and the whole point of publishing this page is that our working can be checked. Every figure on the site comes from JSON we hold rather than from the page you are reading, so a correction fixes it everywhere at once.