Methodology

Version

Trust scoring v3.2 (2026-07-22). When rules change, we update this page and Changelog.

Two badges (always shown)

Verified

Means there is enough real surface to check: live repository and/or live distribution (package or hosted remote) and registry presence under the product’s rules. Does not mean the publisher is the same legal entity as a brand you have in mind, or that the code is free of vulnerabilities.

Official

A claim about a search query matching a verified brand: DNS- or GitHub-verified namespace aligns with the brand you searched (farm-safe rules: registrable root, curated aliases, org proof). Struck through when we checked and it did not hold. Does not mean the code is healthy.

Health verdict

• healthy — no verified problem flags under current rules
• issues — one or more fact-based problems (e.g. archived repo, deprecated package, gone repo)
• unknown — not enough evidence; we do not invent a middle score

A live hosted remote can override a “stale docs repo” style finding when that is the only issue — with an auditable health note.

Search match vs trust (2026-07-23)

Brand search returns two different claims; do not conflate them:

| Field | Scope | Answers | | --- | --- | --- | | match_tier / match_reason | Query-scoped | Why this row is in the result set for this query (official, name, title, domain, or description_only) | | trust_score | Query-free | Hygiene/evidence quality of this server’s artifact (0–100) |

Ranking order: official → match tier (name/title/domain ≫ description-only) → product-position brand → trust → stars. Description-only hits (e.g. a product that merely mentions “Stripe” in registry text) can still have a high trust score for their own surface; they rank and render under Also matched by description, not as peers of the vendor official. Trust is never padded for brand intent — that would break non-search consumers (/v1/server, MCP lookup).

Trust score (0–100)

A published point sum over named factors, grouped into pillars:

| Pillar | What it covers (high level) | | --- | --- | | Identity | DNS/GitHub-verified namespace, first-party name match when corroborated | | Maintenance | Live repo/package/remote, verified composite, health, recency, license | | Adoption | Citations and listing signals (awesome lists, catalogs, code-search refs, etc.) | | Security | Reserved for true security signals; we do not fake a full pen-test pillar |

Each API card includes trust_factors (and related fields) so you can see the working.

Corroboration cap (v3.2)

Identity alone — even a cryptographically verified domain — cannot mint a high score without independent corroboration (e.g. live remote handshake, modest stars/downloads, or citations). Uncorroborated rows are hard-capped (currently 35).

Brand impersonation (v3.2)

Look-alike namespaces for protected brands can receive a brand_impersonation penalty and a caution summary. Strict token rules; curated allowlists for real vendor domains.

Coverage vs score

trust_coverage is breadth of applicable signals vs our full factor set — not a fake confidence percentage. Low coverage with a solid identity is possible and is described honestly in the summary.

Sources (public)

• MCP community registry harvest (daily, chunked)
• GitHub repository metadata
• npm / PyPI package metadata and deprecation
• Live MCP initialize probes for remotes (including RFC 9728 auth challenges as “alive”)
• Citation / adoption sources (e.g. awesome lists, catalogs, code search)
• Off-registry discovery (manifests, probes, social and catalog scouts) into an evidence-gated pipeline

Outbound crawler identity: mcpcensusbot.

What we will not claim

• A coverage % for things we never measured
• Pay-for-badge or paid “featured official”
• That package publisher identity equals GitHub owner identity without evidence
• That a high score means “safe to install without review”
• Fabricated testimonials, customer logos, or fake review counts

How to use this in a gate

Treat the census as a first gate: inventory, identity, health, and evidence trail. Keep code review, permissions, and org policy as later gates. More in Learn.

Reproducibility

Lookup UI and API expose the same cards. Prefer api.mcpcensus.com for automation. Methodology questions: [email protected].