NPMScan

Look up a CVE in the NIST NVD

get_cve

Read-only

Look up authoritative NIST NVD data for one exact CVE ID (e.g. "CVE-2026-2950"), or browse/search NVD by keyword, CVSS severity, CWE, or a publication-date range. Every result is enriched with CISA KEV status (kev, non-null only if this CVE is a confirmed, actively-exploited-in-the-wild vulnerability — treat that as an urgent-patch signal regardless of CVSS score) and FIRST.org EPSS (epss, the probability of exploitation in the next 30 days — a better prioritization signal than CVSS severity alone, which measures impact, not likelihood). For a single cveId lookup, if NVD has no record yet or hasn't scored it, this falls back to the raw MITRE CVE record automatically (source: "mitre" on the result) rather than returning nothing. NVD is NOT npm-scoped — unlike query_vulnerabilities/get_latest_advisories, search results can include CVEs for any ecosystem, so pass keywordSearch (e.g. the package name) to narrow it. Prefer this for the authoritative CVSS score/vector/KEV/EPSS data on a CVE already found via another tool, or when a user pastes a CVE ID/link directly; prefer get_latest_advisories for npm-specific browsing. NVD enforces a strict shared rate limit, so this tool may occasionally ask you to retry in a few seconds — do so rather than assuming failure.

Input Schema

TableJSON Schema

Name	Required	Description
`cveId`	No	Exact CVE ID for a single lookup, e.g. "CVE-2026-2950". When given, search filters below are ignored and should be omitted.
`cweId`	No	Filter by weakness type, e.g. "CWE-79"
`severity`	No	Filter by CVSS v3 base severity
`startIndex`	No	Pagination offset for a search
`keywordSearch`	No	Free-text search, e.g. a package or product name
`publishedSince`	No	Publication date range start (YYYY-MM-DD). Must be given together with publishedUntil.
`publishedUntil`	No	Publication date range end (YYYY-MM-DD). Must be given together with publishedSince; range is capped at 120 days.
`resultsPerPage`	No	Max results for a search (default 10, capped at 50)

Output Schema

TableJSON Schema

Name	Required	Description	Default
`id`	No
`kev`	No
`cves`	No
`cvss`	No
`cwes`	No
`epss`	No
`note`	No
`cveId`	No
`found`	No
`source`	No
`published`	No
`npmscanUrl`	No
`references`	No
`startIndex`	No
`vulnStatus`	No
`description`	No
`lastModified`	No
`totalResults`	No
`resultsPerPage`	No
`dateRangeClamped`	No

TDQS

A4.9/5.0

Behavior5/5

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

Beyond the readOnly/openWorld annotations, the description discloses meaningful behavioral details: KEV and EPSS enrichment semantics, automatic MITRE fallback with a source field, the shared NVD rate limit with retry expectation, and the non-npm-scoped result set. This materially helps an agent interpret outcomes and avoid false failure conclusions.

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

Conciseness5/5

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

The description is long but every sentence earns its place: core purpose, enrichment semantics, fallback behavior, ecosystem scope, tool-selection guidance, and rate-limit caveat. It is front-loaded with the primary lookup/search purpose before moving to interpretive guidance and edge cases.

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, the description covers the critical operational facts: single-ID vs search behavior, fallback to MITRE, KEV/EPSS interpretation, ecosystem scope, and retry-on-rate-limit. The presence of an output schema means return-value details do not need to be repeated in the description.

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?

The input schema already documents all 8 parameters, so the baseline is 3. The description adds value above the schema by explaining the cveId-first behavior, its override of search filters, the fallback when no NVD record exists, and why keywordSearch should be used to narrow the otherwise broad NVD result space.

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 opens with a specific verb-resource pair: 'Look up ... NIST NVD data' for one exact CVE ID or search NVD by several dimensions. It also explicitly contrasts with sibling tools by noting NVD is not npm-scoped, so an agent can distinguish get_cve from query_vulnerabilities and get_latest_advisories.

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?

The description gives explicit selection guidance: prefer this for authoritative CVSS/vector/KEV/EPSS data on an already-discovered CVE or when a user pastes a CVE ID/link, and prefer get_latest_advisories for npm-specific browsing. It also tells the agent to pass keywordSearch to narrow open-world results.

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

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.3/5.0

Disambiguation4/5

Each tool targets a distinct workflow—install script analysis, transitive dependency resolution, batch OSV queries, provenance verification, CVE lookup, advisory browsing, package metadata, exact-version checks, single-package vuln checks, and search. The only mild overlap is that several get_/query_ tools return vulnerability data, but the descriptions clearly delineate when to use each.

Naming Consistency5/5

All tool names follow a consistent snake_case verb_noun pattern: get_package, query_vulnerabilities, analyze_transitive_dependencies, check_package_provenance, etc. There are no mixed casing styles or vague verbs, making the set highly predictable.

Tool Count5/5

10 tools is well-scoped for an npm security scanning server. Each tool earns its place by covering a distinct facet of the domain without redundancy or bloat.

Completeness4/5

The surface covers package discovery, metadata, exact-version vulnerability checks, batch scanning, transitive graph analysis, install-script heuristics, provenance, advisories, and CVE enrichment. Minor gaps remain—e.g. no full tarball code review and maintainer-history red flags are explicitly out of scope—but core agent workflows are covered.

Resources

Need Help?