CVE Risk Check

Triage dependency vulnerabilities

triage_dependencies

Read-onlyIdempotent

Use this when the user wants to know which vulnerable dependencies to fix first, such as "which dependencies in this package-lock.json should I upgrade first?" or "triage my requirements.txt". Pass the text of a lockfile (package-lock.json, pnpm-lock.yaml, yarn.lock, poetry.lock, uv.lock, Cargo.lock, go.sum or go.mod), a package.json or a requirements.txt as manifest, or a packages list of ecosystem, name and exact version (npm, pypi, go, crates.io, maven, rubygems, nuget, packagist); only names and versions are read. Returns fix_first: by default the 3 packages to upgrade first, each with a priority (malicious, exploited, likely, routine or unknown), one line on why, the CVE ids and the version that fixes it, then a short list of the other vulnerable packages and a count per priority. It matches exact package versions to known advisories; it does not scan code or show that the vulnerable code is reached.

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": "triage_dependencies"
  }
}

Input Schema

Name	Required	Description
`limit`	No	How many packages to put in fix_first (default 3)
`manifest`	No	The text of one dependency file. Lockfiles give exact versions: package-lock.json, pnpm-lock.yaml, yarn.lock (npm), poetry.lock, uv.lock (PyPI), Cargo.lock (crates.io), go.sum or go.mod (Go). A package.json is read at the lowest version of each range, a requirements.txt only for == pins. Only names and versions are read; workspace, git, path and url entries are skipped. Every package is checked, up to 3000 in one call; past that, unchecked counts the rest.
`packages`	No	Installed packages: ecosystem (npm, pypi, go, crates.io, maven, rubygems, nuget, packagist), name and exact version. Up to 300.

Output Schema

Name	Required	Description
`as_of`	Yes
`clean`	Yes
`counts`	Yes
`notice`	Yes
`source`	Yes
`status`	Yes
`checked`	Yes
`message`	No
`skipped`	No
`summary`	Yes
`fix_first`	Yes
`truncated`	No	True when the input held more than 3000 packages and only the first 3000 were checked
`unchecked`	No	How many packages were not checked because of that cap
`advisories`	No
`vulnerable`	Yes
`not_triaged`	Yes
`skipped_count`	No
`also_vulnerable`	Yes
`also_vulnerable_total`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedNov 4, 2026

changedInput schema / properties / manifest / description

Previous value: -"The text of one dependency file. Lockfiles give exact versions: package-lock.json, pnpm-lock.yaml, yarn.lock (npm), poetry.lock, uv.lock (PyPI), Cargo.lock (crates.io), go.sum or go.mod (Go). A package.json is read at the lowest version of each range, a requirements.txt only for == pins. Only names and versions are read; workspace, git, path and url entries are skipped."New value: +"The text of one dependency file. Lockfiles give exact versions: package-lock.json, pnpm-lock.yaml, yarn.lock (npm), poetry.lock, uv.lock (PyPI), Cargo.lock (crates.io), go.sum or go.mod (Go). A package.json is read at the lowest version of each range, a requirements.txt only for == pins. Only names and versions are read; workspace, git, path and url entries are skipped. Every package is checked, up to 3000 in one call; past that, unchecked counts the rest."

addedOutput schema / properties / truncated / description

Added value: +"True when the input held more than 3000 packages and only the first 3000 were checked"

addedOutput schema / properties / unchecked

Added value: +{
+  "description": "How many packages were not checked because of that cap",
+  "type": "integer"
+}

Changed1 schema field changedOct 9, 2026

changedInput schema / properties / manifest / description

Previous value: -"The text of a package-lock.json (best: exact versions), a package.json (ranges read at their lowest version) or a requirements.txt (only == pins). Only names and versions are read."New value: +"The text of one dependency file. Lockfiles give exact versions: package-lock.json, pnpm-lock.yaml, yarn.lock (npm), poetry.lock, uv.lock (PyPI), Cargo.lock (crates.io), go.sum or go.mod (Go). A package.json is read at the lowest version of each range, a requirements.txt only for == pins. Only names and versions are read; workspace, git, path and url entries are skipped."

AddedOct 5, 2026

TDQS

A4.2/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already cover read-only/idempotent/non-destructive, and the description adds materially beyond them: only names and versions are read, workspace/git/path/url entries are skipped, matching is exact-version against known advisories, and it explicitly does not scan code or prove reachability. It also discloses caps (3000 packages per call, 300 in the packages list) and what happens past the cap (unchecked count), which the annotations do not convey.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded correctly with the trigger condition, but the second sentence is a run-on that enumerates all eight lockfile types and all eight ecosystems, duplicating the schema enum and inflating length. The return-value sentence is also longer than needed given an output schema exists.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers scope, accepted inputs, coverage limits, and the explicit non-goal (no code scanning or reachability), which is the main way an agent could misuse it. With an output schema present, explaining return shape is optional and the description's version is slightly redundant rather than necessary; no critical gap remains.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents limit, manifest and packages in detail. The description restates the accepted file types and ecosystems and adds the useful framing that package.json is read at the lowest version of each range, but this largely duplicates schema text rather than adding new meaning. Baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource (triage vulnerable dependencies into a fix-first ranking) and immediately differentiates itself from the sibling CVE-lookup tools by framing the job as prioritization, not lookup. The returned artifact (fix_first with priority tiers) is named, so an agent knows exactly what it gets.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Opens with an explicit trigger ("Use this when the user wants to know which vulnerable dependencies to fix first") and backs it with two concrete user-utterance examples, which is strong when-to-use guidance. It stops short of naming the alternatives (check_cve/check_cves) or stating when this tool is the wrong choice, so it is not a full routing rule.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All CVE Risk Check tools Inspect

Try in Browser

Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.