# MCP News - How we verify

## The short version

"Verified" means the claim was checked against evidence somebody actually fetched: a live probe of the server, a published artifact, a vendor statement, an official registry record, or a security advisory. Every record lists its sources with access dates. Facts we cannot prove are recorded as `unknown`, never guessed. Records below 0.8 confidence are withheld entirely. The site publishes no quality ratings; the MCP 500 measures adoption only, by a published formula.

## Labels

- spec_status: current = confirmed support for 2026-07-28 against primary evidence (46 entities today); legacy = confirmed on a specific earlier revision, current not confirmed (564); unknown = not verified either way (155). Never inferred.
- authority: first_party = publisher is the vendor of the fronted service, confirmed against a vendor-controlled surface (vendor GitHub org, docs domain, or verified registry namespace); community = verified publisher who is not that vendor; unknown = relationship not verified. A famous name in a repo title verifies nothing.

## The evidence ladder (2578 published records)

- Direct endpoint probes (191): MCP requests sent to the server's endpoint; proves what that endpoint did on that date. Strongest evidence for a live deployment; scores 0.9+.
- Vendor and repository statements (185): the vendor's own fetched announcement/changelog/docs/repo. Spec-support claims require an exact revision named; vague wording sets nothing.
- Published-artifact chains (1483): package -> declared official-SDK dependency -> resolved SDK version -> its protocol markers, every link a fetched artifact. Proves what the shipped code implements, NOT what a deployment negotiates; scored 0.85, labeled "SDK artifact" on /tracker.
- Official MCP Registry records (703): fetched registry record + namespace verification (DNS or GitHub-org). Proves identity, packaging, namespace control. Registry records lag packages; version facts prefer the package.
- Security advisories and CVE records (16): primary disclosures only, severity as the discloser framed it, fix/disclosure/record dates separated.

Banned as evidence: search-results pages always; directory listings as a sole source. The publish gate rejects offending sources mechanically.

## Checked vs counted facts

Checked facts (spec support, authority, access) carry sources and verified_at. Counted facts (metrics.repo, metrics.package) are read off public APIs with a per-family as_of date and exact source endpoint. Counted facts can never raise confidence, set spec_status, or refresh a verification date. reachable: false means we measured and the declared repo is gone; an absent family means unmeasured.

## The gate

Confidence rubric: 1.0 headline facts on fresh primary evidence; 0.9 spec-support edge by vendor statement or probe; 0.85 well-sourced entity facts with spec support honestly unknown; below 0.8 withheld (private moderation queue). No human override in either direction; the same checks apply to every publisher. Facts age visibly (verified_at everywhere); staleness re-verification is prioritized by rank and age; a failed re-fetch never changes a published fact - only positive contradicting evidence does.

## The ranking, in plain terms

The MCP 500 ranks by measured public adoption: downloads, listings, community size, maintenance recency. Every number is fetched from a public API during the collection run with URL and date stored; a gate recomputes every rank from stored raw data before publish; failed signals void for everyone and the void is disclosed. Full formula and limitations: https://mcp-news.com/adoption-index (markdown: https://mcp-news.com/adoption-index.md).

Full data model for agents: https://mcp-news.com/AGENTS.md. Human page: https://mcp-news.com/how-we-verify