Loading ToolBench
MCP server exposing Attestd CVE checks, supply-chain signals, product catalog, and CVE detail lookup for Claude Code and other MCP clients
Four well-named tools with complete input schemas and comprehensive output schemas. Tool names follow verb_noun pattern (check_*, list_*, get_*). Descriptions are detailed (100-300 chars) and explain WHEN to use each tool. All parameters have types and descriptions. Output schemas are fully documented with field-level descriptions. Tool annotations (readOnlyHint, idempotentHint, openWorldHint) are present. Main gaps: no error handling guidance in descriptions, no parameter constraints (enums, ranges), and no recovery hints for common failure modes.
Check up to 100 software packages or infrastructure products in a single request. Each item is billed as one API call. Use this instead of multiple check_package_vulnerability calls when you need to audit a lockfile, manifest, or dependency list. Items outside Attestd coverage return outsideCoverage=true and should be treated as unknown risk, not safe. A 429 is returned before any results are delivered if the batch would exceed your monthly quota; no calls are billed in that case.
Check whether a software package or infrastructure product version has known CVE vulnerabilities or a confirmed supply chain compromise. Call this before adding, updating, or recommending any npm, PyPI, or infrastructure dependency, including mid-conversation when a developer asks about installing or upgrading a package. outsideCoverage=true means Attestd has no data for that product; treat as unknown risk, not safe. Covers infrastructure products (nginx, PostgreSQL, Redis, Docker, Kubernetes, etc.) and PyPI/npm packages.
Return full details for a single CVE id (CVSS, EPSS, KEV status, affected products). Use when you need context on a specific CVE before recommending a patch or explaining risk to a developer.
Returns Attestd-covered products for CVE checks. With an API key, returns live data from GET /v1/products (CVE infrastructure slugs plus monitored supply chain packages). Without a key, returns the static bundled infrastructure list. PyPI and npm packages also work with check_package_vulnerability even when absent from this list.
No error handling guidance in tool descriptions. When API returns 429 (rate limit), auth error, or unsupported product, descriptions do not tell the LLM what to do next or how to recover.
Parameter 'product' in check_package_vulnerability accepts free-form strings with no enum or format constraint. Description says 'e.g. nginx, runc' but LLMs may hallucinate invalid product slugs. Should validate against COVERED_PRODUCTS or return clear error with suggestions.
Output schema for check_package_vulnerability includes many optional/nullable fields (riskState, maxEpss, fixedVersion, error) but descriptions do not clarify when each is present or absent. LLMs cannot reliably extract the right field without explicit presence rules.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 69 | 2025-06-18+ | v2 |
check_batch_vulnerabilities accepts up to 100 items but no per-item error reporting. If 1 item fails validation, the entire batch response is unclear. Should return per-item success/failure with error details.
list_covered_products returns different schemas depending on whether API key is present (static vs live). LLM must handle two completely different response structures. Should normalize output or document the conditional behavior more explicitly in the description.