Methodology

Preflight policy method v1

Preflight evaluates one exact canonical Census server name under one immutable built-in policy. It returns PASS, REVIEW, or BLOCK from public source facts and their recorded times. Decision precedence is BLOCK, then REVIEW, then PASS.

• PASS — every rule in that policy revision passes on the facts in the result.
• REVIEW — a rule needs human judgment, or a required fact is missing, stale, or inconclusive.
• BLOCK — a confirmed hard failure violates the policy, or strict@1 fails closed on required identity or hosted-liveness evidence.

A PASS does not mean a server is safe. Census does not review code, malware, requested permissions, scopes, data access, or runtime isolation.

Three built-in policies

Policy	Identity	Hosted liveness	Unknown required fact
baseline@1	Context only	Observe only	REVIEW
first-party@1	First party required	Observe only	REVIEW
strict@1	First party required	Fresh live proof required when a remote is claimed	BLOCK

All three policies block a proven brand impersonation, gone repository, missing claimed npm or PyPI package, and deprecated npm package. An archived or stale repository and a package-name OSV advisory require review in v1. One good package never erases a bad claimed package.

Evidence time and validity

Each fact names its source and shows observed_at when the source has a reliable success time. When only an attempt time exists, the result says attempted_at. V1 enforces freshness only for hosted liveness. Strict hosted-liveness evidence expires after 48 hours. Every decision expires within 24 hours through valid_until.

Authenticated completed calls receive a random audit ID and reproducibility digests. audit_signed is false. The digests are not signatures.

Run a Preflight · Read the exact policies · REST and MCP contract

Trust scoring v3.3 update

Trust scoring remains separate from Preflight policy decisions. V3.3 keeps the v3.2 corroboration rule and adds two narrow identity controls: a known allowlisted vendor domain can reach a thin-evidence ceiling of 70, while a random uncorroborated identity remains capped at 35; and a protected-brand claim without matching identity receives a brand_claim_without_identity penalty. Neither score nor threshold is a Preflight rule.

Version

Trust scoring v3.3 (2026-07-24). 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.

Protocol revision (reported, not scored)

The MCP specification's 2026-07-28 revision removed the initialize handshake and made server/discover mandatory. We ask every endpoint on record which revision it speaks, and publish the answer as a fact:

• a dated revision (e.g. 2026-07-28, 2025-06-18) is what the server itself reported;
• gated means the endpoint answered with an OAuth challenge — that proves it is up, and proves nothing about its revision;
• — means we have not asked it yet. That is a gap in our coverage, not a fact about the server.

This does not affect the trust score, deliberately. The revision shipped on 2026-07-28. Scoring an ecosystem on days of migration would manufacture a verdict the evidence does not support, and would mark down working, well-maintained servers for a release that is days old. We will revisit weighting only when real migration exists — and we will say so here when we do.

Two rules we hold ourselves to on this data:

1. A modern-aware SDK is not a modern server. Some implementations recognise the new spec's error codes while only being able to serve older revisions. When a server names its own supported versions, those decide what we publish — not the shape of its error.
2. Only an endpoint can be asked. server/discover is an endpoint call, so a package-only server has no revision to report and is never counted as missing one.

Sources (public)

• MCP community registry harvest (daily, chunked)
• GitHub repository metadata
• npm / PyPI package metadata and deprecation
• Live MCP endpoint probes for remotes — server/discover (2026-07-28) with an initialize fallback for handshake-era servers, 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: info@mcpcensus.com.