Without a lockfile, install resolves dependencies fresh every time, so two installs of the same version of your package can pull different transitive code. That: makes builds non-reproducible, so a compromised transitive dependency can slip in without any change to your own code; defeats auditing: there's no…

Commit a lockfile for your MCP server package

Q: How to fix it

Generate the lockfile locally and commit it to your repository (don't .gitignore it). Pick your ecosystem:

What we checked

We looked in your package’s source repository for a committed lockfile: the file that pins every dependency (direct and transitive) to an exact version and hash. If no lockfile is committed, the supply-chain score is reduced. If we couldn’t read the repository at all, the signal is unverifiable and scores 0; fix the repository link first in that case.

Why it matters

Without a lockfile, install resolves dependencies fresh every time, so two installs of the same version of your package can pull different transitive code. That:

makes builds non-reproducible, so a compromised transitive dependency can slip in without any change to your own code;
defeats auditing: there’s no canonical record of exactly what shipped, so a scan for known vulnerabilities may not reflect what a user actually installs;
removes the integrity hashes that let a client detect tampering.

A committed lockfile is one of the cheapest, highest-signal trust improvements a package can make.

How to fix it

Generate the lockfile locally and commit it to your repository (don’t .gitignore it). Pick your ecosystem:

# Generates package-lock.json
npm install

git add package-lock.json
git commit -m "Add lockfile for reproducible installs"

# uv (recommended): generates uv.lock
uv lock

# or pip-tools: compile requirements.txt -> a pinned, hashed lockfile
pip-compile --generate-hashes -o requirements.txt requirements.in

git add uv.lock   # or requirements.txt
git commit -m "Add lockfile for reproducible installs"

# Opt in to a committed lockfile, then restore to generate it
dotnet restore --use-lock-file
# (or set <RestorePackagesWithLockFile>true</RestorePackagesWithLockFile> in the .csproj)

git add packages.lock.json
git commit -m "Add NuGet lockfile for reproducible installs"

# go.sum is your lockfile: it records the hash of every module
go mod tidy

git add go.mod go.sum
git commit -m "Commit go.sum for verifiable module hashes"

# For a published crate, commit Cargo.lock so builds are reproducible
cargo generate-lockfile

git add Cargo.lock
git commit -m "Commit Cargo.lock for reproducible builds"

How we re-check

We re-scan the repository on our next crawl of your package. Once the lockfile is on the default branch at the repository root, the signal records the lockfile as present on the following score refresh.

Give this to your AI

Paste this into Claude Code (or any coding agent) from inside your server's repository. It states the failing signal, the outcome we re-check for, and the format the fix has to take.

Prompt

Context: this repository publishes an MCP server. VerifyMCP's lockfile
check failed, which means we read your source repository but found no
committed lockfile pinning every dependency, direct and transitive, to
an exact version and hash.

Goal: a lockfile matching your manifest is committed to the default
branch at the repository root, so the next crawl records the lockfile
as present.

Do this:
1. Identify the package ecosystem (npm, Python, .NET, Go, or Rust).
2. Generate the lockfile locally:
   - npm: `npm install` produces `package-lock.json`.
   - Python: `uv lock` produces `uv.lock`, or
     `pip-compile --generate-hashes -o requirements.txt requirements.in`
     for a pinned, hashed `requirements.txt`.
   - .NET: `dotnet restore --use-lock-file` produces
     `packages.lock.json` (or set `<RestorePackagesWithLockFile>true`
     in the `.csproj`).
   - Go: `go mod tidy` maintains `go.sum`.
   - Rust: `cargo generate-lockfile` produces `Cargo.lock`.
3. Commit the lockfile to the repository, do not `.gitignore` it.
4. Add a CI step that fails on drift between the lockfile and the
   manifest (`npm ci`, `uv sync --locked`, `dotnet restore
   --locked-mode`), so it can't go stale silently.

Rules:
- Never commit a lockfile that doesn't match the current manifest just to
  have a file present; a stale lockfile misrepresents what actually
  installs and is worse than none.
- If the check instead reported that it couldn't read the repository at
  all, fix the repository link first; that is a separate signal, not
  this one.

Report back: the ecosystem, the lockfile file committed, and confirmation
the CI step now fails on drift.

Reference: https://verifymcp.io/docs/packages/lockfile