MCP package and supply-chain best practices

To score well on VerifyMCP, a packaged MCP server has to be safe to run today and able to prove where it came from. In practice that means no malware verdict and no unpatched critical CVE (either one caps your score at zero), plus a committed lockfile, no risky install scripts, patched dependencies and a recent release. On the provenance side it means a verifiable public source repository, an OSI licence, a security disclosure policy, and signed build provenance. Supply-chain signals carry 36% of the score and provenance 24%, with the remaining 40% scored from a sandbox capture of the schema your package serves (schema quality 25%, tool coverage 15%). Those two are always counted: if we have not captured your schema yet, they score 0 and say so. Start with the supply-chain guides. Every signal below links to a focused fix guide that tells you what we checked and how to make it pass on the next crawl.

What is a packaged MCP server?

A packaged MCP server is code published to a registry that clients download and run: an npm module, a PyPI or NuGet package, an OCI container image, or an MCPB bundle. Unlike a remote server, there is no live endpoint for us to probe. The trust question is different. When someone installs your package, they are running your code and every dependency it pulls in on their own machine, so trust hinges on two things: whether that code is safe to run today, and whether you can prove where it came from and who stands behind it.

VerifyMCP scores packages on verifiable signals. Half the rubric is what only a package can be judged on: 30% supply-chain security and 20% provenance and transparency. The other half is the MCP schema your package actually serves, captured by running it in an isolated sandbox and scored by the same shared core as a remote endpoint (20% schema quality and AI usability, 15% stability and change management, 10% tool coverage, 5% capabilities).

All six categories are always counted. Sandbox capture is enabled for npm, PyPI, NuGet, OCI and MCPB; until we have a verified capture of your current version, the four shared categories score 0 and the finding says which of the reasons applied. Stability additionally needs two captures to compare, so it reports that it has nothing to compare yet until a second one lands. The container and bundle types are scored on the subset of the package-only signals that apply to them.

If you are building a package rather than fixing an existing one, the per-ecosystem build guides walk through an npm, PyPI, NuGet, OCI or MCPB package from scratch.

Supply chain (36%)

Whether the code is safe to run right now. We read the published artifact and its metadata, and consult vendor sources for malware and known vulnerabilities (CVEs are matched against public advisory databases). Two signals, a critical malware verdict and an unpatched critical CVE, cap the whole package score at zero.

• Commit a lockfile: pin your dependency tree so installs are reproducible and auditable.
• Patch known CVEs: resolve known vulnerabilities in your dependencies, especially unpatched critical ones.
• Malware findings: clear any malware verdict raised against your package or its dependencies.
• Avoid install scripts: drop lifecycle install scripts that run arbitrary code at install time.
• Keep it maintained: publish updates recently enough to show the package is actively supported.

Provenance and transparency (24%)

Whether you can prove where the code came from and who stands behind it. A reachable source repository underpins several of these, since we read it for the licence and the security policy, so linking a verifiable repository is often the highest-leverage single fix.

• Verifiable source repository: link a reachable public repository that matches the published package.
• OSI licence: publish under a recognised OSI-approved licence so users know their rights.
• Security disclosure policy: tell researchers how to report vulnerabilities to you responsibly.
• Signed build provenance: attach a signed attestation, following the SLSA provenance model, that binds the artifact to the source and CI workflow that built it.

How is the score calculated?

The package rubric sets out exactly how these signals combine, which ones cap the score, and why an unverifiable signal counts against you rather than being given the benefit of the doubt. For the wider picture of how VerifyMCP grades both packages and remote servers, see the how we score overview.

Start with the supply-chain guides, since they carry the most weight and the two hard caps live there. Each guide tells you what we checked, why it matters, and what a passing signal looks like.