# Methodology

How MCP Census Preflight turns public identity, maintenance, package, advisory, and liveness evidence into a versioned PASS, REVIEW, or BLOCK decision.

## Version
**Trust scoring v3.2** (2026-07-22). When rules change, we update this page and [Changelog](/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](/bot).

## 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](/learn).

## Reproducibility
Lookup UI and API expose the same cards. Prefer `api.mcpcensus.com` for automation. Methodology questions: **info@mcpcensus.com**.