Hosted MCP server: which CVEs affect your dependency versions, and which version fixes each
Scored across 15 tools
Most tools target a clearly distinct resource+action: search_cves vs lookup_cve vs product_cves, and check_version vs check_dependencies (batch wrapper) are well separated by their descriptions. The one real overlap is add_to_board vs update_board_card, since both can create a missing card and both can change triage status, forcing the agent to guess which to call when adding a CVE with a status.
The dominant pattern is consistent snake_case verb_noun (add_to_board, check_version, list_trackings, search_products, create_jira_issue), which is highly predictable. Minor deviations exist: three noun-only names (product_cves, product_versions, remediation_guide) and the bare verb pair track/untrack, but they remain unambiguous and readable.
15 tools sit at the top of the well-scoped range but each maps to a real step in the vulnerability workflow: discovery (search_products, search_cves, lookup_cve), assessment (check_dependencies, check_version, product_versions, product_cves, remediation_guide), watchlist (track/untrack/list_trackings) and response (board tools, Jira). No obvious redundant or filler tools.
The surface covers the full lifecycle: find products/CVEs, check versions and dependency manifests, track/untrack, push findings to a board, update triage/resolution, and escalate to Jira, plus remediation guidance. Minor gaps: no explicit way to remove a card from the board (only 'dismissed' status), no vendor discovery/search despite track accepting a vendor, and no bulk way to sync many existing cards' statuses beyond re-calling add_to_board.
Add CVEs to the team's board (the API key's team) as cards, or update their status if a card already exists. Use after a scan when the user asks to put the findings on the board; write which dependency and version each CVE came from into notes. Up to 50 CVE ids per call, counted as one tool call. Ask the user before adding; never add unmatched or needs_confirmation findings without saying so.
Inputs: cve_ids (required), notes, status.
Check many product@version pairs in one call. Give the dependencies you read from the repository's manifests (go.mod, package.json / lock files, requirements.txt, pom.xml, Gemfile.lock, Cargo.lock, Dockerfile base images). For each one you get whether VulnTracker matched a product, whether the exact version is known, how many CVEs affect it, the newest affected CVEs with fix versions, and how confident the name match is. Max 50 items per call; batch larger lists.
Inputs: items (required).
The core question: which CVEs affect this exact version of a product, and which version fixes each? Returns (a) CVEs whose claims name this version, with evidence, confidence and fix versions, and (b) range_affected_cves: CVEs whose source gave a version range that contains this version (e.g. '3.0.0 to before 3.0.8'); affected_total adds both. all_versions_cves lists records whose source named no version at all, and shadowed_range_cves lists records where only an open-start '< X' entry covers this version while the same record also has an 'A..X' entry ending at the same X (one source gave a start, the other did not; the open-start entry may just be the same branch restated). An open-start entry whose end differs from every bounded entry is its own release line (node '<= 20.20.1' beside 22/24 lines) and counts as affected; neither is in affected_total, both need confirmation. fix_stated_by_source=false means the fix version was derived from a range bound, not stated by the vendor.
Inputs: product (required), version (required), role, limit.
Open a Jira issue for a CVE on the team's board (the card is created first if missing) using the team's Jira integration. Returns the issue key and URL; if the card already has an issue, returns that one with existing=true. Only when the user asks.
Inputs: cve_id (required), note.
The team's CVE board: the CVEs that reached this team (by tracking notification or added by hand), each with its triage status (new, acknowledged, in_progress, resolved, dismissed), resolution status, notes, severity and the vendor/product it was recorded against. Use it to answer 'what is open on our board', 'which cards mention product X', or to find the card for a CVE.
Inputs: kev, page, limit, query, +5 more.
The vendors, products, versions, CVEs, keywords and CPEs this account's team is watching in VulnTracker.
Inputs: no named parameters.
Full record for one CVE: description, CVSS, EPSS, KEV/exploitation and SSVC, affected products with version ranges and fixes from the ledger, vendor advisories (CSAF), public exploit repositories, and VulnTracker's remediation guide when one is published.
Inputs: cve_id (required).
All CVEs recorded against a product in the affected-version ledger, newest first, with the version ranges each one names. entry_kind 'affected' = the product itself is vulnerable; 'runs_on_platform' = another product is vulnerable when running on it.
Inputs: product (required), limit, offset, entry_kind.
List the versions VulnTracker knows for a product, with per-version CVE and fix counts. Use to find the exact version string before calling check_version.
Inputs: product (required), limit, search.
VulnTracker's published remediation guide for a CVE: summary, steps, workarounds, caveats, kind (fix / workaround / guidance) and the fix versions it rests on. Returns has_guide=false when none is published.
Inputs: cve_id (required).
Search the CVE list with filters. Results are newest first, up to 100 per call; when has_more is true pass next_cursor back as 'cursor' for the following page (at most 10 pages per filter set, so narrow the filters instead of walking the whole database). 'tracked_only' limits to CVEs matching the API key's team trackings.
Inputs: limit, query, cursor, vendor, +7 more.
Find VulnTracker products (software, firmware, libraries) by name. Returns slugs to use with check_version, product_versions and product_cves. Searches display names and known aliases (package names, CPE tokens).
Inputs: query (required), limit, vendor.
Start watching something in VulnTracker for the API key's team: a product (default; slug or id from search_products / check_dependencies matched_slug), a vendor, a single CVE, or a keyword. New CVEs matching the tracking reach the team's board and its notification channels. Plan tracking limits apply; the error says so when the limit is reached. Use when the user asks to 'track', 'watch' or 'follow' the dependencies of a repository; prefer tracking products over individual CVEs.
Inputs: target (required), type, notes, min_severity, +2 more.
Remove a tracking from the API key's team: give the same type and target used with track (or shown by list_trackings). Board cards stay.
Inputs: target (required), type.
Change one board card: triage status (new, acknowledged, in_progress, resolved, dismissed), resolution (patched, mitigated, workaround, accepted_risk, false_positive), notes and resolution notes. Creates the card if the CVE is not on the board yet. Use when the user says a CVE is fixed, accepted or a false positive.
Inputs: cve_id (required), notes, status, resolution_notes, +1 more.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
Loading tool schema changelog…
Add one secure layer between your agents and this server.