CVE MCP Server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.2.0
Disambiguation3/5
Several tools have overlapping purposes, such as check_exploit_availability and check_poc_exists both searching for exploits, and multiple package scanning tools (check_package_vulns, scan_dependencies, scan_container_packages) that differ only in input format. Additionally, passive_dns_lookup and get_domain_intel both query passive DNS, while get_cve_summary and lookup_cve share CVE details. These overlaps could cause an agent to select the wrong tool.
Naming Consistency4/5
Most tools follow a verb_noun pattern (e.g., check_ip_reputation, lookup_cve, scan_dependencies), but there are minor deviations like 'health_check' (noun_noun) and 'shodan_host_lookup' (noun_noun_verb). The use of multiple verbs (check, get, lookup, scan) is consistent in style, but the structure isn't perfectly uniform.
Tool Count4/5
With 27 tools, the server covers a wide range of vulnerability intelligence and threat hunting tasks. This is slightly on the high side but still reasonable given the breadth of functionality. Each tool has a distinct role, though some consolidation could reduce the count without loss of capability.
Completeness5/5
The tool surface is remarkably comprehensive for CVE and threat intelligence, covering CVE details, risk scoring, exploit checks, IOC lookups (IP, domain, URL, hash, Bitcoin address), package scanning, container scanning, secrets scanning, DNS, Shodan, and more. There are no obvious gaps for typical vulnerability assessment workflows.
Average 3.7/5 across 27 of 27 tools scored. Lowest: 2.6/5.
See the Tool Scores section below for per-tool breakdowns.
- 4 of 7 community issues answered or closed in the last 6 months
- 4 commits in the last 12 weeks
- Last stable release on June 22, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under Apache 2.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits but only states the output format. It does not mention what happens if the CVE ID is invalid, the effect of the include_remediation flag, or any side effects like generating a file.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, making it concise but lacking structure. It front-loads the key action and formats, but every sentence should add value; here it omits necessary details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description does not need to explain return values. However, with 3 parameters and no parameter descriptions, and multiple similar sibling tools, the description is insufficient for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 3 parameters with 0% description coverage. The description only hints at the 'format' parameter by listing possible values but does not explain the 'cve_id' or 'include_remediation' parameters, or the meaning of the format values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'generate', the resource 'vulnerability report', and the available formats ('executive, technical, or full format'). This distinguishes it from sibling tools that focus on checking or analyzing specific aspects rather than producing a report.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool instead of alternatives like get_cve_summary or compare_cves. There are no usage contexts, prerequisites, or exclusions mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must disclose behavioral traits. It mentions the data sources (crt.sh, CIRCL PDNS) but does not explain rate limits, authentication needs, or whether the data is historical/current. The behavior beyond 'returns subdomains and certificate history' is not transparent.
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 description is short with two distinct sections: purpose and arguments. It is front-loaded with the key action and uses no fluff. Every sentence serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has one parameter and an output schema, the description covers the essential function. However, it lacks behavioral transparency and usage guidance, leaving gaps for an agent to fully understand implications. It is adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has one parameter 'domain' with a title. The description adds an example (example.com) but no additional constraints or format details. Since schema coverage is 0%, the description adds minimal value beyond the schema's title.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states what the tool does: get domain intelligence from crt.sh and CIRCL PDNS, returning subdomains and certificate history. The verb 'get' and resource 'domain intelligence' are specific. However, it does not explicitly distinguish from sibling tools like 'passive_dns_lookup'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. The description does not mention prerequisites, limitations, or when to avoid using it. The context is implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral transparency. It only states the action and return type but does not disclose whether the operation is read-only, destructive, or has any side effects, rate limits, or authentication requirements.
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 description is concise with three distinct sentences: purpose, output summary, and parameter details. It is well-structured and front-loaded, efficiently conveying essential information without unnecessary fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description does not need to detail return values. However, the tool's complexity (multiple data sources, multiple return fields) could benefit from more context on specific outputs or limitations. The description is minimally adequate but not comprehensive.
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?
The description includes an 'Args' section that explains the format of the hash_str parameter (MD5, SHA1, SHA256 with hex length requirements), adding significant meaning beyond the schema's minimal string type definition. This compensates for the low schema description coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('Look up a file hash'), specifies the data sources (MalwareBazaar and VirusTotal), and outlines the return information (malware family, detection stats, file metadata). It effectively communicates the tool's purpose, though it does not explicitly differentiate from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide any guidance on when to use this tool versus alternatives, nor does it mention prerequisites or exclusions. It simply describes what the tool does without contextualizing its use among many similar tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It mentions the sources searched (GitHub, Exploit-DB, Nuclei) but does not discuss whether the tool is read-only, potential rate limits, or the nature of results (existence vs. details). Basic transparency is provided, but more detail would be beneficial.
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 description is a single concise sentence with no wasted words. However, given the parameter count and need for semantics, it is slightly under-specified. Remains efficient but could be expanded without harming conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although an output schema exists (reducing the need to explain returns), the description lacks parameter explanations and usage context. With 3 parameters and 0% schema coverage, the description is incomplete for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. However, it does not explain any of the three parameters (cve_id, include_github, include_exploitdb). It fails to add meaning beyond the schema, leaving the agent without guidance on how to use the parameters.
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?
The description clearly states 'Search for proof-of-concept exploits across GitHub, Exploit-DB, and Nuclei templates.' It specifically identifies the action (search), the resource (PoC exploits), and the scope (multiple sources), distinguishing it from siblings like check_exploit_availability and check_kev.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for finding PoCs but offers no explicit guidance on when to use this tool versus alternatives (e.g., check_exploit_availability, check_kev), nor does it mention when not to use it. Usage context is implied but not clearly defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description lacks details on limitations, error handling, rate limits, or output format. Only notes comma-separated format for input, insufficient for full transparency.
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?
Two lines with docstring format, no unnecessary words. Front-loaded with purpose. Efficient but could be more structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with output schema, description is adequate but lacks error behavior, limit details, or typical use cases. Gaps for a tool with no annotations.
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 has 0% coverage; description adds that cve_ids is comma-separated, which adds beyond the schema (just string). But no further syntax or constraints given.
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?
Description clearly states it retrieves EPSS scores for CVEs, with specific action and resource. Distinguishes from sibling tools like lookup_cve or check_exploit_availability.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like lookup_cve or check_exploit_availability. Description only states what it does, not context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It only states the action without disclosing side effects, data freshness, API limits, or result format. Minimal behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words. First sentence states purpose, second describes the parameter. Front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema, so return values are covered, but the description doesn't explain typical behavior (e.g., boolean result). For a simple lookup, it's adequate but leaves uncertainty about what 'check' means (boolean vs details).
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 has 0% description coverage. The description adds a format example ('CVE-2021-44228'), which adds some meaning beyond the schema. However, it's minimal and doesn't fully compensate for missing schema descriptions.
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?
The description clearly states the tool checks if a CVE is in the CISA Known Exploited Vulnerabilities catalog. The verb 'Check' and resource 'KEV catalog' are specific, distinguishing it from siblings like lookup_cve or check_exploit_availability.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives. It doesn't mention prerequisites, when to prefer this over lookup_cve or check_exploit_availability, or any context for its use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions the data sources but does not disclose how the composite score is computed, whether it is read-only, or any side effects. For a calculation tool, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that conveys the core purpose without any extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, the description need not detail return values, but it still lacks information on prerequisites, error conditions, or the calculation methodology, which is crucial for agent understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only implies the cve_id parameter by referencing CVE-specific data sources, but does not specify the expected format or additional constraints, leaving ambiguity.
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?
The description clearly states the tool calculates a composite 0-100 risk score using specific data sources (CVSS, EPSS, KEV, PoC). It distinguishes from sibling tools like 'get_epss_score' or 'check_kev' which provide individual scores.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for combining multiple risk metrics into a single score, but does not explicitly state when to use this over individual metric tools or any prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full burden. It mentions using OSV.dev but does not disclose behavior beyond the basic check (e.g., rate limits, response format, or any side effects). The lack of details on what constitutes a 'vulnerability' or how results are returned limits transparency.
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 description is short and structured with a one-line summary followed by parameter documentation. It avoids fluff but could be slightly more concise by omitting the 'Args:' prefix since the schema already defines parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists but is not referenced in the description. The description lacks any hint about the output (e.g., list of CVEs, severity scores), which would help the agent understand what to expect. It is minimally adequate but not complete for a tool that returns structured data.
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 description coverage is 0%, so the description compensates well by listing parameters with examples (e.g., package: 'log4j-core', ecosystem: 'PyPI', version: '2.14.1'). It adds enumerations for ecosystem and clarifies optionality, though it could further explain version format or response linkage.
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?
The description clearly states the tool checks a package for known vulnerabilities via OSV.dev. It specifies the action ('check') and resource ('package for vulnerabilities'), and the tool name and examples distinguish it from sibling tools like 'lookup_cve' or 'scan_dependencies'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of use cases, prerequisites, or when not to use it, leaving the agent without decision-making context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It only states what the tool does but does not disclose behavioral traits like read-only nature, required permissions, or side effects. This leaves agents uncertain about risks.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence of 10 words, front-loaded with action and resource. No wasted words. Ideal conciseness for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has one parameter and an output schema (presumably explains return format), so description need not cover returns. However, missing behavioral context (e.g., whether it's a read operation) and usage guidance reduces completeness. Adequate for a simple tool but with gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 0% description coverage, and the description only mentions 'multiple CVEs' without specifying format, constraints, or required count. The agent must infer the parameter semantics from the name alone, which is insufficient compensation.
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?
The description uses specific verb 'compare' and resource 'CVEs' with a clear outcome 'generate a patch priority ranking', distinguishing it from siblings like lookup_cve (individual lookup) or search_cves (search).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when multiple CVEs need prioritization but provides no explicit guidance on when to use vs alternatives or exclusions. With many sibling tools, lacking differentiation is a missed opportunity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description only mentions search and sorting by star count. Lacks details on rate limits, authentication, or what 'public' means. Insufficient for a tool with no annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three succinct sentences plus Args section. No redundancy, clear and front-loaded purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with output schema, description is adequate but omits sorting details or limitations. Could be more complete given sibling density.
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?
Single parameter cve_id has zero schema description coverage. Description adds format example 'CVE-2021-44228', providing clarity beyond the schema's type definition.
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?
Description clearly states verb 'Search GitHub' and resource 'public proof-of-concept exploit repositories for a CVE'. This differentiates it from sibling tools like check_poc_exists or lookup_cve.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as check_poc_exists. With many similar sibling tools, explicit when/when-not is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description provides moderate behavioral detail: it fetches NVD and EPSS concurrently and returns a summary including severity, EPSS, KEV status, etc. However, it does not disclose potential errors, rate limits, or whether it is read-only.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences plus a parameter listing. The main purpose is stated first, and every sentence adds value without redundancy.
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?
Given the existence of an output schema, the description does not need to detail return values. It covers the essential input, the sources fetched, and the summary items. Some behavioral context (e.g., caching, error handling) is missing, but overall it is adequate.
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?
The schema provides only a title and type for cve_id, but the description adds a clear explanation and a concrete example (CVE-2021-44228). This significantly aids understanding and correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it provides a comprehensive summary of a CVE, listing specific fields included. It distinguishes from some siblings by emphasizing concurrency and breadth, but doesn't explicitly differentiate from closely related tools like lookup_cve or get_cve_timeline.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus the many sibling tools. The description does not mention prerequisites, context, or alternatives, leaving the agent to infer usage without direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as whether the operation is read-only, authentication requirements, error handling, or what happens if the CVE does not exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences plus an arguments list, front-loaded with the purpose, and contains no extraneous information.
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?
The tool has one parameter and an output schema (as per context), and the description lists the key data points returned, which is sufficient for an agent to understand what it will receive. However, it does not describe the output structure or error scenarios.
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?
The input schema has one parameter with no description (0% coverage), and the description adds an example format (CVE-2021-44228) but does not explain accepted formats, case sensitivity, or validation rules.
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?
The description clearly states that the tool builds a 'complete CVE lifecycle timeline' and lists specific data points (NVD publication date, EPSS score history, etc.), which distinguishes it from sibling tools like get_cve_summary or get_epss_score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says when to use it (to get a lifecycle timeline for a specific CVE) but does not explicitly state when NOT to use it or provide alternatives like get_cve_summary for a simple summary, despite many overlapping siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions the database (Ransomwhere) and accepted address formats, but does not disclose behavioral traits like read-only nature, error handling, or response format. The output schema exists but is not referenced.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences and a bullet point. Every sentence adds meaning with no fluff or repetition.
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?
Given the tool's simplicity (one parameter, no enums) and the presence of an output schema, the description adequately covers the tool's purpose and input format. It could optionally mention the output, but it's not necessary per the rubric.
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 description coverage is 0%, so the description adds value by specifying the parameter as a Bitcoin wallet address and listing valid types (P2PKH, P2SH, bech32), which goes beyond the schema's plain type string.
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?
The description clearly states the verb 'check' and the resource 'Bitcoin address' against 'ransomware family' using a specific database. It distinguishes itself from siblings like check_ip_reputation and check_url_safety by focusing on Bitcoin addresses and ransomware.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for checking ransomware associations of Bitcoin addresses but lacks explicit guidance on when to use vs alternatives, such as other threat intelligence tools. No alternatives or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. It only describes the query action and output, but does not mention authentication requirements, rate limits, data freshness, or whether the operation is read-only. This is insufficient for a tool making external API calls.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences plus a one-line argument description. Every sentence adds value. No redundant information. Front-loaded with the core purpose.
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?
Given the tool has a simple single parameter and an output schema exists (as indicated by context signals), the description provides sufficient context about input and output (historical resolutions). It does not mention pagination or limits, but for a lookup tool this is acceptable. The sibling context is not necessary for completeness here.
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?
The description adds meaningful semantic details to the sole parameter, clarifying that it accepts IPv4, IPv6, or domain names. Schema description coverage is 0%, so this justification is crucial. It could be enhanced by specifying expected format (e.g., no protocol prefixes) but is adequate.
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?
The description clearly states it queries CIRCL Passive DNS for historical DNS resolutions, and specifies the two possible directions (hostnames to IP or IP to hostnames). This distinguishes it from sibling tools like check_ip_reputation or shodan_host_lookup which serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when historical DNS resolution data is needed, but does not explicitly state when to use this tool over alternatives like 'check_ip_reputation' or 'get_domain_intel'. No when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses lazy download and 24h caching, and that it searches descriptions and references. With no annotations, description carries full burden but is adequate. Lacks info on behavior when CVE not found or if it's read-only (inferred).
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?
Three sentences plus Args block; purpose is front-loaded. Clear and efficient, though Args could be integrated into prose.
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?
Covers key aspects: purpose, caching, search mechanism. Output schema exists, so return values need not be detailed. Missing info on error handling or empty results, but overall sufficient for a focused mapping tool.
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 0%, but description compensates with an Args section that explains cve_id and provides an example CVE format. This adds meaningful context beyond the raw 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?
Description clearly states the specific action: mapping a CVE to MITRE ATT&CK techniques and threat groups. It distinguishes from sibling tools like get_cve_summary or check_exploit_availability by focusing on attack mapping.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implied usage: use when needing ATT&CK mapping for a CVE. No explicit when-not-to-use or alternatives mentioned. Caching detail is provided but not decision guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states what it fetches and shows, but fails to disclose behavioral traits like rate limits, authentication needs, or error handling (e.g., if CVE is not found).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the purpose, and each sentence adds value without wasted words. It is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (so return values don't need explanation) and one parameter, the description is fairly complete. However, it lacks differentiation from similar sibling 'lookup_cve' and doesn't mention any edge cases or error conditions.
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?
The input schema has 0% parameter description coverage, but the description adds value by specifying the parameter 'cve_id' with a format example (CVE-2021-44228). This compensates for the schema lack and helps the agent understand the required input.
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?
The description clearly states it fetches vendor security advisories for a CVE from three specific vendors (Microsoft, Red Hat, Ubuntu) and shows patch availability and affected products. This is a specific verb+resource and distinguishes it from siblings like check_exploit_availability or check_poc_exists.
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?
The description implies usage when you need official vendor advisories/patch info for a CVE. It doesn't explicitly state when not to use or provide alternatives, but the context is clear among the many sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It indicates that the tool queries an external source (ThreatFox) and returns certain fields, but it does not disclose whether it is read-only, any authentication needs, rate limits, or error behavior. The description is adequate but not fully transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two short paragraphs: a one-sentence overview followed by a clear Args section. Every sentence adds value without redundancy.
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?
Given the tool's simplicity (one parameter, straightforward purpose) and the presence of an output schema, the description covers the essential aspects. However, it could mention the output schema existence or error handling to be fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'ioc' is thoroughly explained in the description: 'Indicator of Compromise — IP address, domain, URL, MD5/SHA256 hash'. This adds significant meaning beyond the input schema, which only specifies a string type with no description.
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?
The description clearly states the verb 'look up' and the resource 'IOC against ThreatFox for malware family attribution'. It specifies the types of IOCs (IP, domain, URL, or hash) and mentions the output fields, making it distinct from sibling tools like check_ip_reputation or lookup_file_hash.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit guidance on when to use this tool versus alternatives, nor does it mention exclusions or prerequisites. It implicitly suggests use for malware family attribution but lacks comparative context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It implies a read-only search operation but does not explicitly state non-destructive nature, rate limits, or other behaviors. Adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: three lines for purpose plus three bullet-like argument descriptions. Front-loaded with purpose, no wasted text.
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?
Given the existence of an output schema, return values need not be explained. Parameter documentation is thorough, but minor missing context like pagination or data freshness does not detract significantly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds rich semantics beyond the schema: allowed characters for query, exact severity options, numeric range for limit. With 0% schema description coverage, this fully compensates.
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?
The description clearly states the action ('Search'), resource ('NVD'), and object ('CVEs'), and distinguishes it from sibling tools like 'lookup_cve' by specifying keyword and optional severity filter.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'lookup_cve' or 'get_cve_summary'. While parameter constraints are provided, the description lacks explicit context for tool selection among many CV-related siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It lists returned fields but does not disclose potential rate limits, authentication needs, or side effects. For a read-only check, it is adequate but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two paragraphs, front-loaded with purpose and return values, followed by a focused Args section. No redundant words.
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?
Given the output schema exists (handling return details), the description provides adequate context: purpose, sources, parameter format, and return fields. Lacks mention of read-only nature but is still complete for the tool's simplicity.
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?
With 0% schema description coverage, the description compensates by explaining the 'ip' parameter format (IPv4/IPv6) and providing examples, adding value beyond the bare 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?
The description clearly states the verb 'check' and the resource 'IP address reputation', and specifies the data sources (AbuseIPDB, GreyNoise Community), distinguishing it from sibling tools like shodan_host_lookup or check_url_safety.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit when-to-use or when-not-to-use guidance relative to siblings. It implies general IP reputation checking but lacks boundaries or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It mentions using URLScan.io and returns scan verdicts, malicious flag, score, and categories. However, it does not disclose if it is read-only, rate limits, or authentication needs. The information is adequate but incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with one short paragraph and a single-line parameter explanation. Every sentence adds value, no redundancy, and the purpose is front-loaded.
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?
Given the tool has an output schema, the description's mention of return values (verdicts, malicious flag, score, categories) is sufficient. It lacks error handling or timeout info but covers the core functionality well for a simple tool.
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 description coverage is 0%, but the description compensates by explaining the single parameter: 'URL (https://example.com/path) or bare domain (example.com)'. This adds meaningful format guidance beyond the schema's type-only definition.
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?
The description clearly states 'Check a URL or domain for malicious activity via URLScan.io', specifying the verb (Check), resource (URL or domain), and purpose (malicious activity). This distinguishes it from sibling tools like check_ip_reputation or check_exploit_availability.
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?
The description implies usage for URL/domain safety checks. While not explicitly stating when not to use or naming alternatives, the tool's purpose is clear enough given the sibling list covers different security checks. A score of 4 reflects implied but clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explains that the tool uses OSV.dev and specifies input format, but with no annotations provided, it lacks details on rate limits, error handling, or behavior under failure conditions. It provides moderate transparency but not full behavioral context.
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 description is front-loaded with the core purpose and then provides structured details in an 'Args' section. It is clear but slightly verbose; could be more concise while retaining all necessary information.
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?
Given the presence of an output schema (so return values are documented elsewhere), the description adequately covers input specification and purpose. It lacks explanation of potential error conditions or performance characteristics, but overall is sufficiently complete for a single-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by detailing the single required parameter 'packages': format ('name:ecosystem:version' lines), examples, and supported ecosystems. This adds significant meaning beyond the bare 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?
The description clearly states the tool scans container image packages for known CVEs via OSV.dev, with specific input format and examples. It distinguishes itself from sibling tools by focusing on container images and using OSV.dev, which is unique among the listed tools.
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?
The description provides explicit input format and examples, along with supported ecosystems, guiding the agent on proper usage. However, it does not explicitly state when not to use this tool or mention alternative tools for similar tasks, though the context of sibling tools implies this is the dedicated container scanning tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full burden. It discloses supported input formats, the max package limit (behavioral constraint), and that only vulnerable packages are returned. It does not explicitly state read-only behavior or auth needs, but the scanning action inherently implies safety, and the max limit adds transparency.
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 description is efficient: one sentence for purpose, a line for format support, and a brief args section. It is well front-loaded. Minor improvement could be separating the argument description more clearly, but it remains concise without wasted words.
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?
Given the tool has an output schema (implied by context), missing return structure details are acceptable. The description covers input, supported formats, and key behavioral limits. It lacks explanation of error handling or malformed input, but overall provides sufficient context for typical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 0% parameter description coverage, so the description must compensate. It fully explains the dependency_list parameter: what formats it accepts (file contents or formatted lines) and the max 1000 packages. This adds significant meaning beyond the schema's bare type definition.
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?
The description clearly states the tool bulk scans dependencies for CVEs via OSV.dev, specifies supported formats (requirements.txt, package.json, pom.xml, or generic lines), and notes it returns only vulnerable packages. This is a specific verb-resource combination that distinguishes it from siblings like check_package_vulns.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for bulk scanning with max 1000 packages, but does not explicitly state when to use this tool versus alternatives like check_package_vulns. It lacks directives on prerequisites or exclusions, leaving usage context implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavioral disclosure. It discloses the need for a GITHUB_TOKEN for best results and the security research scope. However, it does not explain behavior without the token (e.g., rate limits, reduced results) or any other traits like idempotency or side effects. This is adequate but not comprehensive.
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 description is concise (3 sentences) and front-loaded with the main purpose. It includes necessary details like token requirement and use case. Minor improvement could be separating use case or adding a note about output, but overall efficient.
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?
Given the tool has a single parameter and an output schema (not described), the description is reasonably complete. It explains what the search term should be, the purpose, and prerequisites. The existence of an output schema means return values don't need elaboration. However, it could mention the response type (e.g., list of matches) for completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero description coverage (0%), so the description must compensate. It provides detailed guidance: 'CVE ID, tool name, or keyword to search for in public repo files (e.g. CVE-2024-1234, AWS_SECRET_ACCESS_KEY, log4j).' This adds significant meaning beyond the schema's type and title.
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?
The description clearly states the tool searches GitHub public repositories for exposed credentials/secrets related to a search term. It specifies the search term can be a CVE ID, tool name, or keyword, providing examples (e.g., CVE-2024-1234, AWS_SECRET_ACCESS_KEY, log4j). This distinguishes it from sibling tools like lookup_cve or check_exploit_availability, which focus on CVE details and exploit availability, respectively.
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?
The description mentions 'Requires GITHUB_TOKEN for best results. For security research only.' This provides context on prerequisites and intended use. While it doesn't explicitly state when not to use it or compare with alternatives, the specificity of the tool (searching for secrets in repos) makes it clear when to invoke.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It states the operation is a lookup (read-only) and requires an environment variable, but does not mention any side effects, rate limits, or safety assurances. While likely safe, the description could be more explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise: two sentences covering purpose, and a clear argument specification. It is front-loaded with the key functionality and has no unnecessary words.
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?
Given the tool has a single parameter and an existing output schema, the description adequately covers what the tool does and its prerequisite. It does not need to explain return values because an output schema exists. Slight improvement could include mention of JSON output format.
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?
With 0% schema description coverage, the description adds valuable context: 'ip: IPv4 address to look up (e.g. 8.8.8.8)'. This clarifies the expected format and provides an example, going beyond the bare 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?
The description clearly states the tool looks up a host on Shodan, listing open ports, services, OS, and CVEs. This is specific and distinguishes it from sibling tools like get_domain_intel or lookup_cve, which focus on different entities.
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?
It mentions the required SHODAN_KEY environment variable, which is essential context. However, it does not explicitly state when to use this tool versus alternatives like passive_dns_lookup or search_cves, leaving the decision to the agent's inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses the return content (CVSS scores, description, weaknesses, CISA KEV status). It does not cover potential rate limits or authorization, but the read-only nature is inferred.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with no wasted words, front-loading the purpose and return details, followed by a clear args section.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple single-parameter tool with an output schema, the description fully covers what the tool does, what it returns, and how to provide input, leaving no gaps.
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?
The schema has 0% description coverage, but the description adds meaning via an example format ('e.g. CVE-2021-44228') and explains it is a CVE identifier, which is sufficient for a single parameter.
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?
The description clearly states the tool looks up a specific CVE by ID from NVD, distinguishing it from sibling tools like search_cves (search) and get_cve_summary (summary).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when one has a specific CVE ID (e.g., CVE-2021-44228), but does not explicitly mention when to avoid this tool or suggest alternatives like search_cves for broader queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Given no annotations, the description carries full burden. It clearly states a read-only parse action with no side effects. While it doesn't detail error handling or validation, the tool's simplicity and the existence of an output schema mitigate the need.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only three lines, with the purpose front-loaded. Every word is informative, including the inline parameter explanation and example, with no extraneous content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one required parameter, no nested objects) and has an output schema. The description fully covers the input semantics and purpose, making it complete for its complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant meaning beyond the schema by specifying the parameter 'vector' as a CVSS vector string and providing an example. Since schema description coverage is 0%, this compensation is excellent.
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?
The description clearly states it 'Parse and explain a CVSS vector string' with versions v2, v3.x, or v4.0. This specific verb+resource combination distinguishes it from sibling tools like calculate_risk_score or check_exploit_availability.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. However, the specific purpose of parsing CVSS vectors implies its usage context, but lacks exclusions or references to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It explains concurrent fan-out, NVD fallback, and depth-specific behavior (SSVC for deep). It does not mention rate limits or auth, but the core behavioral traits are well disclosed.
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 description is well-structured with a summary line, then detailed explanation, then Args. It is concise for the complexity but could be slightly tighter. Front-loaded with purpose.
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?
Given the tool's complexity and the presence of an output schema, the description covers inputs, behavior, and depth variations adequately. It does not detail output fields, but that is likely in the output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description provides a detailed Args block explaining cve_id and depth, including explicit values for depth. This adds significant meaning beyond the bare 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?
The description clearly states it is a one-call CVE triage orchestrator that fans out multiple upstream sources and computes a composite risk score. It distinguishes itself from sibling tools like lookup_cve or get_epss_score by offering a comprehensive assessment in a single call.
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?
The description implies use when a holistic risk assessment is needed, but it does not explicitly state when to avoid this tool in favor of siblings. However, the context of fanning out multiple sources and depth options gives clear usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that it pings NVD without rate limiting and returns only API key names (not values). With no annotations, the description covers safety and privacy behavioral traits adequately.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, then critical usage note. Every word earns its place, no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Fully covers what the tool checks and a key constraint (rate limiting). Given no parameters and existence of an output schema, the description is complete.
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?
No parameters exist, so baseline 4 applies. Description does not need to add parameter info.
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?
Clearly states the tool checks server health including NVD connectivity, KEV status, cache, risk scoring version, manifest hash, and configured API keys. Distinct from siblings which all deal with CVEs or security 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?
Explicitly warns not to call in a loop due to no rate limiting. Provides clear context on what it checks, though could mention it's a read-only health check for initial diagnostic use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![cve-mcp-server MCP server](https://glama.ai/mcp/servers/mukul975/cve-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/mukul975/cve-mcp-server)

Score Badge

Copy to your README.md:

[![cve-mcp-server MCP server](https://glama.ai/mcp/servers/mukul975/cve-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/mukul975/cve-mcp-server)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/mukul975/cve-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server