Loading ToolBench
NIST Vulnerability MCP Server - Search and retrieve CVE vulnerabilities from the NVD (National Vulnerability Database) using the NIST API
Three tools present with incomplete definitions. Tool naming is clear and action-oriented (get_*, search_*), which is a strength. However, descriptions vary significantly in quality and completeness. Parameter schemas are present but lack type definitions for some fields (e.g., recent_days, last_days lack explicit 'type' in the visible schema). Most critically, output schemas are entirely undocumented, the tools return strings rather than structured objects, making it difficult for LLMs to chain results. Error handling is minimal: the code checks for malformed dates but provides no actionable recovery guidance. The get_temporal_context tool is well-described, but search_cves and get_cve_by_id lack sufficient detail on what fields are returned and when to use one vs. the other.
Retrieve a CVE by its CVE-ID
Get current date and temporal context when it needed. **USAGE**: Call this tool FIRST when user asks for time-relative question like "this year", "last year", "6 months ago", etc. Returns current date context and examples for constructing specific date parameters.
Search CVEs by keyword in description, with flexible time filtering. **IMPORTANT**: For time-relative queries (this year, last year, etc.), call get_temporal_context() FIRST to get current date information. **Date filtering logic (in priority order):** - If start_date and end_date are provided → use them directly - Else if last_days is provided → calculate start_date = now - last_days - Else fallback to last 30 days **Technical notes:** - If the time period > 120 days, queries are split into 120-day chunks - start_date, end_date: Use ISO 8601 format: "YYYY-MM-DDTHH:MM:SS" - recent_days parameter is deprecated, use last_days instead.
Output schemas undocumented. All three tools return plain strings instead of structured objects. LLMs cannot parse results reliably or chain tool calls because they don't know what fields to expect in the response.
get_cve_by_id description is only 35 characters ('Retrieve a CVE by its CVE-ID'). It does not explain when to use this tool vs. search_cves, what fields are returned, or any prerequisites.
Parameter schema for search_cves is incomplete. The 'recent_days' and 'last_days' parameters are typed as 'integer' in the visible schema, but the description says 'recent_days is deprecated', yet the tool code still handles it. No enum constraints on mutually exclusive date-filtering logic. Parameter descriptions do not explain the priority order or conflict resolution (which field wins if multiple are provided).
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 55 | <=2025-11-25 | v2 |
Error handling lacks recovery guidance. When dates fail to parse, the tool returns a plain error string ('Error: end_date must be valid ISO-8601 format') with no suggestion for what to do next or example of a valid format. Per pattern:recovery-guide, errors must tell the LLM what to try next.
No pagination in search_cves output. The tool accepts resultsPerPage and startIndex parameters but there is no indication in the description of what the total result count is, whether more results are available, or how to retrieve the next page. This violates pattern:paginated-result and risks context window overflow.
Deprecated parameter not properly retired. 'recent_days' is marked deprecated in the description, but the tool still accepts and processes it. The code prefers 'last_days' if provided, but silently falls back to 'recent_days' with no warning. This creates ambiguity and technical debt.