Use tashan

Start with the stack you already have.

Most advice tells you what to install. The better question is what you are already running that should not be there: a server the author archived, a package marked deprecated, a name that shadows an official one. One command answers it.

#1 Audit what you already run

nothing is uploaded
npx tashan-cli doctor

Reads the agent config on this machine: Claude Code, Claude Desktop, Cursor, VS Code, Windsurf, ~/.claude/skills/. Matches every entry against the Index.

It prints only what needs a decision. A real machine has a hundred-odd skills that are simply fine, and listing each one buries the two servers that matter. Those are counted instead; --all lists every row.

It is local, and there is nothing to opt out of. doctor reads files on your disk and compares them against a public JSON file. No account, no key, no beacon, no upload. If we ever add aggregate contribution it will be a separate, explicit command, and the rule we hold ourselves to is that any data that feeds a score must be published. A score computed from numbers only we can see is the thing this site exists to be an alternative to.

Exit code is 2 when something needs attention, so it drops into CI: npx tashan-cli doctor || echo "stack needs a look". Add --json to pipe it.

We measure this package the same way. Being asked to npx an unfamiliar package in order to find risky packages is a fair thing to be suspicious about. So tashan-cli is in the Index like anything else, scanned by the same scanner, scored by the same rules, including the parts that do not flatter us. Today: no install script. Zero dependencies, so nothing is pulled in behind it. One maintainer, which our own scorer counts against it. No build provenance, which puts us in the same majority we point at for exactly that. That last one is not fixed, and the reason is worth stating. npm generates a provenance attestation from a public source repository; ours is private, so publishing from CI signs the release but cannot attest it. Publishing runs from a workflow (.github/workflows/publish-cli.yml) with no long-lived token, and that workflow fails the release if it ever claims an attestation it did not get. That is how we found this. Making the CLI attestable means publishing it from a public repository: a decision we have not taken, not a task we have finished. Read the dossier: tashan-cli ›

#2 Find what is worth adding

npx tashan-cli search database
npx tashan-cli top browser
npx tashan-cli info context7

Or browse in the page: the full Index, filtered by type, activity and depth — or jump straight to a category such as Database, Browser & Web or Dev Tools & CI. Every row links to a dossier showing the arithmetic behind its score.

#3 Install it

npx tashan-cli add context7 --client claude

Prints the exact command or config block for claude, cursor, desktop, codex or plain npx. Generated from the same logic as the website, so the terminal and the page never disagree.

For maintainers

If you publish a capability, embed its measurement. The badge is generated from the same data as the Index and updates when the evidence does — including downward. That is the point of it.

![tashan](https://tashan.sh/badge/pkg-upstash-context7-mcp.svg)

Your slug is on your capability page. Nothing about a badge, a claim or a payment changes a score — see the methodology.

Let your agent ask before it installs

Everything above assumes you are the one typing. If you would rather your coding agent check before it recommends or installs anything, install tashan into it once:

claude mcp add tashan -- npx -y tashan-cli mcp

Three tools: find a capability for a job, check one before installing it, audit the config already on the machine.

All three are free; nothing about risk is ever behind the paid tier.

For agents and machines

Scores change as the evidence changes, so cite the date. Attribution: tashan (tashan.sh), measured <date>.

Browse the Index › How we measure ›