JavaScript supply-chain and frontend source inventory analysis tools for deterministic, offline, read-only evidence collection
Two tools with basic descriptions and visible input schemas, but significant gaps in parameter documentation and output schema clarity. Tool names lack action verbs (inspect-js-supply-chain, inventory-frontend-source are noun-heavy). Descriptions are present (94 and 104 chars respectively) but lack WHEN/WHY guidance. Parameters have types and enums but lack descriptions explaining their purpose and constraints. No output schema documentation visible. Error handling and recovery guidance absent. Both tools are read-only (low risk) but lack the structure expected of production tools.
Collects deterministic, offline, read-only JavaScript manifest and npm lockfile evidence. It does not contact registries, generate an SBOM, determine license compliance, or report vulnerabilities.
Collects deterministic, read-only frontend source evidence. It does not choose architecture or write output files. Markdown is the default format.
Tool names lack action verbs. 'inspect-js-supply-chain' and 'inventory-frontend-source' are noun-heavy descriptors, not verb_noun patterns. LLMs struggle to infer intent from non-verb names.
Parameter descriptions missing. 'root', 'format', and 'maxFiles' have no descriptions explaining what they control, valid ranges, or constraints. LLMs cannot infer parameter semantics from names alone.
Output schema not documented. Tool descriptions state what they collect but do not specify the structure of returned data. LLMs cannot plan downstream operations without knowing response fields.
No error handling or recovery guidance. Tools provide no documentation of failure modes, error messages, or what the LLM should do if analysis fails (e.g., missing package.json, unreadable files).
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 39 | 2026-07-28+ | v2 |
Descriptions lack WHEN/WHY context. Both tools state WHAT they do but not when an LLM should call them instead of alternatives, or what prerequisites exist (e.g., 'Requires a valid Node.js project with package.json').