Compare
Every MCP directory says "verified". They all mean something different.
A badge on a listing is a claim, and the claim is only worth what it was computed from. One directory checks that you own the domain you published under. One runs your server and grades how well its tools describe themselves. One estimates your weekly traffic. Below is what each label is derived from, read on 24 August 2026, so you can tell which question a badge actually answers before you rely on it.
What each badge is derived from
Catalog size is in the first column because it is the number every directory leads with, and it is the one that answers the fewest questions. A listing is a record that someone submitted an entry. It is not a record that anything answered.
| Directory | Listings | The label | What it is derived from | Refreshed |
|---|---|---|---|---|
| Official MCP Registry | 23,816 servers | Namespace ownership | Proof that you control the namespace you published under: a DNS TXT record or a /.well-known file for a domain, or an authenticated GitHub account. It is a claim about who published the server, not about what the server does. Published method. | At publish |
| Glama | 77,243 servers | Letter grade, A to F | A real tools/list exchange, then a rubric applied to the text that came back. Glama builds an open-source server from its Dockerfile and runs it inside a sandbox, or connects to a hosted one as an MCP client, then scores how well each tool describes itself. The grade measures the quality of the writing in the tool definitions, not whether the tools work. Published method. | Every commit and rebuild |
| PulseMCP | 22,012 servers | "Est Visitors (Week)", plus provenance tags | An estimate of traffic, labelled as an estimate on the card itself. The tags beside it ("Anthropic References", "Official Providers", "Community") describe who published a server rather than anything measured about it. | Daily, per its own description |
| Smithery | 17,029+ servers | A verified badge, plus use counts | We did not find published criteria for the badge on the pages we read, so we cannot say what it is derived from. That is a gap in our reading, not a finding about Smithery. | Not stated on the pages we read |
| mcphunter.com | 195+ servers | "verified, rated, and ready to install" | We did not find published criteria for either word on the pages we read. Named here because the domain is one hyphen from ours and readers land on it looking for us. | Not stated on the pages we read |
| MCP Hunter (this site) | One week at a time | Verified <date> | N tools | responded in Nms | One tools/list call to the address the maker gave us, on the date printed in the line. The tool count is what came back. There is no grade, no score and no judgment of any kind, because a single call cannot support one. Published method. | Never. We call once, at submission |
Every external row was read from the linked page on 24 August 2026. Badge policies change, and a directory may publish criteria somewhere we did not look. Where a row says we did not find published criteria, that is a description of our reading and not a finding about the directory.
The row we lose
Glama's grade is fresher than our line, and it is not close. It re-runs on every commit and every rebuild. We call a server once, when it is submitted, and never again, so our line describes a moment that gets older every day. That is a deliberate choice and not an oversight: a directory that re-checks on a schedule is making a promise about the present, and a claim like "working today" is one we would have to keep making forever to keep it true.
So the honest reading is that these labels answer different questions. If you want to know whether a server's tools are well described and whether that held up on the latest commit, Glama's grade is derived from exactly that. If you want to know what one specific address returned on one specific date, with the date on the face of it, that is ours.
What a listing tells you when the answer is nothing
This is the property worth checking on any directory, and it is easier to check than a methodology page. Find a listing the directory could not reach and see what it says. A record that can only ever report a success is not a record, because you cannot tell a server that passed from a server nobody tried.
On our listings the absence is printed in the same place the measurement would go, and it names what happened: Not verified. Timed out. A product with no address at all, which is how most MCP servers ship, carries no verification line whatsoever rather than a softer one. Those listings say what their stdio start command is and what its package registry returned, and nothing about a connection, because there was none to make.
Why catalog size is the weakest number on any of these pages
We called 1,100 of the 12,771 addresses the official registry listed on 20 August 2026, once each. 139 of them (12.6%) did not answer as an MCP server at all. Another 263 (23.9%) answered by asking for credentials, which is a working server guarding itself and is counted here as answering.
That is the gap between a catalog and a measurement, in the one place it can be measured. It is not a claim about any directory's own catalog, which we have not swept, and it is not a claim about any individual server: an address that did not answer on one afternoon may have been mid-deploy, and one call cannot tell the difference. The full census carries the method and every caveat.
There is a structural reason this number is unusual rather than a clever one. A directory cannot publish the reachability of its own catalog, because the figure devalues the thing it is selling. We have no catalog to protect: the board holds one week at a time, so the measurement costs us nothing to publish.
What none of these badges tell you
Whether the server is safe to install. Not one label in the table above is a security review, including ours. We have not read anyone's source, audited how a server handles your data, or checked what its tools do once you grant them access, and a tools/list call cannot reveal any of it: it returns the names and schemas a server chooses to advertise. If a directory's badge sounds like a safety judgment, the thing to do is read what it says the badge is computed from, exactly as above.
How to read any MCP directory badge
- Find the date. A claim with no date on it is a claim about a moment nobody will tell you.
- Find the method. If the site publishes what the label is computed from, that document is the badge. The word on the card is a summary of it.
- Find a failure. Look for a listing that did not pass. A directory that shows you one is telling you the label means something.
- Check what was measured against what you need. Ownership, description quality, popularity and reachability are four different questions, and no badge answers more than one of them.
Check a server yourself
The MCP connection tester runs one tools/list call against any address and hands back the same dated record our listings carry: outcome, negotiated protocol revision, tool count, tool names, and whether the descriptions are there. It takes a URL and no account, and the result gets a permanent link you can send someone.
Built an MCP server? Launch it on the weekly board. You get a permanent page with a dated record of what your server answered, and the week it launched in stays online forever at its own URL.
External claims on this page were read from the linked pages on 24 August 2026. Our own verification line is produced by one tools/list call at submission and is never refreshed (how the connection test works).