No user-submitted related servers found.
Scored across 16 tools
Most tools target distinct axes: single-CVE record (get_cve), CVE search (search_cves), per-CVE enrichment (cve_intel), remediation (cve_remediation), EPSS history, and exposure. However, check_affected/scan_manifest/check_sbom share the same underlying 'check component vs advisory corpus' purpose and differ mainly by input shape, and vendor_advisories_for_cve vs get_vendor_advisory vs search_vendor_advisories have fuzzy boundaries. An agent can usually pick correctly, but a few choices require careful reading.
There is a recognizable scheme: get_* for single records (get_cve, get_cwe, get_vendor_advisory), search_* for lists (search_cves, search_vendor_advisories), check_*/scan_* for assessment, and resource-prefixed analytics (cve_*, kev_*, epss_*). The noun-only names like cve_exposure, exposure_radar, kev_recent and epss_history deviate from a strict verb_noun pattern, but the set remains predictable and readable.
Sixteen tools is at the heavier end for a single server, but this is a broad vulnerability-intelligence platform spanning CVE lookup, KEV, EPSS, exposure, SBOM/manifest scanning, CWE and vendor advisories, and each tool covers a distinct capability. Nothing is clearly redundant enough to remove, so the count is justified though slightly on the high side.
The surface covers the read lifecycle well: search and fetch CVEs, summaries, KEV and EPSS feeds, per-CVE intel/remediation, exposure radar, CWE grouping, vendor advisory search/detail, and component assessment via single version, lockfile or SBOM. Minor gaps remain, such as a direct 'list all CVEs affecting a package/ecosystem' query, but the core workflows have no dead ends.