Check a whole lockfile for known-malicious dependencies (free, no API key)
check_lockfileChecks every exactly pinned dependency in a lockfile against known malicious-package advisories, helping you audit dependencies before install or when reviewing an unfamiliar project.
Instructions
Checks every exactly-pinned dependency in a lockfile against published malicious-package advisories (OSV / OpenSSF). One call covers the entire dependency tree.
WHEN TO USE: before installing dependencies, or when auditing a project you did not write. This is the broadest and cheapest check, so start here. Prefer scan_artifact when you need to know what a specific package DOES rather than whether it is already known malware, and scan_lockfile_deep to ask that of every package in the tree. Prefer known_bad_lookup when you already hold a sha256 of a file rather than a lockfile.
COST AND EFFECTS: free, no API key, no payment. Read-only. Reads the lockfile from the working
directory itself, so a large lockfile never has to be pasted through the model context. Give
packages instead to ask about specific versions, and no lockfile is read.
LIMITS: only exactly-pinned versions can be answered. A range such as ^5.0.0 has no definitive
answer, because a compromised release usually sits between clean ones (chalk 5.6.1 was malware
while 5.3.0 and later releases were not). Entries with no published registry identity
(file:, link:, workspace:, git) are counted under skipped rather than silently dropped.
READING THE RESULT: malicious lists confirmed known-malware versions with advisory ids, and
a result with any of them is marked as an error, so act on it rather than summarising it. An empty malicious list is an all-clear ONLY when unverified is also empty AND truncated
is false. Anything under unverified could not be checked and must never be reported as clean.
truncated: true is worse than that: the lockfile ran past the per-request package limit, and
the packages past it are in NEITHER list. They were never looked at, and checked counts only
the ones that were. When it is true, run this once per workspace with path, or pass the rest of
the tree as lockfile text, before telling anyone the dependencies are clean.
Tool call template
This tool declares no required parameters. Add optional parameters from the input schema as needed.
{
"id": 1,
"jsonrpc": "2.0",
"method": "tools/call",
"params": {
"arguments": {},
"name": "check_lockfile"
}
}Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | Lockfile path relative to the working directory, e.g. "package-lock.json" or "apps/web/pnpm-lock.yaml". Omit to auto-detect package-lock.json, npm-shrinkwrap.json, yarn.lock, or pnpm-lock.yaml in the working directory. Only those filenames are read. | |
| lockfile | No | Full text contents of a lockfile, for when it is not on disk (for example fetched from a PR diff). Supplying this skips reading from disk. Prefer omitting it and letting the tool read the file, which keeps a large lockfile out of the context window. | |
| packages | No | Exact name@version identities to check instead of a lockfile, e.g. ["chalk@5.6.1", "@babel/core@7.24.0"]. Use it when you know which versions you care about. Give this or `path` or `lockfile`, not more than one kind: no lockfile is read or sent. |