vulnerability-exposure-mcp

Overview Schema Source Related Servers Discussions Admin

Distro patch check

distro_patch_check

Read-onlyIdempotent

Checks Ubuntu or Debian package versions against distro security data via OSV.dev to detect known vulnerabilities, including backported fixes that leave upstream versions unchanged.

Instructions

Check an Ubuntu or Debian package version against the distro's own security data (via OSV.dev), which counts fixes the distro backports without changing the upstream version. Use it when Shodan lists distro_packages (e.g. OpenSSH_8.9p1 Ubuntu-3ubuntu0.6 gives package 'openssh', package_version '8.9p1-3ubuntu0.6'), or when the user gives an installed package version. Pass the version check's affected_cve_ids as cve_ids. release (e.g. '22.04', '12') is found automatically when possible. No key needed.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "package": "<package>",
      "package_version": "<package_version>",
      "distro": "<distro>"
    },
    "name": "distro_patch_check"
  }
}

Input Schema

Name	Required	Description
`distro`	Yes	The distribution.
`cve_ids`	No	CVE IDs to check, usually the version check's affected_cve_ids.
`package`	Yes	The source package name, e.g. 'openssh' or 'nginx'.
`release`	No	The distro release, e.g. '22.04' or '12'. Found automatically when possible if left out.
`package_version`	Yes	The installed package version with its distro revision, e.g. '8.9p1-3ubuntu0.6'.
`investigation_id`	No	The investigation_id from investigate_target. Pass it so the result counts toward that investigation's evidence, budget and key facts; without it the lookup runs on its own.

Schema Changelog

Changes observed during successful MCP inspections.

Changed6 schema fields changedv1.0.1Oct 29, 2026

addedInput schema / properties / cve_ids / description

Added value: +"CVE IDs to check, usually the version check's affected_cve_ids."

addedInput schema / properties / distro / description
```
Added value: +"The distribution."
```

addedInput schema / properties / investigation_id / description

Added value: +"The investigation_id from investigate_target. Pass it so the result counts toward that investigation's evidence, budget and key facts; without it the lookup runs on its own."

addedInput schema / properties / package / description

Added value: +"The source package name, e.g. 'openssh' or 'nginx'."

addedInput schema / properties / package_version / description

Added value: +"The installed package version with its distro revision, e.g. '8.9p1-3ubuntu0.6'."

addedInput schema / properties / release / description

Added value: +"The distro release, e.g. '22.04' or '12'. Found automatically when possible if left out."

First observedv0.1.0Oct 25, 2026

TDQS

A4.3/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly, idempotent, non-destructive and open-world, so the safety profile is covered. The description adds genuinely non-obvious behavior: distro backports are counted as fixes even when the upstream version is unchanged, release is auto-detected when possible, and it requires no API key.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The capability statement is front-loaded, and each following sentence adds usable information (examples, parameter provenance, no-key note). It is dense and slightly packed with parentheticals, but there is no filler to cut.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a six-parameter read-only tool with no output schema, the description covers inputs, chaining, and the key behavioral nuance. The remaining gap is return shape — it never says what a patch check yields (e.g. per-CVE patched/vulnerable status), which an agent must infer.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so a baseline of 3 applies, but the description adds real cross-tool meaning by mapping the Shodan field to parameters ('OpenSSH_8.9p1 Ubuntu-3ubuntu0.6' → package 'openssh', package_version '8.9p1-3ubuntu0.6') and defining cve_ids' provenance. Some sentences, such as automatic release detection, only restate the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource — check a distro package version against Ubuntu/Debian security data via OSV.dev — and names the distinguishing mechanism (counting backported fixes without upstream version bumps). That mechanism separates it from upstream-version tools like nvd_lookup or version_specific_vulnerability_check without opening either schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives concrete triggering conditions: when Shodan lists distro_packages, or when the user supplies an installed package version, plus chaining guidance to feed the version check's affected_cve_ids in as cve_ids. It does not state any when-not conditions or explicitly name the sibling to use instead for non-distro cases.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.