vulnerability-exposure-mcp

Overview Schema Source Related Servers Discussions Admin

Check report

check_report

Read-onlyIdempotent

Validate draft investigation reports before finalizing: compare claims against tool results and key facts, and list unsupported CVEs, versions, statuses, and exploit assertions to fix or remove.

Instructions

Run before giving the final report. Compares your draft with this investigation's tool results and key facts, with no model involved, and lists what they don't support: CVE or advisory IDs no lookup returned, version numbers and EPSS-style percentages that appear nowhere in the data, claims such as "end-of-life", "no patch available" or "internet-facing" that no source makes, unconfirmed CVEs filed as confirmed (and the reverse), misquoted fix versions, upgrade versions named when no version was given, and exploit claims the data doesn't back. Fix or remove each one.

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": {
      "investigation_id": "<investigation_id>",
      "report_markdown": "<report_markdown>"
    },
    "name": "check_report"
  }
}

Input Schema

Name	Required	Description	Default
`report_markdown`	Yes	Your full draft report, in Markdown.
`investigation_id`	Yes	The investigation_id from investigate_target.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv1.0.1Oct 29, 2026
- addedInput schema / properties / investigation_id / description
```
Added value: +"The investigation_id from investigate_target."
```
- addedInput schema / properties / report_markdown / description
```
Added value: +"Your full draft report, in Markdown."
```
First observedv0.1.0Oct 25, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world, so the safety profile is covered. The description adds real value beyond that: it discloses the check is deterministic ('no model involved') and enumerates the exact classes of problems surfaced (unreturned CVE IDs, invented version numbers, unsupported claims, confirmed/unconfirmed mismatches). It doesn't say precisely how results are formatted or ordered, keeping it at 4.

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 imperative trigger is front-loaded in the first sentence, followed by the mechanism and the findings taxonomy. The long enumeration of check categories is dense but each item is a distinct, actionable detection class; a bulleted layout would read better but nothing is genuinely wasted.

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?

With no output schema, the description carries the burden of explaining returns, and it does so by describing the output as a list of unsupported claims grouped by type. For a two-parameter, read-only validator this is nearly complete; only the exact return shape and whether it blocks further work remain unspecified.

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

Parameters3/5

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

Schema coverage is 100% and both parameters are self-explanatory, so the baseline is 3. The description implicitly frames what goes in ('your draft' and 'this investigation's tool results') but adds no format or size guidance beyond what the schema already states.

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: it compares a draft report against the investigation's tool results and key facts and lists unsupported claims. The description is explicit that it is a deterministic validator ('no model involved'), which separates it cleanly from sibling lookups like nvd_lookup or get_key_facts that supply the underlying data.

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?

'Run before giving the final report' gives a clear trigger point, and 'Fix or remove each one' tells the agent what to do with the output. It lacks an explicit exclusion (e.g. don't run mid-investigation before key facts are gathered) or a named alternative, so it falls short of a 5.

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