How tashan measures

tashan exists because the AI-capability ecosystem has massive supply and almost no honest signal. So the first rule is: we score capabilities on public evidence — and we show every component. Here is exactly what we count, how tashan score is computed, and what we deliberately refuse to do.

No user tracking. tashan installs nothing, instruments no one, and reads no private data. Every number here is derived from public sources — the MCP registry, npm, and public GitHub configs — and is re-derivable by anyone.

Coverage

We ingest the official MCP registry as the spine of coverage: thousands of capabilities with their canonical name, description, source repository, package, and active/deprecated status. On top of that we mine public GitHub configs (mcp.json, claude_desktop_config.json, .cursor) for real-world usage the registry can't see. The goal is simple: track everything, then rank it on evidence.

What we measure

The tashan score

The single Index number is a transparent composite — and every input is shown on the capability's page, never hidden:

raw = mean(Upkeep, Freshness) × gate(Adoption) × coverage
tashan score = calibrate(raw)
gate = 0.30 + 0.70 × Adoption⁄100  ·  coverage discounts a score built on thin evidence
calibrate = piecewise-linear, raw 50 → 68; strictly order-preserving

Why it is called the tashan score, not a trust score. We measure whether people use a capability and whether it is kept alive. We do not audit it: there is no CVE scan, no prompt-injection review, no reading of its code. Calling that "trust" claimed something the arithmetic does not support, and this page had to walk it back a paragraph later. The number is our measurement, on public evidence, and it is named accordingly.

Upkeep and freshness set the ceiling; adoption decides most of what a capability actually scores. That balance is deliberate and it was wrong before: upkeep and recency both saturate near 100 for any repo that was pushed recently, so when the gate floor sat at 0.6 a well-kept capability nobody used still kept 60% of the score, and a plugin with 30 stars outranked packages with thousands of weekly downloads. The floor is now 0.30, which means real use — not a recent commit — is what separates the top of the Index from the middle. Adoption itself blends npm downloads (log-scaled) and config reach. Capabilities we can't yet measure quality on are shown unrated — plainly marked, never invented. When retention and evals land, they'll be separate, labelled scores, never quietly folded into one number.

Missing evidence is not a bad score. Upkeep is scored only across the axes we can actually read for that capability — maintainer count, release cadence, freshness — and rescaled over those, so a capability that simply isn't on npm is no longer marked down for metadata that does not exist. It used to be: anything without npm was capped at 35/100 however well kept it was, which ranked a 51,000-star plugin pushed yesterday below a package with 422 weekly downloads. Instead, thin evidence discounts tashan score in proportion to how much of the picture we have, and "we found no adoption signal" is treated no better than a measured-but-low one — absence of evidence must never outscore evidence of absence. As we fill in contributor and release data for non-npm repositories, that discount shrinks on its own, because the coverage becomes real.

Why there is a calibration step. The raw formula multiplies three factors that are each at most 1, so it decides the order well and lands in a useless range. A capability with no adoption signal has gate = 0.30, which caps it at about 27⁄100 however well kept it is — and 38% of what we measure has neither a download count nor a star count. The result was half the index inside a 13-point band, 98% below 50, and "well kept but unproven" published as a number that reads as bad. The calibration is a fixed, strictly order-preserving stretch of that raw number onto the published scale: it cannot move any capability past another, it only decides how far apart they are printed. It is deliberately not a percentile — a percentile would re-baseline every night as the index grows, so a badge minted today would quietly mean something different next week. The middle of the index sits near 39 rather than 50, because a median of 50 would claim we think half of these are proven when for most of them we have no usage evidence either way.

When we change the ruler, we say so. Every stored score records which version of the scorer produced it. That matters because the scorer was rewritten four times in one week: one capability reads 43, 43, 43, 42, 40 across those days and every step down was us, not the capability. Comparing across that line would report our own recalibration as something declining, so we do not do it — a trend is only ever computed within a single scorer version, and a version change starts the clock again. The current version is s2, from 30 July 2026.

A capability the registry removes stays visible to you. The MCP registry marks servers deleted, and its moderation policy names spam, malware and illegal content as the usual reasons. We keep that row rather than dropping it: it is never scored, never ranked and never recommended, but it is still there so doctor can tell you if it is in your config. Deleting the record would have turned the most serious thing we can tell you into silence.

What we deliberately don't do

The security audit

Separate from the score, and deliberately so: well maintained and nothing known is wrong with it are different claims, and a popular, actively maintained package can still ship a vulnerability. Folding one into the other would hide exactly the case you most need to see. Four layers, all from public evidence:

What the audit does not do, just as plainly: no source-code review, no execution or sandboxing, no testing of outputs for prompt injection, and no coverage of capabilities with no npm package to resolve. A clean audit means nothing known is wrong.

What this is not (yet) — stated plainly

The roadmap

Each is a separate, defensible measurement. Stacked, they become something no directory can copy: an evidence base for what actually works.

‹ Back to the Index