NPMScan

Generate a CycloneDX or SPDX SBOM

generate_sbom

Read-only

Given the same inputs batch_query_vulnerabilities accepts — either a flat {packages:[...]} list, or raw package.json / lockfile / CycloneDX JSON / SPDX JSON content via content — emits a spec-valid CycloneDX 1.6 or SPDX 2.3 JSON document (pick with format, default 'cyclonedx') with npmscan's own OSV.dev vulnerability findings and registry license data embedded in each spec's native fields: CycloneDX gets a top-level vulnerabilities[] array (VEX analysis.state: 'in_triage' — an unreviewed automated finding, not a claim of exploitability) and per-component licenses[]; SPDX (which has no vulnerabilities array in 2.3) gets one externalRefs SECURITY/advisory entry per finding and licenseDeclared/licenseConcluded. Only a flat package inventory is known here, so the CycloneDX dependencies[] transitive graph and any SPDX package hierarchy are intentionally omitted rather than fabricated. Set includeVulnerabilities/includeLicenses to false to skip either enrichment pass (faster, no registry/OSV calls for that pass); pass policy (same shape as check_license_compliance) to also get per-package compliance context; componentName/componentVersion name the SBOM's own root component/document if known. When content is a package.json, peerDependencies are excluded by default (a peer is often intentionally left unresolved by the consumer) — pass includePeerDependencies: true to include them as SBOM components too, since an SBOM meant to be complete shouldn't silently omit a whole dependency category.

Input Schema

TableJSON Schema

Name	Required	Description
`format`	No	SBOM format to emit. Default 'cyclonedx'.
`policy`	No	License allow/deny policy, same shape as check_license_compliance. Omit for the default policy.
`content`	No	Raw dependency inventory content: package.json, package-lock.json, yarn.lock, pnpm-lock.yaml, CycloneDX JSON, or SPDX JSON. Use this OR `packages`, not both.
`packages`	No	Explicit package list (1-1000 items, capped to 100 when includeLicenses is on). Use this OR `content`, not both.
`componentName`	No	Name of the SBOM's own root component/document, if known.
`includeLicenses`	No	Resolve registry license data and embed it natively. Default true.
`componentVersion`	No
`includeDevDependencies`	No	Ignored when using `packages`; only applies when `content` is a manifest/lockfile format that distinguishes dev dependencies.
`includeVulnerabilities`	No	Query OSV.dev and embed findings natively. Default true.
`includePeerDependencies`	No	Ignored when using `packages`; only applies when `content` is a package.json. peerDependencies are excluded by default — set this to also include them as SBOM components.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`sbom`	Yes
`format`	Yes
`policy`	No
`warnings`	No
`inputFormat`	No
`ignoredCount`	No
`enrichmentNote`	No
`parsedPackageCount`	Yes
`totalVulnerabilities`	Yes
`licenseViolationCount`	No
`packagesWithVulnerabilities`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedSep 20, 2026

addedInput schema / properties / includePeerDependencies

Added value: +{
+  "description": "Ignored when using `packages`; only applies when `content` is a package.json. peerDependencies are excluded by default — set this to also include them as SBOM components.",
+  "type": "boolean"
+}

AddedSep 4, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Adds substantial behavior beyond the readOnlyHint/openWorldHint/destructiveHint annotations: discloses that OSV.dev and registry calls occur, clarifies VEX analysis.state 'in_triage' is an unreviewed automated finding (not an exploitability claim), explains SPDX 2.3 has no vulnerabilities array so externalRefs are used, and states the transitive dependencies[] graph is intentionally omitted rather than fabricated. No contradiction with annotations.

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?

Front-loaded with the core purpose and format details in the first sentence, and every subsequent sentence carries behaviorally meaningful information. However, it is a dense wall of text across four long paragraphs that could benefit from structural separation; the density is justified by tool complexity but the length is at the upper edge.

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?

Highly complete for a complex 10-parameter tool with nested objects and an output schema: it explains output-format differences (CycloneDX vulnerabilities[]/licenses vs SPDX externalRefs/licenseDeclared), enrichment and policy options, intentional omissions, and cross-tool parameter reuse. 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 high (90%), but the description still adds value: enumerates the content formats (package.json, package-lock.json, yarn.lock, pnpm-lock.yaml, CycloneDX/SPDX JSON) beyond the schema, documents the 100-item cap on packages when includeLicenses is on, cross-references the policy param shape to check_license_compliance, and explains peerDependencies exclusion default and includeDevDependencies ignoring behavior — details the schema omits.

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 and resource: 'emits a spec-valid CycloneDX 1.6 or SPDX 2.3 JSON document' with an explicit format choice and default. No sibling tool generates SBOMs (siblings cover vulnerability queries, license checks, remediation), so it is cleanly distinguished from all alternatives.

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?

Gives clear contextual guidance: references the shared input shape with batch_query_vulnerabilities, explains when to skip enrichment passes (includeVulnerabilities/includeLicenses=false for speed), when to set includePeerDependencies (when an SBOM must be complete), and the content-vs-packages exclusivity. It lacks an explicit 'don't use when' exclusion, but for a generation tool the usage contexts are well covered.

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?