# VulnTracker

> CVEs, affected versions and fix versions for your dependencies, from an affected-version ledger.

- name: io.vulntracker/mcp
- version: 2.5.0
- connection class: R1 (autonomous)
- trust: 100/100
- quality: 84/100 (new)
- owner: not claimed
- descriptor: https://api.protogrid.dev/v1/servers/io.vulntracker%2Fmcp
- tools: https://api.protogrid.dev/v1/servers/io.vulntracker%2Fmcp/tools

**An agent can connect on its own if it already holds `api_key`.** Remote endpoint behind a static API key or header. The registry never sees the value; the agent fills the placeholder.

## Connection (mcpServers)

```json
{
  "mcpServers": {
    "vulntracker": {
      "type": "http",
      "url": "https://api.vulntracker.io/mcp",
      "headers": {
        "Authorization": "Bearer ${api_key}"
      }
    }
  }
}
```

Placeholders to fill: `${api_key}`.

## Trust

- hygiene: 100
- liveness: 100
- freshness: 100
- provenance: 100
- drivers: +repository +namespace-matches-repo +dns-namespace +website +reachable +uptime-100% +updated-4d-ago
- Derived from observable signals (official registry feed and our own credential-free probes); no code audit performed.

## Quality 84/100 (new)

### protocol: 88 (weight 25)

- pass `protocol.modern`: supports 2026-07-28 (server/discover)
- pass `protocol.stateless`: answers without a session
- pass `protocol.transport`: streamable HTTP
- warn `protocol.list_ttl`: tools/list declares ttlMs 0, so clients re-fetch it on every use

### authorization: n/a (weight 15)

- n/a `auth.prm`, `auth.as_metadata`, `auth.cimd`: no remote uses OAuth
- n/a `auth.secret_in_url`: no templated URL

### tool hygiene: 81 (weight 30)

- pass `tools.descriptions`: every tool has a description
- warn `tools.description_length`: 1 tools have descriptions over 1,024 characters, which crowds the context
- pass `tools.schemas`: every tool has an object input schema
- pass `tools.annotations`: 15 of 15 tools declare readOnlyHint or destructiveHint
- fail `tools.directory_hints`: no tool declares all four of readOnlyHint, destructiveHint, idempotentHint and openWorldHint; missing: list_trackings (destructiveHint, openWorldHint); lookup_cve (destructiveHint, openWorldHint); track (openWorldHint); …
- pass `tools.token_cost`: about 3,396 tokens to load every tool
- pass `tools.api_dump`: tools are not a one-to-one API dump
- pass `tools.hidden_text`: no hidden text in tool names, descriptions, schemas or annotations

### stability: n/a (weight 15)

- n/a `stability.changes`, `stability.rug_pull`, `stability.new_links`: tool history recorded for 3 of the 7 days needed

### dependencies: n/a (weight 15)

- n/a `deps.known_vulns`, `deps.mcp_sdk_version`, `deps.resolvable`: no npm or PyPI package

- tools: 15, about 3,396 tokens to load them all
- tool set hash: edd01746e8d2e5b7fdcf9aa0f04c1fab
- tools last changed: 2026-11-12T19:11:05.501Z
- badge: [![protogrid quality](https://protogrid.dev/badge/io.vulntracker/mcp.svg)](https://protogrid.dev/servers/io.vulntracker/mcp)
- Checks run on what our credential-free, read-only probes observe; tools are never called and no code audit is performed.

### Tool changes

- 2026-11-12 `check_version` changed (description)
  - before: 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 objects carry provenance: quote a fix version with who stated it (stated_by, source_url); fix_stated_by_source=false / source="derived.range" means VulnTracker inferred the version from a range bound (derived_from), not a statement in the CVE record.
  - after: 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 objects carry provenance: quote a fix version with who stated it (stated_by, source_url); fix_stated_by_source=false / source="derived.range" means VulnTracker inferred the version from a range bound (derived_from), not a statement in the CVE record. Fix objects may also carry stated_for (the stream or product the record named, e.g. a RHEL stream) and package (the package to update); when present, quote the package and stream, since on distributions the fix is a package version, not an OS version.
- 2026-11-12 `check_version` changed (description)
  - before: 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.
  - after: 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 objects carry provenance: quote a fix version with who stated it (stated_by, source_url); fix_stated_by_source=false / source="derived.range" means VulnTracker inferred the version from a range bound (derived_from), not a statement in the CVE record.
- 2026-11-10 `create_jira_issue` added
  - 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.
- 2026-11-10 `search_cves` changed (description, inputSchema) **meaning changed**
  - before: Search the CVE list with filters. Results are newest first. 'tracked_only' limits to CVEs matching the API key's team trackings.
  - after: 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.
- 2026-11-10 `list_board_cards` changed (inputSchema)

Full history: https://api.protogrid.dev/v1/servers/io.vulntracker%2Fmcp/changes

## Remotes

- https://api.vulntracker.io/mcp (streamable-http, auth api_key ${api_key}, reachable true, uptime30d 1)

## Packages

_none_

## Tools (15)

- `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.
- `check_dependencies`: 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.
- `check_version`: 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 objects carry provenance: quote a fix version with who stated it (stated_by, source_url); fix_stated_by_source=false / source="derived.range" means VulnTracker inferred the version from a range bound (derived_from), not a statement in the CVE record. Fix objects may also carry stated_for (the stream or product the record named, e.g. a RHEL stream) and package (the package to update); when present, quote the package and stream, since on distributions the fix is a package version, not an OS version.
- `create_jira_issue`: 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.
- `list_board_cards`: 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.
- `list_trackings`: The vendors, products, versions, CVEs, keywords and CPEs this account's team is watching in VulnTracker.
- `lookup_cve`: 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.
- `product_cves`: 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.
- `product_versions`: 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.
- `remediation_guide`: 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.
- `search_cves`: 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.
- `search_products`: 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).
- `track`: 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.
- `untrack`: 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.
- `update_board_card`: 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.