Searches CISA's Known Exploited Vulnerabilities catalog and cve.now by CVE ID or keyword to surface critical or actively exploited vulnerabilities. Read-only lookups.
Recherche dans CISA KEV et cve.now (vulns critiques / activement exploitées). Lecture seule.
| Name | Required | Description | Default |
|---|---|---|---|
| cve | No | CVE exacte, ex. CVE-2021-44228 | |
| keyword | No | mot-clé vendor/produit/techno ou CVE |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral burden; 'Lecture seule' is a useful disclosure that substitutes for readOnlyHint. It says nothing about how results from the two sources are combined, whether auth or rate limits apply, or what happens when called with zero arguments (both parameters are optional) — a meaningful gap for a federation of two external data sources.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, with the scope front-loaded and no wasted wording. It is terse to the point of under-specification rather than verbose, but the structure itself is clean.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter, no-output-schema lookup tool this covers the essentials of what it searches, but leaves unstated the merged return shape of two separate sources and the no-argument behavior. Adequate, with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with both parameters documented including an exact-CVE example, so the schema does the heavy lifting. The description adds no semantics about parameter interaction or precedence (e.g., cve vs keyword), so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names the specific resource (CISA KEV and cve.now) and the operation (recherche) plus the domain (vulns critiques / activement exploitées), which rescues the opaque tool name 'kev'. It doesn't explicitly contrast with siblings probe/ports/dirs/tmpl, but those are clearly a different domain (scanning vs. vulnerability lookup).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Lecture seule' implies this is a safe lookup rather than an active scan, and the parenthetical scope hints at the use case. However, there is no explicit statement of when to call this versus when not to, no note on whether both sources are always queried, and no guidance on choosing between the cve and keyword parameters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.