Actively exploited? End of life? Which version fixes it? CVE verdicts for server software.
Scored across 3 tools
Each tool has a clearly stated scope: list_products is catalog discovery, check_version is a single-product lookup, and check_stack is batch processing of up to 50 versions. check_version and check_stack overlap in purpose (stack is essentially batched version checks), but the descriptions explicitly differentiate single vs. bulk usage so an agent is unlikely to misselect.
All three tools follow the same verb_noun snake_case convention (check_stack, check_version, list_products) with unambiguous verbs. No mixed casing or inconsistent verb styles.
Three tools is on the lean side but each maps to a real workflow need: discovery, single lookup, and bulk lookup. check_stack could arguably be folded into check_version as a list-accepting parameter, so there is slight redundancy rather than a shortfall.
The core query lifecycle is covered: discover products, check one version, check many, and get the fixing version back. Minor gaps remain, such as no way to look up a vulnerability by CVE ID or fetch detailed advisory/reference data beyond the summary result.
Check up to 50 product versions, e.g. everything in a Dockerfile, docker-compose.yml or server inventory.
| Name | Required | Description | Default |
|---|---|---|---|
| items | Yes |
| Name | Required | Description |
|---|---|---|
| results | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and openWorldHint=false, so safety and repeatability are covered. The description adds the batch limit and examples of suitable sources, but does not discuss partial failures, output shape, or rate limits. With annotations present, this is adequate but not rich.
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?
It is a single, front-loaded sentence with no wasted words. The batch limit and example inputs are both included efficiently.
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?
An output schema exists, so the description need not explain return values. Annotations cover the safety profile, and the description covers the batch use case. Minor gaps around partial failures or duplicate handling remain but are not essential for invoking the tool.
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?
The description conveys that the tool accepts product versions in bulk and caps at 50, which aligns with the single items parameter. The schema itself defines the nested product/version fields, though context reports 0% top-level schema description coverage. The description does not explain the item structure beyond the high-level batch concept.
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 states a specific verb and resource: check up to 50 product versions at once. The Dockerfile/docker-compose/server-inventory examples make the batch purpose concrete. It implies differentiation from check_version via 'up to 50' but does not explicitly name the sibling alternative.
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?
The examples indicate intended usage for batch inventories, files, and configs. However, it does not explicitly say when to use check_stack instead of check_version or when not to use it. Usage is clearly implied but not fully guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check one product version for known vulnerabilities, active exploitation and end of life, and get the version that fixes it.
| Name | Required | Description | Default |
|---|---|---|---|
| product | Yes | Product name, e.g. "nginx", "PHP", "Node.js", "GitLab", "n8n" | |
| version | Yes | Exact version, or command output such as "nginx version: nginx/1.24.0" |
| Name | Required | Description |
|---|---|---|
| eol | Yes | |
| notes | Yes | |
| counts | Yes | |
| product | Yes | |
| upgrade | Yes | |
| verdict | Yes | |
| version | Yes | |
| checkedAt | Yes | |
| productName | Yes | |
| dataGeneratedAt | Yes | |
| vulnerabilities | Yes | |
| activelyExploited | Yes | |
| moreVulnerabilities | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, closed-world), so the bar is lower, and the description adds real substance: it enumerates what the check covers (vulnerabilities, active exploitation, EOL) and that a fixing version is returned. It doesn't mention rate limits or coverage gaps in the vulnerability database, which would have pushed it higher.
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?
One sentence, front-loaded with the action, and every clause carries information — the vulnerability/exploitation/EOL scope and the remediation answer. No filler.
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?
An output schema exists, so the return shape needn't be explained, and the description adequately frames the input and scope for a two-parameter read tool. The only shortfall is the absence of explicit sibling routing to check_stack or list_products.
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% and both parameters are documented with examples in the schema itself. The description only reinforces that a single product/version pair is expected, adding nothing about accepted version formats beyond what the schema already shows.
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?
States a specific verb and resource — check one product version for vulnerabilities, active exploitation, end of life — plus the remediation outcome. The word 'one' implicitly separates it from a stack-wide check, but the sibling check_stack is never named, so differentiation relies on inference.
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?
Usage is implied by 'one product version', suggesting this is the single-version counterpart to check_stack, and list_products is clearly a discovery tool. However, the description never states when to prefer this over check_stack, nor any prerequisite such as needing a resolved version string.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the products FixedIn covers, with their newest known release.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| products | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint, idempotentHint, and openWorldHint=false, so the safety and determinism profile is covered. The description adds that results include the newest known release, which is useful context about the returned data, but does not disclose more behavior beyond that or beyond what the output schema may provide.
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?
The description is a single, front-loaded sentence with no wasted words. It efficiently conveys both the resource and the key content of the result.
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?
Given zero parameters, existing annotations covering safety, and an output schema, the description is nearly complete for an agent to call the tool correctly. Its main gap is the absence of sibling-routing guidance against check_stack and check_version.
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?
The tool has zero parameters, so there is no parameter semantics to document; a baseline of 4 is appropriate. The description does not need to compensate for missing parameter details.
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 states a specific verb and resource: it lists the products FixedIn covers and includes their newest known release. It is clear what the tool does, but it does not differentiate itself from siblings check_stack or check_version.
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?
Usage is implied: an agent would use this to discover supported products. However, the description does not explicitly say when to use this versus check_stack or check_version, nor does it state any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
check_stackcheck_versionlist_productsIs a CVE exploited? CISA KEV, FIRST EPSS, CVSS and SSVC with a patch-first verdict. Free, no key.
CVE & vulnerability search: 365k+ CVEs/NotCVEs, CVSS, EPSS, CISA KEV, exploits, patches, versions.
CVE intelligence: exploitation (KEV/EPSS), detection coverage, fixed versions, CPE configurations.
CVE search, vulnerability database, EPSS exploit prediction, KEV, IP reputation & threat feed.
Add one secure layer between your agents and this server.
