Adoption Index methodology

What it measures, and what it does not

The Adoption Index is a composite of public, machine-verifiable adoption signals for Model Context Protocol servers. It answers one question: how widely adopted is this server, by observable public measurements, as of the snapshot date? It is not a quality rating, a security endorsement, or a recommendation. Fact verification (spec-revision support, publisher authority, access details) is a separate process; a high rank and an unverified record can and do coexist.

Components and weights

Count signals are log-scaled (log10(1 + value)) and normalized 0-100 against the maximum observed across the measured universe in the same snapshot; the maxima are stored in the snapshot. The index is the weighted mean over the components that have data, with weights renormalized across available components. A server needs at least 2 evidenced components to be ranked - nothing ranks on a single gameable signal. The published cut is the top 500.

Where the data comes from

The candidate universe is the official MCP Registry (latest active version per server) plus this site's verified catalog. Identity joins use exact machine-verifiable keys only: the registry record's own package identifiers, normalized repository URL equality, or already-verified catalog fields. There is no fuzzy name matching anywhere; identifiers claimed by more than one record are attributed to none and disclosed in the snapshot. Every measurement stores the exact API endpoint it was fetched from and the date, and only in-run responses count: nothing is estimated or carried forward. The one defined exception is Docker pull velocity, which is the delta against the previous snapshot's stored pull count, referenced by snapshot date.

GitHub repository probes run on a mechanical shortlist: the strongest distribution scorers plus every cataloged, Docker-Catalog-listed, or Smithery-joined candidate. Candidates outside the shortlist have community and maintenance recorded as unavailable rather than guessed.

Completeness and voiding

Each snapshot records, per signal, how many probes were attempted and how many succeeded. If a signal's success rate falls below 90% (rate limiting, API failure), the signal is voided for the entire snapshot: no row scores on it, and the void is disclosed on the list and in the raw data. Zero and no-data are distinct: zero means the API answered zero; unavailable data renormalizes the weights instead of scoring.

Known limitations

• Stars can be bought and downloads can be inflated by CI; the multi-component composite and log scaling dampen, but cannot eliminate, gaming.
• GitHub Container Registry does not publish pull counts, so GHCR-only distribution is invisible to the distribution component (disclosed as no public data).
• Remote-only servers without packages or public repositories have less measurable surface; the coverage floor keeps them unranked rather than misranked.
• Smithery usage joins require an exact homepage-to-repository match, so some platform usage goes unattributed by design rather than misattributed by guessing.

Verification gates

Before a snapshot publishes, an automated gate recomputes every component score, index value, and rank position purely from the snapshot's stored raw measurements and this methodology's constants, and blocks publication on any mismatch. The same gate enforces measurement dating (every access date must equal the snapshot date), the coverage floor, rank-order consistency, and identity-key integrity (a per-package or per-repository measurement URL must embed the exact identifier it was fetched by).

Change policy

The methodology is versioned; this page documents v1. Changing weights, signals, formulas, or gates increments the version, updates this page, and is announced in news. Snapshots are never recomputed retroactively: each records the version it was computed under.