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

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

Changed4 schema fields changedSep 1, 2026

changedInput schema / properties / cveId / description

Previous value: -"Exact CVE ID for a single lookup, e.g. \"CVE-2026-2950\". When given, all search filters below are ignored."New value: +"Exact CVE ID for a single lookup, e.g. \"CVE-2026-2950\". When given, search filters below are ignored and should be omitted."

addedInput schema / properties / publishedUntil / $ref
```
Added value: +"#/properties/publishedSince"
```
removedInput schema / properties / publishedUntil / pattern
```
Removed value: -"^\\d{4}-\\d{2}-\\d{2}$"
```
removedInput schema / properties / publishedUntil / type
```
Removed value: -"string"
```

AddedSep 1, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Annotations already establish readOnlyHint=true and destructiveHint=false, and the description adds significant behavioral context beyond that: results are enriched with KEV and EPSS, single-ID lookups fall back to MITRE records with source: 'mitre', and NVD has a shared rate limit that may require retries. This gives the agent practical expectations about data provenance, urgency semantics, and transient failures.

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: purpose, enrichment semantics, fallback behavior, scope warning, routing guidance, and rate-limit caveat. The core action is front-loaded in the first sentence, and the additional caveats are each relevant to avoiding incorrect agent behavior. Nothing reads as filler.

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?

For a tool with 8 parameters, two operating modes, and cross-ecosystem scope, the description covers all critical decision points: exact ID lookup vs search, non-npm scope, fallback source, priority signals, rate limiting, and sibling-tool routing. The output schema exists, so the absence of return-field detail is not a gap.

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 description coverage is 100%, so the baseline is 3. The description adds meaningful context on top of the schema: it explains that keywordSearch should carry a package name to narrow the cross-ecosystem NVD results, clarifies that cveId mode ignores search filters, and explains the purpose of EPSS/KEV fields. This goes beyond the raw schema but not exhaustively for every parameter.

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 and resource: 'Look up authoritative NIST NVD data' for one exact CVE ID or as a search/browse tool. It clearly distinguishes itself from sibling tools by stating that NVD is NOT npm-scoped, unlike query_vulnerabilities/get_latest_advisories. This makes the tool's purpose immediately identifiable.

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 when-to-use guidance: '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.' It also tells the agent to pass keywordSearch to narrow results because NVD covers all ecosystems. This is strong routing guidance with named alternatives.

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.4/5.0

Disambiguation4/5

Most tools have clearly distinct scopes, such as flat vs. transitive vulnerability checks and per-package vs. GitHub-repo audits. The main ambiguity is that several tools all ultimately report OSV/NVD findings or perform install-script risk checks, though the descriptions do draw clear boundaries and include cross-references to steer selection.

Naming Consistency5/5

Every tool follows a consistent lowercase snake_case verb_noun pattern, e.g. analyze_install_script, check_maintainer_changes, prioritize_remediation. The naming is predictable and makes the action and target of each tool immediately clear.

Tool Count3/5

At 22 tools, the surface is at the heavy end of the rubric and pushes beyond the typical 3-15 well-scoped range. The tools are individually purposeful and broad in coverage, but the count is high enough that an agent faces a large decision space and several workflows that overlap or compose in complex ways.

Completeness5/5

The set covers the full npm supply-chain assessment lifecycle: discovery, metadata lookup, vulnerability scanning, transitive dependency analysis, license checks, install-script analysis, maintainer and provenance checks, SBOM generation, dependency diffs, upgrade simulation, remediation prioritization, and alternative suggestion. There are no obvious dead ends or major missing operations for the stated domain.

Resources

Need Help?