VulnMCP

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation5/5
Each tool targets a distinct resource and action: classification, vulnerability lookup, sightings, KEV, comments, bundles, CPE guessing, and GNA registry. The GNA tools (get, list, search) are differentiated by query type, and no two tools appear to do the same thing.
Naming Consistency5/5
All tool names follow a consistent lowercase snake_case verb_noun pattern (e.g., classify_severity, search_vulnerabilities, list_kev_entries). Verbs are uniform and predictable, with no mixing of conventions.
Tool Count4/5
With 16 tools, the count is slightly above the ideal 3-15 range but each tool serves a distinct purpose in the vulnerability intelligence domain. The breadth of features (search, classify, sightings, KEV, comments, bundles, CPE guessing, GNA) justifies the size, though it borders on heavy.
Completeness4/5
The tool set covers vulnerability search, retrieval, classification, sightings, KEV, comments, bundles, CPE guessing, and GNA registry, providing a comprehensive read and analysis surface. Minor gaps exist such as no create/update/delete operations for comments or bundles, but these are likely out of scope for this server.
Average 4.1/5 across 16 of 16 tools scored. Lowest: 3.2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 9 commits in the last 12 weeks
- Last stable release on March 26, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under AGPL 3.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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true. The description adds useful context about the default base URL and the VULNMCP_LOOKUP_URL environment variable override. However, it omits other behavioral traits like pagination or rate limits, but with annotations covering safety, a 3 is appropriate.
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 concise two-sentence structure: the first sentence states the purpose, the second provides configuration context. It is front-loaded and contains no filler, making it efficient and well-structured.
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 tool's complexity (10 parameters, all optional) and the presence of an output schema, the description is notably minimal. It doesn't explain how filters interact, typical usage scenarios, or any behavioral details beyond the base URL. The output schema helps, but the description still feels under-specified for a tool of this scope.
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 description coverage is 100% — every parameter has a description, so the schema carries the full burden. The tool description itself adds no additional parameter semantics beyond what is already in the schema. Baseline 3 is correct.
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 'Search vulnerabilities on Vulnerability Lookup with filters,' which specifies the verb, resource, and scope. It distinguishes from sibling tools by naming the resource (vulnerabilities), though it doesn't explicitly contrast with alternatives like get_vulnerability. A solid, clear purpose.
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 or how filters should be applied. The description only mentions the base URL and environment variable, which is configuration rather than usage guidance. There is no mention of exclusions or preferred contexts.
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?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, establishing a safe, idempotent read operation. The description adds conceptual context about bundles but does not disclose additional behavioral details such as pagination or filtering behavior, which are already covered by the schema and annotations.
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 long, with the first sentence stating the action and the second explaining what bundles are. Every sentence earns its place, and the content is front-loaded with the primary 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?
For a simple paginated search tool, the description is sufficiently complete: it explains the domain concept of bundles, and the schema covers parameters while the output schema covers return values. Nothing critical is missing for an agent to select and invoke the tool correctly.
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 100% parameter description coverage, so the baseline score of 3 applies. The description does not add extra meaning to the parameters, leaving the schema as the primary source of parameter documentation.
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 the specific verb 'Search' with the resource 'bundles' on Vulnerability Lookup, clearly distinguishing it from sibling search tools like search_vulnerabilities and search_sightings. It also explains what bundles are (curated collections of related vulnerabilities), reinforcing the tool's unique purpose.
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 context by explaining that bundles are useful for grouping CVEs by campaign, product, or incident, which suggests when to use this tool. However, it does not explicitly mention alternatives or exclusions, relying on the domain explanation to convey applicability.
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?
Annotations already declare readOnly, idempotent, and non-destructive behavior. The description adds context about the data ('actively discussed or exploited') but does not disclose additional behavioral traits such as pagination behavior or filtering semantics beyond what the schema already provides.
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 clearly states the tool's purpose without any redundant or vague wording. It is efficient and 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?
With a rich input schema and an output schema present, the description provides sufficient context for an agent to understand the tool's core function. It could be slightly more explicit about relationship to sibling tools, but overall it is complete for a search tool with well-documented parameters.
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 description coverage is 100%, so all 8 parameters are already documented in the schema. The description adds no extra parameter-level meaning, which aligns with the baseline score of 3.
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 a specific verb ('Search') and resource ('sightings'), clearly distinguishing it from siblings like 'search_vulnerabilities' and 'create_sighting'. The phrase 'actively discussed or exploited vulnerabilities' adds useful intent and scope.
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 vulnerability sightings that are actively discussed or exploited, but it does not explicitly state when to choose this tool over alternatives like 'search_vulnerabilities' or 'get_vulnerability'. No exclusions or alternative mentions are 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?
The annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the agent knows this is a safe read operation. The description adds that it returns exactly 3 most recent vulnerabilities, which is useful behavioral detail. However, it does not disclose error handling, rate limits, or behavior when no vulnerabilities are found. With annotations covering the safety profile, the description adds moderate value, consistent with the 'get_calls' calibration example.
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, concise sentence that front-loads the core action ('Fetch the 3 most recent vulnerabilities') and immediately specifies the input ('for a given CWE ID'). There is no waste, and every word earns its place. It is optimally structured for quick parsing.
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?
This is a simple tool with one well-documented parameter, comprehensive annotations, and an existing output schema (though not shown in the prompt). The description adequately conveys the tool's purpose and result scope without needing to explain return values, since the output schema covers that. It is complete for a recent-list retrieval tool of this simplicity.
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 provides 100% coverage for the only parameter (cwe_id), including a clear description and examples ('CWE-79' or '79'). The tool description does not add any parameter-specific information beyond what the schema already provides, so the baseline of 3 applies.
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 ('Fetch'), the resource ('the 3 most recent vulnerabilities'), and the scope ('for a given CWE ID'), which distinguishes it from sibling tools like get_vulnerability (which likely fetches by vulnerability ID) and search_vulnerabilities (which likely searches broader criteria). The inclusion of the count '3' and the CWE filter makes the purpose unambiguous.
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 when to use this tool (when you need recent vulnerabilities for a specific CWE), but it does not explicitly state alternatives or exclusions. It lacks guidance such as 'for broader searches, use search_vulnerabilities' or 'if you have a specific vulnerability ID, use get_vulnerability'. The usage context is clear but not comprehensive relative to alternatives.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds behavioral context by explaining the default base URL (https://cpe-guesser.cve-search.org) and the VULNMCP_CPE_GUESSER_URL environment variable for override. This is useful configuration information but does not disclose details like response behavior or edge cases. With annotations, this extra context earns a 3, though richer operational details would push higher.
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: the first clearly states the purpose, and the second provides necessary configuration details about the default URL and environment variable. Every sentence earns its place, and 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.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter, full annotations, and an output schema, the description provides sufficient context. It includes purpose and configuration details. The output schema already handles return values, and annotations handle safety. There is no missing critical information that would prevent correct tool selection or invocation.
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 description coverage is 100%: the input schema already describes the 'query' parameter as 'A list of product keywords (e.g. ["outlook", "connector"]).' The description does not add additional parameter semantics beyond this. Per the rubric, when schema coverage is high, the baseline is 3 even with no extra param information, and no extra value is added here.
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 'Guess CPE values from product-related keywords using cpe-guesser.' This is a specific verb (guess) + resource (CPE values) + method (from keywords using cpe-guesser). It is easily distinguishable from sibling tools like search_vulnerabilities or classify_severity, which involve different operations.
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 you have product keywords and need CPE values, this tool guesses them. However, it provides no explicit when-to-use versus alternatives, no exclusions, and does not reference sibling tools. Usage context is clear but not elaborated, so it falls under 'implied usage.'
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?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds semantic context about comments being community-contributed but does not disclose behavioral traits such as pagination behavior, result ordering, or rate limits. It does not contradict the annotations.
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 two sentences, front-loaded with the primary action 'Search comments related to vulnerabilities'. It contains no redundant information and is appropriately sized for a simple search tool.
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?
For a simple read-only filtered search tool with all parameters documented in the schema and an output schema present, the description is complete. It explains the domain (community comments on vulnerabilities) and the tool's purpose, and the schema handles parameter and return value specifics.
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 100% description coverage, with each parameter (page, author, vuln_id, per_page) already explained. The description does not add parameter-specific meaning beyond what the schema provides, so the baseline score of 3 applies.
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 a specific verb and resource ('Search comments related to vulnerabilities') and clarifies that comments are community-contributed notes attached to specific vulnerabilities. This clearly distinguishes the tool from sibling search tools like search_vulnerabilities and search_sightings, which target different resources.
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 provides context about what comments are but does not explicitly state when to use this tool vs alternatives, nor does it mention exclusions or alternative tools. Usage is implied by the tool's name and description, but no proactive guidance is given.
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?
Annotations already declare read-only and idempotent behavior. The description adds meaningful behavioral context by explaining the tool uses a ML model to predict categories and maps them to parent CWEs, which signals that outputs are predictions and not exact database matches. This goes beyond basic safety annotations without contradicting them.
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, front-loaded with the core purpose, and each sentence provides distinct value—purpose and model behavior. No filler or 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 simple tool with one input and an existing output schema, the description sufficiently explains the tool's behavior (classification with parent CWE mapping). It does not mention limitations like language support (already in schema) or probability scores, but these are not essential for correct selection and invocation. The sibling context makes the tool's niche clear.
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 schema covers the single parameter (description) with 100% coverage, including language specification (English). The description does not add extra parameter semantics such as length limits or examples, but the schema adequately defines the input, so no gap exists.
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 states a specific action ('Classify a vulnerability description into CWE categories') and distinguishes from siblings like classify_severity by specifying CWE categorization. It also mentions the model (CIRCL's RoBERTa) and mapping to parent CWEs, making the purpose unambiguous.
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 the tool is for CWE classification but does not explicitly state when to use it versus alternatives such as classify_severity. No exclusions or alternative recommendations are provided, 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false and destructiveHint=false, but the description adds valuable behavioral context by disclosing the authentication requirement ('Requires an API key on most Vulnerability Lookup instances') and the automatic authentication mechanism. This goes beyond the structured annotations, though it stops short of describing side effects or return details.
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 exceptionally concise, consisting of two short sentences. The first sentence states the core purpose, and the second provides essential authentication context. Every word earns its place, and the information is front-loaded for quick comprehension.
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 (3 flat parameters, no nested objects), an output schema exists, and annotations cover safety hints, the description covers the key contextual need: authentication. It doesn't explain the return value, but that is presumably addressed by the output schema. A small gap is the lack of guidance on what constitutes a valid 'sighting_type' or 'source', but these are not strictly required for invocation.
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 description coverage is 100%, with all three parameters (vulnerability_id, sighting_type, source) individually described. The description adds no additional parameter semantics beyond what the schema already provides, so the baseline score of 3 is appropriate.
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's purpose: 'Create a sighting for a vulnerability.' This is a specific verb+resource pairing that distinguishes it from sibling tools, which are mostly read/search operations. The addition of authentication context further clarifies the tool's nature without ambiguity.
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 by stating it creates a sighting, and mentions the API key requirement, which is a precondition. However, it does not explicitly contrast with alternatives or state when not to use it. The sibling context suggests this is the only create tool, but the description itself provides no comparative guidance, so it earns a middle score.
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?
Annotations already declare readOnly and idempotent, so the description's key added value is the exclusivity constraint between id and short_name. This is meaningful behavioral guidance beyond the structured data, though no error details or response format are included.
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 concise sentences, front-loaded with the purpose and immediately followed by the key constraint. Every word earns its place with no 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?
The tool is a simple getter with a complete input schema, strong read-only annotations, and an output schema. The description covers the essential identifier requirement; minor gaps like error behavior when both parameters are omitted are acceptable given the 'exactly one' statement.
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 description coverage is 100%, so the schema fully documents both id and short_name with examples. The description restates the 'exact' requirement for short_name but does not add material semantics beyond what the schema already provides.
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 states the tool gets a specific GNA entry by numeric ID or exact short name, using a clear verb and resource. It distinguishes from list/search siblings by emphasizing 'specific' and the exact-identifier constraint, but does not explicitly name alternatives.
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 instruction 'Exactly one of id or short_name must be provided' gives clear usage context for invocation. It implies this tool is for known identifiers rather than broad search, though it does not explicitly contrast with list or search 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?
Annotations already convey readOnlyHint, openWorldHint, idempotentHint, and non-destructive behavior. The description adds that results are ranked by sighting activity and useful for prioritization, but does not disclose additional behavioral details like pagination or sorting direction beyond what the schema already provides.
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 sentences: the first states exactly what the tool does, and the second explains the value. Every sentence earns its place; no redundant or vague text.
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 scope, full schema coverage, and presence of an output schema, the description is complete. It explains the tool's purpose and how to think about the result (prioritization), and the annotations cover safety and idempotence.
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 description coverage is 100%, so the parameters (limit, date_to, date_from, sighting_type) are fully documented in the schema. The description does not add any extra meaning to these parameters, so the baseline score of 3 is appropriate.
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's function: 'Get vulnerabilities ranked by sighting activity.' This specifies the verb (get), the resource (vulnerabilities), and the ranking criterion (sighting activity), distinguishing it from sibling tools like search_vulnerabilities or get_recent_vulnerabilities_by_cwe.
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 clear usage context: it helps 'prioritize vulnerabilities with high real-world activity' and distinguish important from minor issues. It does not explicitly mention alternatives or when not to use, but the prioritization purpose implies when this tool is appropriate over siblings.
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?
Annotations already declare read-only, open-world, idempotent, and non-destructive behavior, so the description's burden is reduced. It adds useful context about the configurable base URL (default and environment variable override), which is beyond annotation data and helps in deployment contexts. No contradictions with annotations.
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: the first immediately states the tool's purpose, and the second adds essential configuration context. Every word earns its place; no filler or redundancy. Front-loaded and efficient.
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 operation (lookup by ID with optional flags), the annotations, output schema, and parameter descriptions provide comprehensive context. The description adds configuration details and source identification, making the tool fully understandable for an agent without external documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all parameters, so the baseline is 3. The description does not add meaning beyond the schema—it merely repeats that the lookup is by ID, which is already in the parameter description. No extra syntax or format details are provided.
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's function with a specific verb ('Get') and resource ('detailed information about a vulnerability by its ID from Vulnerability Lookup'), immediately distinguishing it from sibling tools like search_vulnerabilities and get_recent_vulnerabilities_by_cwe. No ambiguity.
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 the agent has a vulnerability ID, but does not explicitly contrast with alternative tools or state when not to use it. Since sibling tools exist for searching and other lookup modes, explicit exclusions would improve guidance. The context is clear but not fully articulated.
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?
Annotations already indicate read-only, idempotent, non-destructive behavior. The description adds valuable behavioral context: language auto-detection, use of different models for different languages, and the fact that Chinese descriptions only yield low/medium/high (no critical). This goes beyond what annotations convey.
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 and well-structured: a single purpose sentence, followed by a compact bulleted list of model/language details, and a closing note on auto-detection. No unnecessary words or repetition.
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 tool's simplicity (2 params, output schema present), the description is complete. It covers purpose, supported languages, model variants, label sets, and the auto-detection behavior. Return values are not described, but the output schema exists so that is not a gap.
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 description coverage is 100%, with both 'description' and 'language' clearly explained in the schema. The tool description does not add significant new meaning to the parameters; it only repeats the auto-detection note that is already in the language parameter description. Baseline 3 is appropriate.
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's function with a specific verb+resource: "Classify the severity of a vulnerability based on its description." It also distinguishes itself from the sibling tool classify_cwe by focusing on severity rather than CWE classification, and provides details about language-specific models.
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 gives clear context for when to use the tool: to classify severity of vulnerability descriptions. It does not explicitly mention alternatives or exclusions, but the sibling tools are clearly different in purpose (e.g., classify_cwe), making the use case clear without naming them.
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?
Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds value by disclosing a network-side effect ('Downloads references if not already cached locally') and describes the return shape, going beyond the annotations without contradicting them.
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?
Four sentences, each earning its place: 1) what it lists, 2) how the output relates to a sibling tool, 3) the downloading behavior, 4) the return format. No redundancy or filler.
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?
With no parameters and a provided output schema, the description covers all necessary context: purpose, relationship to list_kev_entries, side effects, and return structure. It is complete for a read-only reference-listing 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?
The tool has zero parameters, so there is nothing to document. Baseline 4 for no parameters is appropriate; the description correctly focuses on output and usage rather than nonexistent inputs.
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 opens with 'List GCVE references' — a specific verb and resource — and clarifies the content as 'vulnerability dataset sources and their GNA mappings'. It also distinguishes from the sibling tool list_kev_entries by explaining how the returned UUIDs feed into that tool's parameter.
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 gives a concrete usage context: the KEV catalog UUIDs can be used with list_kev_entries' vulnerability_lookup_origin parameter. It also mentions the download-if-not-cached behavior, but does not explicitly contrast with alternative tools or state when not to use it.
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?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is known. The description adds meaningful context about how UUIDs identify KEV catalogs and that the base URL can be overridden via an environment variable. No contradictions with annotations.
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 compact paragraph of four sentences. It front-loads the core purpose, follows with use cases, then gives essential UUID context and configuration details. Every sentence contributes necessary information with 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?
For a tool with 9 optional parameters, an output schema, and a clear domain, the description covers all necessary operational context: what it does, when to use it, how to identify catalog UUIDs, known examples, and configurability. The existence of an output schema covers return value details, so nothing critical is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, providing baseline 3. The description adds significant semantic value by explaining the 'vulnerability_lookup_origin' parameter in depth, listing known catalog UUIDs and repeating the pointer to list_gcve_references. This enriches the schema's terse description of that 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 uses a specific verb ('List and filter') paired with a clear resource ('Known Exploited Vulnerability (KEV) entries'). It further clarifies the scope with concrete use cases: browsing catalogs, checking for a specific vulnerability, and finding recent entries. This clearly differentiates it from sibling tools like list_gna_entries.
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 explicitly states when to use this tool ('Use this tool to browse... check... find...') and points to a specific alternative for discovering KEV catalogs ('Use the list_gcve_references tool to discover available KEV catalogs and their UUIDs'). It lacks an explicit 'when not to use' statement, but the guidance is otherwise clear.
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?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, so the safety profile is covered. The description adds valuable behavioral detail beyond the schema by specifying case-insensitive substring matching. No contradictions with annotations.
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?
One sentence, 10 words, front-loaded with the action and resource. Every word earns its place; no filler or 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?
For a simple one-parameter search tool with an output schema and comprehensive annotations, the description is complete. It covers the tool's purpose, matching semantics, and scope ('by name' = GNA short names as per schema). No critical information is missing.
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 100% coverage of the single parameter, describing it as a search term matching GNA short names. The description enhances this by specifying case-insensitive substring matching, which adds semantic detail not present in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies a clear verb ('Search') and resource ('GNA entries'), and immediately clarifies the matching behavior ('case-insensitive substring match'). This distinguishes it from siblings like get_gna_entry (exact retrieval) and list_gna_entries (listing all).
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 clear context: use this tool to find GNA entries by name with case-insensitive substring matching. It does not explicitly mention alternatives or exclusions (e.g., use get_gna_entry for exact IDs), but the context is clear enough for an agent to infer when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnly, idempotent, non-destructive), the description discloses that the tool downloads and verifies the registry if not cached, and it also outlines the return structure (dict with count and list of entries with specific fields). This adds meaningful 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?
The description is three sentences: a clear purpose statement, a note on download/caching, and a return summary. No redundant filler.
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?
For a tool with no parameters and an output schema, the description covers the main behavior, the side effect (download/verify), and the return format. It is complete for an agent to select and invoke it.
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 no parameters, so there is nothing for the description to clarify. The description adds the return structure, which is helpful but not strictly parameter-related. Baseline 4 for zero params.
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 the specific verb 'List' plus the resource 'Global Numbering Authorities (GNA)' and scopes it to the GCVE registry, which clearly distinguishes it from siblings like get_gna_entry and search_gna.
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 retrieving the full set of GNA entries ('List all'), but it does not explicitly mention alternatives or exclusion criteria. The sibling tools are not referenced, so usage guidance is clear but not optimally contrastive.
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:

[![VulnMCP MCP server](https://glama.ai/mcp/servers/vulnerability-lookup/VulnMCP/badges/card.svg)](https://glama.ai/mcp/servers/vulnerability-lookup/VulnMCP)

Score Badge

Copy to your README.md:

[![VulnMCP MCP server](https://glama.ai/mcp/servers/vulnerability-lookup/VulnMCP/badges/score.svg)](https://glama.ai/mcp/servers/vulnerability-lookup/VulnMCP)

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/vulnerability-lookup/VulnMCP'

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