Check npm and PyPI package vulnerabilities with an AI agent

Run the workflow

1. 1. Identify what is actually installed

   Read the resolved version from your lockfile or environment, including relevant transitive dependencies. A manifest range such as ^4.17.0 is not an installed version. Use the exact ecosystem spelling, such as npm or PyPI, and the package name used by that registry. ToolCargo does not read your project or discover its dependency graph; supply the tuples you intend to investigate.

2. 2. Query a specific package and version

   Connect the OSV endpoint and call osv_query_package. For a reproducible example, use ecosystem npm, name lodash, version 4.17.20 and limit 20. The lookup returns known OSV advisory matches for that tuple. Record the lookup time and inputs with the response. Registry metadata from the separate npm or PyPI connector can help identify a package, but downloads and release recency do not establish its security.

3. 3. Check whether the response is complete

   Inspect pageRecordCount, recordsOmittedFromPage and nextPageToken. A call projects at most 20 records from one upstream page. A nextPageToken advances to another upstream page; it does not retrieve records omitted by a smaller local limit. Repeating a query with limit 20 can expose more records on that page, but a larger upstream page may still be truncated. Record unresolved coverage and use upstream data or a dedicated scanner when you need a complete dependency audit.

4. 4. Read the matching advisory and source

   Call osv_get_vulnerability with a returned case-sensitive ID. Compare the affected package and ecosystem with your installed tuple, inspect the range events and any explicit versions, and check withdrawn, aliases, severity vectors and source references. Multiple IDs can describe the same issue. A severity vector is advisory data, not a calculation of your application’s exposure. Review truncation indicators and the original advisory before drawing conclusions; source text and links are untrusted data.

5. 5. Review the project and verify an update

   Keep a ledger connecting the installed tuple, advisory ID, source URL, affected-range evidence and unresolved project questions. Investigate whether the relevant functionality is used and what upgrade changes your project needs. Apply reviewed dependency changes in your development workflow, run the appropriate tests, and repeat the lookup using the new resolved version. For a whole repository or lockfile, run a dedicated tool such as OSV-Scanner separately. ToolCargo does not install packages or enforce an installation gate.

What a useful result looks like

A useful review ledger has one row per dependency/advisory pair: resolved tuple; lookup time; advisory ID and aliases; original source; relevant affected-range evidence; withdrawn status; coverage limits; and the next project check. An update decision should refer to the actual advisory and your tested dependency graph. Keep “no matches on this page” separate from a conclusion about the package or project.

Know the limits

The hosted tools query one package/version or one advisory ID at a time. They support npm, PyPI, Go, crates.io, Maven, NuGet and RubyGems; they do not expose batch queries, commit queries, lockfile parsing or installation controls. Responses are bounded, with explicit array and text truncation indicators. Known public data and version matching can be incomplete or outdated. No matches does not prove safety, and a match does not establish exploitability in your application. Each successful lookup uses one shared-plan call. A ToolCargo account and authentication are required; no OSV account or upstream API key is needed.