Skip to main content
Glama

vulnerability_exploits

Read-onlyIdempotent

List the known exploits, proofs of concept, and detection templates for a specific CVE.

What this tool does

Returns the exploit maturity of a CVE and the related public material known to SecDB:

  • Metasploit modules

  • Exploit-DB entries

  • Nuclei templates

  • proofs of concept published on GitHub

When to use this tool

Use this tool when the user asks:

  • "Is there a public exploit for this CVE?"

  • "Is there a Metasploit module or a Nuclei template for this vulnerability?"

  • "How mature is the exploitation of this CVE?"

For other evidence (scanner plugins, social media, MISP), use sightings_search.

Inputs

  • cve_id: valid CVE identifier (CVE-YYYY-NNNNN).

  • limit: maximum number of items to return for each kind of material (default 10, maximum 100).

Outputs

  • exploit_maturity: score, max, and the sources that contribute to the score

  • metasploit: modules, each with module, name, type

  • exploitdb: entries, each with id, description, type, platform, date_published

  • nuclei: templates, each with template, name, severity

  • poc: repositories, each with name, html_url, description

  • totals: total number of items for each kind of material, before limit is applied

LLM usage guidelines

  • Empty lists mean that SecDB knows no such material, not that the vulnerability cannot be exploited.

  • Report references and availability only: do not reproduce or write exploit code.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "cve_id": "<cve_id>"
    },
    "name": "vulnerability_exploits"
  }
}

Input Schema

NameRequiredDescriptionDefault
limitNoMaximum items for each kind of material
cve_idYesCVE identification (CVE-YYYY-NNNNN)

Output Schema

NameRequiredDescriptionDefault
pocYesProofs of concept
cve_idYesCVE identifier
nucleiYesNuclei templates
totalsYesTotal items for each kind of material
exploitdbYesExploit-DB entries
metasploitYesMetasploit modules
exploit_maturityYesExploit maturity score and sources

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.4/5.0
Behavior4/5

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

Beyond the readOnly/idempotent/non-destructive annotations, it discloses a genuinely important behavioral caveat — empty lists mean SecDB has no record, not that exploitation is impossible — plus a usage constraint (report references only, do not write exploit code) and the fact that `totals` are computed before `limit`. It stops short of saying anything about freshness or coverage limits of the source data.

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?

Well front-loaded: the one-line purpose precedes the sectioned detail, and each section is skimmable. The 'Outputs' block is the weakest part, since an output schema already exists and this enumerates the same fields a second time.

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 two-parameter read-only lookup with full schema coverage, an output schema, and rich annotations, nothing an agent needs in order to decide to call it and interpret the result is missing. The interpretation caveat about empty lists closes the main remaining risk.

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%, so both parameters are already documented, including the per-material-kind semantics of `limit`. The description largely restates the schema (default 10, maximum 100, CVE-YYYY-NNNNN format) without adding syntax or edge-case handling such as behavior for an invalid or unknown CVE.

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?

Opens with a specific verb and resource: 'List the known exploits, proofs of concept, and detection templates for a specific CVE.' The four enumerated material kinds (Metasploit, Exploit-DB, Nuclei, PoC) make the scope unambiguous against siblings like vulnerability_info or sightings_search.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The 'When to use' section gives three concrete user-phrasing examples, and it explicitly routes adjacent evidence needs to the alternative: 'For other evidence (scanner plugins, social media, MISP), use sightings_search.' That is a named alternative plus the condition that selects it.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources