MCP server for the NIST National Vulnerability Database (NVD) with optional CISA KEV enrichment
The server defines 4 tools with basic functionality for NVD vulnerability queries. Tool naming follows verb_noun convention consistently (nvd_get_cve, nvd_search_cves, nvd_search_cpes, nvd_get_cve_history). All tools have descriptions present and input parameters are typed with descriptions. However, several significant quality gaps exist: (1) Output schemas are not documented in the source code, we can see async functions return 'dict' but no actual response structure is visible; (2) Parameter descriptions are present but minimal (1-10 words), lacking detail on formats, ranges, constraints, and when to use one tool vs another; (3) No error handling guidance visible, tools call service methods that may fail but no recovery instructions are documented; (4) Missing parameter constraints, date parameters accept 'ISO format' strings but no regex, min/max, or validation guidance; (5) No pagination documentation despite search tools accepting 'limit' parameters, and no indication of result structure (is it a list? paginated object?); (6) Services are called but their implementations are not visible in the provided code, preventing full schema verification. The tool definitions work but are barebones and would require LLM reasoning to infer correct usage patterns.
Get normalized details for a single CVE ID from the NVD.
Get NVD CVE change history by CVE ID or change window.
Search CPE entries in the Official CPE Dictionary.
Search NVD CVEs using common filters.
Output schemas not documented. All tools return 'dict' with no visible response structure specification. LLM cannot predict response fields, breaking downstream tool chaining and forcing runtime discovery.
Parameter descriptions are minimal (1-10 words) and lack actionable constraint details. Date parameters state 'ISO format' but omit regex, valid ranges, or examples. 'limit' parameters lack min/max bounds. Descriptions should be 10-1024 chars with explicit constraints per the rubric baseline (avg 72 chars per param).
No error handling or recovery guidance in tool descriptions. Services may fail (invalid CVE IDs, API errors, malformed dates) but no recovery hints provided. LLM receives no guidance on whether to retry, ask user, or fall back.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 48 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 29 | - | v1 |
Search tools accept 'limit' parameters but no pagination pattern documented. Unclear if results are truncated, if a cursor/offset exists, or if repeated calls require different parameters. Large result sets may exhaust context window.
Service implementations not visible in source code. Cannot verify actual schemas, error handling, or data transformations. Tool definitions reference service methods (cve_service.get_cve, cpe_service.search_cpes) but their implementations are opaque.
Date parameter handling is ambiguous. Parameters like 'pub_start_date', 'pub_end_date', 'change_start_date', 'change_end_date' state 'ISO format' but no clarification on timezone, whether boundaries are inclusive, or how they interact. LLM may guess wrong.
Tool descriptions lack WHEN/WHY guidance. 'Get normalized details for a single CVE ID' does not clarify when to use nvd_get_cve vs nvd_search_cves with cve_id filter. 'Search NVD CVEs' does not explain what filters are mutually exclusive or recommended patterns.
Optional parameter relationships undocumented. nvd_search_cves has 8 optional filters (keyword, cpe_name, cve_id, cvss_v3_severity, dates). No guidance on which are mutually exclusive, recommended combinations, or what happens if all are omitted.