Loading ToolBench
MCP server for looking up CVE details from NIST NVD, checking CISA Known Exploited Vulnerabilities catalog, and searching GitHub for CVE-related repositories
Three read-only tools with varying quality. Tool names follow verb_noun convention and are specific. All tools have input schemas with proper types and descriptions. However, output schemas are largely undocumented, the code shows complex nested structures (e.g., references with priority, categories, tags) but the tool descriptions do not document what fields consumers should expect. Descriptions are present but generic (10-80 characters), lacking actionable guidance on when to use each tool vs. alternatives. Error handling returns basic error dicts without recovery guidance. Parameter descriptions are minimal. The server shows foundational quality but lacks the LLM-optimized descriptions and output documentation expected of production-grade tools.
Check if CVE is in CISA Known Exploited Vulnerabilities catalog and get metadata
Look up CVE from NIST NVD
Search GitHub for repos mentioning CVE
Output schemas not documented. lookup_cve_details returns complex nested structures (references with url, source, type, priority, categories, tags, nvd_tagged; cve_id, description, cvss_score, severity, published_date, last_modified, cwe list) but the tool description does not specify what fields the LLM should expect. This forces agents to guess at response shape and risks failed downstream extraction.
Tool descriptions are too brief and lack LLM-optimized guidance. 'Look up CVE from NIST NVD' (28 chars) does not explain WHEN to use this vs. check_cisa_kev_details or search_github_cve_repos, what the output contains, or how CVE format should be validated.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 62 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 41 | - | v1 |
Parameter descriptions are minimal or absent. The 'cve_id' parameter across all tools has a valid-format description ('CVE identifier in format CVE-YYYY-NNNNN') but no guidance on case sensitivity, what happens on invalid format, or examples of valid input. The 'search_type' enum in search_github_cve_repos has a description but lacks hints on when to use 'poc' vs. 'fix' vs. 'advisory'.
Error handling lacks recovery guidance. Code returns bare dicts like {'error': 'Invalid CVE format: ...'} or {'error': 'CVE not found'}. Call search_github_cve_repos(...) to verify if exploits exist for similar CVEs.' Raw error messages give the agent nothing to act on.
No input validation schema constraints beyond string type. The cve_id parameter accepts any string and validates it in code (regex check: '^CVE-\d{4}-\d{4,}$'). This regex should be exposed in the JSON Schema as a pattern field so LLMs can self-correct before calling the tool, reducing failed attempts.
Response filtering reduces utility. lookup_cve_details filters references for broken links, deduplicates by normalized URL, and infers KEV status from source tags. While this post-processing improves output quality, the tool does not document which references are excluded or why, making it opaque to the LLM. Consider returning a 'filtered_count' or 'exclusion_reason' field per reference so agents understand data provenance.