How we verify
Every fact MCP News publishes traces to evidence somebody actually fetched: a probe of the server itself, a published artifact, a vendor statement, a registry record, or a security advisory. Facts we cannot prove are recorded as unknown, never guessed. Records below 0.8 confidence are withheld entirely.
The short version
When this site says a fact is verified, it means someone, or a program someone audits, actually went and looked: opened the vendor's page, downloaded the published package, or sent a request to the server itself, and wrote down what came back and when. Every record shows those receipts. There is no "trust us" layer between you and the evidence.
When we cannot prove something, we say unknown. We never fill a gap with a guess, a vendor's marketing claim, or what a directory listing says. On this site, "we checked and could not confirm it" is a real answer with its own date, and it is the honest state of a lot of a young ecosystem.
Every record also carries a confidence score between 0 and 1 that reflects how strong its evidence is. Anything below 0.8 is not published at all: it sits in a private queue until better evidence exists. What you can read here has already cleared that gate.
And one thing we never do: rate quality. No stars, no editor's picks, no "best MCP server" lists. The MCP 500 ranks by measured public adoption, the way you might rank companies by revenue, and its formula is published. Being #1 there means widely used, not good, and certainly not safe.
What the labels mean
Two headline labels appear on every server record, and each has exactly three possible values. Neither label ever holds an inferred value: each one is set by evidence or left at unknown.
Spec support (spec_status)
- current - we confirmed support for the current stable revision, 2026-07-28, against primary evidence: a vendor statement naming the revision, a probe demonstrating it, or the published artifact implementing it. Currently 46 entities.
- legacy - we confirmed support for a specific earlier revision (recorded on the entity), and current-revision support is not confirmed. Currently 564 entities.
- unknown - not verified either way. "It exists, so it must support some revision" is a guess, and guesses do not set this field. Currently 155 entities.
Publisher relationship (authority)
- first_party - the server is published by the vendor whose service it fronts, confirmed against a vendor-controlled surface: the vendor's own GitHub organization, its docs domain, or its verified registry namespace. A famous name in a repository title is not verification; lookalike servers are a documented problem in this ecosystem.
- community - the publisher is verified but is not the vendor of the fronted service.
- unknown - the relationship is not verified.
The evidence ladder
Not all evidence is equal, and the confidence score encodes that. From strongest down, with what each method can and cannot establish, and how much of the catalog rests on it today (2578 published records):
| Evidence | Records | What it proves, and what it does not |
|---|---|---|
| Direct endpoint probes | 191 | We sent MCP requests to the server's own endpoint and recorded the answer: negotiated revision, tool list, authentication challenge. The strongest evidence for a live deployment. It proves what that endpoint did on that date, nothing about other deployments. |
| Vendor and repository statements | 185 | The vendor's own announcement, changelog, docs, or repository states the fact, and we fetched the page. It proves the vendor claims it; for spec support, a statement naming an exact revision is required, and vague wording ("latest spec") sets nothing. |
| Published-artifact chains | 1483 | The entity's published package declares a dependency on an official MCP SDK; we resolve that range to the concrete SDK version and read the protocol markers out of its published archive. Every link is a fetched artifact. It proves what the shipped code implements, not what any deployment negotiates, so it scores below a probe and the tracker labels it "SDK artifact" per row. |
| Official MCP Registry records | 703 | The official registry's record for the server, fetched directly, plus its namespace verification (a DNS-verified domain or a verified GitHub organization). It proves identity, packaging, and namespace control. Registry records routinely lag the packages they describe, so version facts prefer the package itself. |
| Security advisories and CVE records | 16 | The primary disclosure: a repository advisory, a CNA record, or a vendor bulletin. Severity is reported exactly as the discloser framed it, and every security story separates three dates that routinely differ by months: when it was fixed, when it was disclosed, and when the record was published. |
Two things are banned as evidence everywhere: search-results pages and third-party directory listings as a sole source. Directories can corroborate; they cannot ground. The publish gate rejects records mechanically when a cited source is a search URL, is missing its access date, or is not an HTTP URL at all.
Checked facts and counted facts
The catalog holds two kinds of facts, and they deliberately cannot touch each other. Checked facts (spec support, publisher authority, access details) are claims verified against evidence, carrying sources and a verification date. Counted facts (stars, forks, downloads, release history) are numbers read straight off public APIs, each family stamped with its own as_of date and the exact endpoint it came from.
A star count says nothing about whether a server does what it claims, so counted facts are never allowed to raise a confidence score, set a spec status, or refresh a verification date. When a declared repository no longer resolves, that is recorded as a counted fact too (reachable: false), not silently omitted.
The gate
Confidence is scored against a published rubric: 1.0 for headline facts verified against primary evidence with a fresh date, 0.9 for a spec-support edge confirmed by vendor statement or probe, 0.85 for well-sourced entity facts whose spec support is honestly unknown, and lower as sourcing weakens. Records below 0.8 are withheld. There is no human approval step to override the gate in either direction: the same mechanical checks apply to every record, from Anthropic's servers to a solo maintainer's.
Facts also age visibly. Every record shows when it was last verified, and a staleness process re-verifies the catalog continuously, prioritized by rank and age. Re-verification that fails to reach the evidence does not change a published fact; only positive contradicting evidence does, and material corrections are made in place with refreshed sources.
The ranking, in plain terms
The MCP 500 is a weekly ranking of servers by measured public adoption: how much the packages are downloaded, where the server is listed, how large its community is, and how recently it has been maintained. Every number in it was fetched from a public API during that week's collection run, with the URL and date stored, and an automated gate recomputes every rank from the stored raw data before a snapshot can publish. When a data source fails mid-run, the whole signal is voided for everyone that week and the void is disclosed, so no server ranks on data another was denied.
The full formula, weights, normalization, known limitations, and change policy are published at /adoption-index, and the raw snapshots are downloadable. If you cannot reproduce a rank from the published data, that is a bug, and we want to hear about it.
For agents
Everything above is also machine-readable. This page has a markdown sibling at /how-we-verify.md, the full data model and provenance contract for programmatic consumers is documented at /AGENTS.md, every record embeds schema.org JSON-LD with per-claim Claim nodes, and the raw fields (confidence, sources[], verified_at, verification_method, per-family as_of) ship in every record's markdown form.