Skip to main content
Before anyone runs your server, they find it on a package registry — and a listing that doesn’t resolve, hides its license, or links no source loses the user before the first npx. mcpscore --package audits that surface:

What it checks — and what it deliberately doesn’t

A package audit reads the package’s registry metadata only. The package is never downloaded and never executed — the report’s package.executed field records that, permanently false. The six packaging rules check that the coordinate resolves, the pinned version exists, the release isn’t withdrawn/yanked, and that a source repository, license, and description are declared — see the packaging rules for severities. A package audit answers “is this server well published?” — not “does it speak MCP?”. For the second question, run the server itself:

Scores are not comparable to server scores

Package audits run only the packaging rules, and server audits run none of them — the two rule sets are disjoint, so their score/max_score share no denominator. In the JSON report, a non-null package object is the marker that a report is a package audit; consumers that aggregate scores must branch on it (see the stability contract).

See also

Rules Reference

The six packaging rules and their severities

Stability Contract

The package report block, field by field