NPMScan

Rank raw `npm audit --json` output by what to fix first

enrich_npm_audit

Read-only

Given the raw output of npm audit --json (npm 7+'s {vulnerabilities: {...}} format, or legacy npm 6's {advisories: {...}}), parses it directly — no need to re-paste package.json/lockfile content — and runs it through the same remove-now/patch-now/patch-soon/scheduled/monitor ranking prioritize_remediation exposes for hand-built finding lists (a MAL-* advisoryId in the audit report is auto-detected as malware and forces remove-now). npm audit's JSON almost never includes a CVE id (only a GHSA advisory URL), so this resolves each GHSA to its CVE alias via OSV.dev when one exists (ghsaResolvedToCveCount reports how many) before doing the same CISA KEV + FIRST.org EPSS + severity scoring — skipping this step would silently degrade most findings to severity-only ranking despite prioritize_remediation being built around CVE-keyed KEV/EPSS data. Also carries through npm-audit-specific context prioritize_remediation itself has no field for: isDirect (direct vs. transitive dependency) and fixAvailable/fixTarget (npm's own computed fix — note fixTarget can name a different package than the vulnerable one, e.g. bumping a parent to pull in a patched transitive dependency). A package with more than one distinct advisory in the source report only has its first advisory used for ranking; a warning names the package so query_vulnerabilities can be called on it directly for the rest. yarn audit --json and pnpm audit --json use different report shapes and are not supported — use batch_query_vulnerabilities with the project's manifest/lockfile for those instead.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`content`	Yes	Raw stdout of `npm audit --json` — either npm 7+ format ({"auditReportVersion": 2, "vulnerabilities": {...}}) or legacy npm 6 format ({"advisories": {...}}).

Output Schema

TableJSON Schema

Name	Required	Description	Default
`ranked`	Yes
`summary`	Yes
`warnings`	Yes
`inputFormat`	Yes
`skippedCount`	Yes
`totalFindings`	Yes
`uniqueCveCount`	Yes
`ghsaResolvedToCveCount`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed5 schema fields changedSep 25, 2026

addedOutput schema / properties / ranked / items / properties / findingType

Added value: +{
+  "enum": [
+    "malware",
+    "vulnerability",
+    "supply-chain",
+    "install-script"
+  ],
+  "type": "string"
+}

changedOutput schema / properties / ranked / items / properties / tier / enum

Previous value: -[
-  "patch-now",
-  "patch-soon",
-  "scheduled",
-  "monitor"
-]New value: +[
+  "remove-now",
+  "patch-now",
+  "patch-soon",
+  "scheduled",
+  "monitor"
+]

changedOutput schema / properties / ranked / items / required

Previous value: -[
-  "rank",
-  "packageName",
-  "cveId",
-  "advisoryId",
-  "advisoryTitle",
-  "currentVersion",
-  "fixedVersion",
-  "severity",
-  "kev",
-  "epss",
-  "score",
-  "tier",
-  "reason",
-  "npmscanUrl",
-  "cveNpmscanUrl",
-  "isDirect",
-  "fixAvailable",
-  "fixTarget"
-]New value: +[
+  "rank",
+  "packageName",
+  "cveId",
+  "advisoryId",
+  "currentVersion",
+  "fixedVersion",
+  "severity",
+  "kev",
+  "epss",
+  "score",
+  "tier",
+  "findingType",
+  "reason",
+  "npmscanUrl",
+  "cveNpmscanUrl",
+  "advisoryTitle",
+  "isDirect",
+  "fixAvailable",
+  "fixTarget"
+]

addedOutput schema / properties / summary / properties / removeNow
```
Added value: +{
+  "type": "number"
+}
```

changedOutput schema / properties / summary / required

Previous value: -[
-  "patchNow",
-  "patchSoon",
-  "scheduled",
-  "monitor",
-  "kevListedCount"
-]New value: +[
+  "removeNow",
+  "patchNow",
+  "patchSoon",
+  "scheduled",
+  "monitor",
+  "kevListedCount"
+]

AddedSep 4, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds rich behavioral detail: direct parsing, malware auto-detection, GHSA-to-CVE resolution via OSV.dev, and the consequence of skipping that step, plus carrying isDirect/fixAvailable/fixTarget fields. It also discloses the limitation of using only the first advisory per package.

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

Conciseness4/5

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

The description is long but every sentence earns its place—purpose first, then mechanisms, then limitations, then alternatives. It is front-loaded and well-organized. It could arguably be a 5, but the length (though justified) makes it slightly less concise than the crispest examples.

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

Completeness5/5

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

Given the tool's complexity (two input formats, external resolution, extra fields, edge cases), the description covers all critical aspects: parsing, ranking, resolution, field semantics, limitations, and alternatives. An output schema exists, so return values are not required. Nothing an agent needs to call it correctly is missing.

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

Parameters4/5

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

Schema coverage is 100%, so the parameter is already documented. However, the description adds meaningful format details (npm 7+ vs legacy npm 6 structures) beyond the schema's generic description, which helps the agent prepare valid input. Baseline 3 would be acceptable, but the extra format specificity earns a 4.

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?

The description states a specific verb ('rank') and resource ('raw npm audit --json output'), and immediately contrasts it with prioritize_remediation for hand-built lists, and batch_query_vulnerabilities for yarn/pnpm. It leaves no ambiguity about what this tool does and how it differs from siblings.

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

Usage Guidelines5/5

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

It explicitly says when to use (raw npm audit output) and when not (yarn/pnpm audit), naming alternatives (batch_query_vulnerabilities) and also points to query_vulnerabilities for cases where a package has multiple advisories. This is exemplary guidance.

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

All NPMScan tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?