METHODOLOGY · popularity-v1.0

Popularity, with the evidence.

mcpverdicts.com ranks specific MCP implementations using observed platform activity, package distribution, and repository interest. The score is a relative index within our collected sample. It is not a count of agents, a quality rating, or a security endorsement.

Chart snapshot: 2026-09-17. 413 eligible contenders from 494 reviewed identities. Catalog and source coverage are partial. Daily refresh attempts update available measurements and label retained observations when a source fails.

Usage & adoption counts

Chart rows show rounded, observed counts alongside the popularity score. Each count names its source and reporting period. Open a profile to see the exact count, collection date, measured scope, and source link.

We display the adoption signal leading the score first, followed by the supporting adoption signal when available. The raw counts use different units and are not summed. A larger displayed count does not automatically mean a higher overall rank: the score also reflects each source’s reference distribution and supporting evidence.

• Observed: a published source measurement, rounded for readability. Smithery uses retain their source-defined period; npm downloads cover 30 days; PyPI uses its source-defined last-month window.
• Estimated: reserved for modeled figures with a disclosed method. No modeled usage estimates are published in this version.
• Publisher-reported: company-supplied aggregates, displayed separately after review and consent. The review status describes evidence review, not an independent audit.

Rounding an observed count does not turn it into an estimate of total traffic. Downloads, platform uses, visitors, and successful tool calls are different measures. GitHub stars remain an interest signal and never appear as usage counts. Unavailable or withheld measurements are not filled with invented figures.

One score. The same competition.

We normalize Smithery uses and package downloads separately, then take the stronger adoption signal for the 85-point component and the other for the 10-point component. GitHub contributes at most five points. A server can qualify with a single positive adoption signal, earning up to 85 points; another source must contribute observed evidence to earn more.

“Supporting” means additional public evidence, not statistically independent users. Downloads and Smithery counts can overlap. We never sum their raw counts. Claimed ownership, publisher submissions, payments, and profile completeness add no points.

Normalization and small samples

Each input receives its empirical percentile against a frozen, source-specific reference population: the share of positive reference measurements less than or equal to the observed value. Zero receives zero. Outliers cannot exceed 100. If a reference has fewer than 30 observations, its normalized score is multiplied by its sample size divided by 30. This prevents a tiny sample’s leader from automatically receiving a full source budget.

Reference version: reference-2026-09-17-v1. The reference includes attributable measured scopes across the catalog, not only published contenders. PyPI’s small sample materially limits its score contribution. Expanding or changing a reference creates a new version and resets comparisons across that boundary.

For package distribution, the audited primary package is fixed. When both npm and PyPI are available, this version uses npm. We compared that rule with taking the larger normalized package signal: it did not change this release’s Top 100. We do not sum packages or give each implementation the full downloads of a shared package.

Missing, zero, and stale data

Unavailable inputs remain unavailable; we do not estimate a count of zero. Only observed evidence earns score points. Unused component budgets are not redistributed, so removing a signal cannot improve a server’s score. Applicability is not inferred just because a metric is missing: an uncollected or unknown source stays labeled unavailable.

A measured zero stays zero. Observations older than seven days are labeled older. Inputs older than 14 days are withheld when calculating a new chart. Successful measurements can advance during a partial collection. Failed measurements keep their original collection dates and show refresh pending; their age still counts toward the 14-day cutoff. If every measurement fails, the last dated chart is retained. Archived repositories are withheld pending lifecycle review.

What the sources measure

• Smithery: its published useCount, accepted as supplied. Its period is source-defined; we do not relabel it monthly users or tool executions.
• npm: downloads over the previous 30 complete UTC days. Installs, CI and automation may contribute.
• PyPI: the source’s last_month download count. Its exact boundary is not asserted when unavailable.
• GitHub: cumulative interest in an attributable repository. Shared monorepo stars are withheld.

PulseMCP estimated visitors and ClawHub skill downloads are not inputs in this score. Neither establishes executions of a specific MCP implementation.

Who can rank

A published contender needs reviewed identity, a primary category, and at least one positive, attributable adoption signal. Deprecated listings, archived mappings, unresolved shared-package counts and unclear server purposes are withheld. Star-only listings remain searchable but cannot enter the main chart. The wider catalog has 11,891 provisional identities; being listed does not imply ranking eligibility.

We considered the activity-bearing catalog, reviewed the likely leading contenders, and checked the unreviewed population against the proposed Top 100 cutoff. This release has 0 unreviewed candidates above that cutoff. Registry pagination, the seeded 500-listing Smithery sample, and package coverage remain incomplete. This is not an exhaustive global ranking.

Categories, ties, and search

Each implementation has one primary competitive category. Category charts filter the same overall score and contain up to 100 eligible entries. A smaller category shows its actual count. Search and pagination preserve published overall and category positions. Ties use the full-precision score followed by stable canonical ID; displayed scores are rounded to one decimal.

Why this method

We tested fixed Smithery/package/GitHub weights of 50/35/15, 60/25/15 and 40/45/15. Those source-weighted models strongly favored whichever adoption source had the higher budget in a mostly single-source population. The selected method gives either adoption source the same leading budget.

The ±10-point leading/supporting tests retain all 100 entries. Removing an adoption source still changes the chart substantially because most servers have only one observed adoption source. The score is useful for comparison, but coverage limits remain real.

Download the scoring comparison workbook →

History and competitive features

Weekly rank movement requires comparable snapshots seven to nine days apart, with the same model, reference and identity-mapping version. A first appearance is labeled New; it never gets an invented prior rank. Trending uses growth in the same npm package’s rolling 30-day downloads across the weekly interval, requiring at least 100 prior downloads and at least 100 additional downloads; growth is capped at 300% for ordering. New daily snapshots also record source dates and scopes; retained windows and changed package scopes are excluded from Trending. Smithery’s undefined counter window is not treated as a monthly growth rate.

New & Rising means newly indexed in a published chart, not newly launched. It requires a comparable weekly baseline without that identity, a first chart appearance after that baseline, a current Top 100 position, and a score of at least 60. These pages show a waiting state until comparable history exists. Dated badges link to preserved snapshots and show the chart population and methodology.

There is currently 1 published chart snapshot.

Verification and corrections

Verified owner confirms publisher control. Usage reviewed means an authorized reviewer assessed submitted aggregate evidence and methodology. Neither status changes the ranking or guarantees the claims are independently audited. Raw uploads remain private; only approved aggregates with publisher consent appear on profiles. Consent can be withdrawn.

Use “Suggest a correction” on any profile to dispute identity, category or attribution. Category and identity changes require review and a recorded reason; they are not instant publisher edits.

Related-party disclosure

mcpverdicts.com’s founder also operates The Agent Times / Agent News. Its public-source listing is evaluated under the same rules. Internal publisher figures, investment claims, and company relationships are excluded from the score.