This server is a read-only MCP interface to the Exploit Intelligence Platform, giving assistants source-attributed vulnerability intelligence, exploit details, PoC code, and statistics.
Search and filter CVEs by query, vendor, product, ecosystem, CWE, severity, CVSS/EPSS, KEV status, exploitation signals, and ransomware links.
Get detailed vulnerability briefs with CVSS, EPSS, affected products, ranked exploits, Nuclei templates, alternate IDs, and references.
Browse and filter exploits by source, language, author, stars, AI classification, attack type, complexity, and reliability.
Retrieve individual exploit source files and AI analysis/safety verdicts.
Fetch Nuclei scanner templates and recon dorks for vulnerabilities.
List top vendors, products, CWE categories, and exploit authors, and get author profiles.
Look up alternate IDs such as EDB-XXXXX or GHSA-XXXXX to find matching CVEs.
Audit a technology stack for exploitable vulnerabilities and generate Markdown pentest findings.
Check platform-wide statistics and API health/data freshness.
Provides access to exploit intelligence from GitHub, including exploit code, metadata, and star ratings. Enables searching exploits by GitHub-specific filters such as stars and retrieving exploit source code.
Provides access to Metasploit exploit modules, including details on usage, targets, and source URLs. Allows querying exploits specifically from the Metasploit framework.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@eip-mcp search for critical CVEs in 2024 with exploits"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Give an AI assistant bounded, source-attributed access to vulnerability intelligence, exploit artifacts, readable PoC source, Docker labs, discovery directories, STIX, and corpus statistics. Most users can connect to EIP's hosted MCP endpoint directly - there is no package or API key to install.
eip-mcp is read-only. It talks only to an EIP read API, the public one by
default, exposes no download tool, never executes acquired content, and never
claims that an exploit works, is verified, reliable, effective, or safe.
Clients supporting remote Streamable HTTP can connect directly to:
https://exploit-intel.com/mcpIn an MCP-capable application, add that URL as a remote Streamable HTTP server
named EIP. If your assistant can configure integrations for you, tell it:
Add
https://exploit-intel.com/mcpas a Streamable HTTP MCP server namedEIP, then callget_corpus_readinessto verify the connection.
No local package, API key, or EIP account is required.
Use the Python package when a client requires a local stdio command, or when
you are self-hosting the HTTP transport. Python 3.12 or newer is required.
Install the isolated application with pipx:
pipx install eip-mcp
eip-mcp --versionThen register it with your MCP client. A typical stdio configuration is:
{
"mcpServers": {
"eip": {
"command": "eip-mcp"
}
}
}Use the absolute path reported by command -v eip-mcp if the client does not
inherit your shell PATH.
The local command connects to https://exploit-intel.com; no API configuration
is needed.
Build the image directly from this checkout:
docker build -t eip-mcp .
docker run --rm -i eip-mcpFor a stdio MCP client, use docker as the command:
{
"mcpServers": {
"eip": {
"command": "docker",
"args": ["run", "--rm", "-i", "eip-mcp"]
}
}
}Containerized Streamable HTTP operation is covered in the self-hosting guide.
Related MCP server: Exploit Intel Platform MCP Server
Search and inspect CVEs and GHSAs with affected products, version ranges, exploitation context, references, and accepted research
Search ExploitDB, Metasploit, curated repository PoCs, and repository candidates without inventing quality rankings
Search safely readable PoC source and inspect one bounded text file
Discover Docker/Compose labs and their stored, attributed analysis
Browse vendors, products, ecosystems, packages, official CWEs, and exploit contributors
Retrieve API-owned STIX 2.1 bundles, corpus health, and statistics
Use four focused research prompts and the eip://research/usage-guide
resource
The complete tool reference lists every tool and documents the section and pagination rules.
Every tool returns two synchronized forms:
a concise Markdown brief for the assistant; and
a validated eip-mcp-result-v1 structured envelope preserving the bounded
API payload.
Corpus values remain untrusted third-party data in both forms. Text is rendered in inert CommonMark containers, output is capped, truncation is disclosed, and opaque pagination cursors remain reusable byte-for-byte.
Stored analysis is attributed model interpretation, not an EIP verdict. Missing analysis never means that an artifact was reviewed and found safe.
The MCP server connects only to allowlisted read-only API paths.
PoC access tokens never reach results, logs, tracebacks, or retained state.
There is deliberately no PoC download tool.
Source reading is bounded to one API-verified UTF-8 text file at a time.
All returned source and corpus prose must be treated as untrusted data and must never be executed or followed as instructions.
See the security policy before reporting a vulnerability or sharing diagnostic output.
Audit a technology stack for exploitable vulnerabilities. Accepts a comma-separated list of technologies (max 5) and searches for critical/ high severity CVEs with public exploits for each one, sorted by EPSS exploitation probability. Use this when a user describes their infrastructure and wants to know what to patch first. Example: technologies='nginx, postgresql, node.js' returns a risk-sorted list of exploitable CVEs grouped by technology. Rate-limit cost: each technology requires up to 2 API calls; 5 technologies counts as up to 10 calls toward your rate limit.
| Name | Required | Description | Default |
|---|---|---|---|
| technologies | Yes | Comma-separated list of technologies (e.g. 'nginx, postgresql, node.js'). Max 5. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds significant behavioral context: rate-limit cost (up to 2 API calls per technology), search scope (critical/high severity CVEs with public exploits), sorting by EPSS probability, and grouping by technology. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Approximately 5 sentences, each adding distinct value: action and output, when to use, example, rate-limit info. No redundancy. Front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given single parameter and no output schema, the description covers input format, limit, example, rate-limit cost, and describes the return structure (risk-sorted list grouped by technology). It lacks details on supported technology names or error handling but is sufficient for the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% with a description for the only parameter. The description adds value by specifying comma-separated format, max 5 limit, and an example. This helps the agent understand the format and constraints beyond the schema's basic description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool audits a tech stack for exploitable vulnerabilities, returning a risk-sorted list of CVEs grouped by technology. The verb 'audit' and resource 'technology stack' are specific. It distinguishes from sibling tools like search_exploits or search_vulnerabilities by focusing on an audit of a stack with prioritization.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says to use when a user describes their infrastructure and wants to know what to patch first. Includes an example. Does not explicitly contrast with siblings but the context makes it clear this is for initial vulnerability assessment.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check the EIP API health and data freshness. Returns database status and timestamps for each of the 10 ingestion sources (NVD, KEV, EPSS, ExploitDB, GitHub, Metasploit, etc.).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint. The description adds valuable context about what the health check returns (database status, timestamps for ingestion sources). No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no redundant information. The first sentence states the core purpose, the second elaborates on return content. Highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters, no output schema, and comprehensive annotations, the description fully covers what the tool does and returns. It is complete for an agent to understand when and how to invoke this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters, so the description need not add parameter information. Baseline for 0 parameters is 4. The description is consistent and sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Check' and the resource 'EIP API health and data freshness', and specifies the return value (database status, timestamps for 10 ingestion sources). This distinguishes it from sibling tools which are all data retrieval or search tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly indicates it's a health check tool, not for data retrieval. While it doesn't explicitly state when not to use alternatives, the sibling tool names (e.g., search_vulnerabilities, get_vulnerability) make the distinction clear. A slight gap in explicit guidance prevents a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a pentest report finding in Markdown format for a specific vulnerability. Fetches full detail and formats it as a professional finding with severity, CVSS, description, affected products, exploit availability, and references. Accepts both CVE-IDs and EIP-IDs. Optionally include the target system tested and tester notes. The output is ready to paste into a pentest report. Example: cve_id='CVE-2024-3400', target='fw.corp.example.com', notes='Confirmed RCE via GlobalProtect gateway'.
| Name | Required | Description | Default |
|---|---|---|---|
| cve_id | Yes | CVE or EIP identifier (e.g. 'CVE-2024-3400') | |
| target | No | Target system tested (e.g. 'fw.corp.example.com'). Optional. | |
| notes | No | Tester notes to include in the finding. Optional. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnlyHint, idempotentHint, etc. The description adds context about fetching details and formatting, and mentions the output format (Markdown), which is useful beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: three sentences plus an example. Every sentence adds value, no fluff. Front-loaded with the main purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given three well-documented parameters, annotations covering safety, and no output schema, the description is complete. It explains the output content (severity, CVSS, etc.) and usage, leaving no gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds an example and clarifies that target and notes are optional. This adds marginal value, but the example is helpful.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool generates a pentest finding in Markdown format for a specific vulnerability. It specifies inputs (CVE/EIP IDs) and outputs (severity, CVSS, etc.), and distinguishes from raw data tools like get_vulnerability.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use (to generate a formatted finding for a report) and provides an example. It does not explicitly state when not to use or compare to alternatives, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get an exploit author's profile with all their exploits. Returns author name, handle, total exploit count, activity start date, and a paginated list of their exploits with CVE context. Use this when asked about a specific researcher like 'show me all exploits by Chocapikk'.
| Name | Required | Description | Default |
|---|---|---|---|
| author_name | Yes | Author name (e.g. 'Chocapikk') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, etc. The description adds meaningful context about the paginated list and returned fields, going beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero waste. Essential information front-loaded: what it does, what it returns, and a usage example.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description explains the return data in sufficient detail for a simple read-only tool. Could mention error handling but overall adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers the single parameter completely with description and constraints. The tool description does not add extra semantic meaning to the parameter beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it gets an author's profile with their exploits, listing specific fields returned and providing an example usage that distinguishes it from siblings like list_authors and search_exploits.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use this when asked about a specific researcher', giving a clear usage context. It does not mention alternatives but implies them through the example.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get details for a specific CWE including full name, description, exploit likelihood, parent CWE, and total vulnerability count. Example: cwe_id='CWE-79' returns details about Cross-Site Scripting.
| Name | Required | Description | Default |
|---|---|---|---|
| cwe_id | Yes | CWE identifier (e.g. 'CWE-79' or '79') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds that it returns specific fields but does not disclose additional behavioral traits (e.g., whether the data is cached, latency implications, or pagination). No contradiction 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first defines purpose and output fields, second provides an example. No wasted words; information is front-loaded and efficiently conveyed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the single parameter and no output schema, the description adequately covers what the tool does and returns. It lists the key fields but doesn't specify the exact return structure (e.g., JSON keys). For a detail retrieval tool, this is mostly sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents the cwe_id parameter with pattern and description. The description adds value by showing an example usage ('cwe_id='CWE-79'') and explaining the parameter in context, which helps the agent understand the expected format beyond the regex.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get', the resource 'CWE', and lists specific fields returned (full name, description, exploit likelihood, parent CWE, total vulnerability count). It also provides an example with 'CWE-79', distinguishing it from sibling tools like list_cwes which returns all CWEs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when needing details of a specific CWE, but does not explicitly state when to use or not use this tool compared to alternatives like list_cwes or get_vulnerability. No exclusionary guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the full AI analysis for a single exploit by its platform ID. Returns classification (working_poc, trojan, suspicious, scanner, stub, writeup), attack type, complexity, reliability, confidence score, authentication requirements, target software, a summary of what the exploit does, prerequisites, MITRE ATT&CK techniques, deception indicators for trojans, and the standalone backdoor-review verdict with operator-risk notes when available. Use this to check if an exploit is safe before reviewing its code. Example: exploit_id=61514 returns a TROJAN warning with deception indicators.
| Name | Required | Description | Default |
|---|---|---|---|
| exploit_id | Yes | Platform exploit ID (the [id=XXXXX] number from results — NOT the EDB number) |
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, indicating a safe, non-destructive, idempotent read operation. The description adds extensive behavioral context by listing all the analysis fields returned (classification, attack type, complexity, reliability, confidence score, authentication requirements, target software, summary, prerequisites, MITRE ATT&CK techniques, deception indicators, backdoor-review verdict, operator-risk notes). This goes well beyond annotations to inform the agent about what the tool reveals.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (3 sentences) and front-loaded: first sentence states purpose, second details return fields, third gives usage guidance and an example. Every sentence is informative and earns its place. No redundant or vague language.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (returns many analysis fields) and absence of output schema, the description is remarkably complete. It enumerates all major return components (classification, attack type, complexity, reliability, confidence score, authentication, target software, summary, prerequisites, MITRE ATT&CK, deception indicators, backdoor-review verdict, operator-risk notes). This fully equips the agent to understand what the tool returns without needing an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema describes the parameter 'exploit_id' with description 'Platform exploit ID (the [id=XXXXX] number from results — NOT the EDB number).' The description adds meaning by clarifying it is the platform exploit ID, not the EDB number, and referencing the result format. With 100% schema coverage and a single parameter, this extra clarification ensures the agent correctly identifies which ID to use.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get the full AI analysis for a single exploit by its platform ID.' It lists the specific analysis components returned (classification, attack type, etc.), distinguishing it from sibling tools like get_exploit_code (which gets code) or get_author (author info). The verb 'Get' and resource 'AI analysis' are specific and unique among siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear use case: 'Use this to check if an exploit is safe before reviewing its code.' This tells the agent when to invoke the tool. It also includes an example (exploit_id=61514) to illustrate. However, it does not explicitly state when not to use it or mention alternative tools for different contexts, slightly lowering the score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve the source code of a specific exploit by its platform ID. IMPORTANT: Use the platform's internal ID shown as [id=XXXXX] in results, NOT the ExploitDB number (EDB-XXXXX). These are different numbering systems. Returns code from the exploit archive. If no file_path is specified, auto-selects the most relevant code file. Use this to analyze exploit mechanics, understand attack techniques, or review PoC code.
| Name | Required | Description | Default |
|---|---|---|---|
| exploit_id | Yes | Platform exploit ID (the [id=XXXXX] number from results — NOT the EDB number) | |
| file_path | No | Relative path inside the exploit archive (optional — auto-selects if omitted). Absolute paths and traversal patterns are rejected. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, non-destructive, idempotent, and open-world hints. Description adds that it returns code from the exploit archive and auto-selects relevant files, which adds context but does not fully compensate for missing output schema or authentication details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, front-loaded with main action and an important warning. Every sentence adds value, no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple retrieval tool without output schema, description adequately covers purpose, ID usage, and optional parameter behavior. Could mention return format but overall complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters. Description reinforces the ID numbering distinction and clarifies behavior when file_path is omitted, enhancing semantics beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool retrieves source code of an exploit by platform ID, with specific use cases like analyzing mechanics or reviewing PoC code. Distinguishes from sibling tools like 'get_exploit_analysis' and 'search_exploits'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides important guidance on using platform ID (id=XXXXX) over EDB-XXXXX and explains auto-selection of code files when file_path is omitted. Lacks explicit when-not-to-use or alternatives, but context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get Nuclei scanner templates and recon dorks for a vulnerability. Returns template metadata, severity, verification status, tags, and ready-to-use Shodan, FOFA, and Google dork queries for target identification. Accepts both CVE-IDs and EIP-IDs. Use this to plan scanning or reconnaissance.
| Name | Required | Description | Default |
|---|---|---|---|
| cve_id | Yes | CVE or EIP identifier (e.g. 'CVE-2024-27198') |
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, covering safety and idempotency. The description adds value by explaining the return content (template metadata, severity, dork queries) but does not disclose additional behavioral traits like rate limits, authentication needs, or error conditions. Given the strong annotation coverage, a score of 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences long, each serving a distinct purpose: statement of main output, list of returned items, and usage guidance. It is front-loaded with the core purpose and contains no redundant or irrelevant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only lookup tool with one required parameter and no output schema, the description is sufficiently complete. It explains what the tool returns (metadata, severity, dorks), specifies the valid input types (CVE/EIP), and provides a usage context. No additional information is necessary for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of the parameter description (the schema's description field already explains the CVE/EIP identifier format). The description repeats 'Accepts both CVE-IDs and EIP-IDs' without adding new meaning or format details. With full schema coverage, the baseline is 3, and the description does not further compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the verb 'Get' and the resource 'Nuclei scanner templates and recon dorks for a vulnerability'. It distinguishes the tool from siblings by detailing the output (template metadata, severity, verification, tags, and dork queries) and explicitly stating its use case for planning scanning or reconnaissance. This differentiates it from related tools like get_exploit_code or get_vulnerability.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states 'Use this to plan scanning or reconnaissance', which gives clear context for when to invoke the tool. However, it does not explicitly list alternatives or when not to use it. The sibling tools provide implicit contrast, but the description itself lacks direct exclusion guidance. A score of 4 reflects strong usage context without explicit negative examples.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get platform-wide statistics from the Exploit Intelligence Platform. Returns total counts of vulnerabilities, exploits, KEV entries, Nuclei templates, vendors, and authors, plus the last data update timestamp.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, destructiveHint, idempotentHint, and openWorldHint. The description adds detail on return values, which is useful context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose and specific return fields. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but description fully lists returned counts and timestamp. Complete for a simple stats tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so description need not add parameter info. Baseline 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'platform-wide statistics', and lists specific returned fields (vulnerabilities, exploits, KEV entries, etc.). It distinguishes from siblings which focus on individual items.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or alternatives stated, but the absence of parameters and aggregate nature imply it is for overall statistics. Sibling names further clarify context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a full intelligence brief for a specific vulnerability. Accepts both CVE-IDs (e.g. CVE-2024-3400) and EIP-IDs (e.g. EIP-2026-12345 for pre-CVE entries). Returns detailed information including CVSS score and vector, EPSS exploitation probability, CISA KEV status, description, affected products, ranked exploits (grouped by Metasploit modules, verified ExploitDB, GitHub PoCs, and trojans), Nuclei scanner templates with recon dorks, alternate identifiers, and references. Exploits are ranked by quality: Metasploit modules first (peer-reviewed), then verified ExploitDB, then GitHub by stars. Trojans are flagged at the bottom.
| Name | Required | Description | Default |
|---|---|---|---|
| cve_id | Yes | CVE or EIP identifier (e.g. 'CVE-2024-3400' or 'EIP-2026-12345') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds significant behavioral context: it accepts two ID formats, returns detailed fields, and explains exploit ranking order. No contradiction 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured paragraph that front-loads the main purpose. Each sentence adds useful information (accepted IDs, return fields, ranking). While detailed, it is not overly verbose for the complexity of the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (single param, no output schema), the description covers return fields comprehensively and explains ranking. It does not describe response format or error handling, but the annotations and schema provide sufficient context for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with a regex pattern. The description adds value by explaining that both CVE-IDs and EIP-IDs are accepted, providing examples and clarifying that EIP-IDs are for pre-CVE entries. This goes beyond the schema's pattern definition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get a full intelligence brief for a specific vulnerability,' specifying a verb and resource. It distinguishes from siblings like search_vulnerabilities (search) and get_exploit_code (code snippets) by focusing on comprehensive intelligence.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: use when you have a CVE/EIP ID and need a full brief. It does not explicitly state when not to use or contrast with alternatives like get_exploit_analysis or search_vulnerabilities, leaving some ambiguity for an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List exploit authors/researchers ranked by exploit count. Returns the top security researchers with their exploit counts and handles. Use this when asked 'who are the top exploit authors?' or 'who writes the most exploits?'
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number (default: 1) | |
| per_page | No | Results per page (1-50, default: 25) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, destructiveHint, idempotentHint, and openWorldHint, covering safety. The description adds behavioral context about ranking by exploit count and returning counts and handles, which is useful beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: first states purpose, second gives usage examples. No filler words or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description specifies the return data (exploit counts, handles, ranking). For a simple listing tool with clear annotations, this is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for page and per_page. The tool description adds no additional parameter information beyond what the schema provides, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists exploit authors/researchers ranked by exploit count, with a specific verb (list) and resource (authors). It differentiates from siblings like get_author (single author) and search_exploits (exploits, not authors).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit example queries ('who are the top exploit authors?') for when to use the tool. Lacks explicit when-not-to-use or alternatives, but the guidance is clear enough for common use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List CWE (Common Weakness Enumeration) categories ranked by vulnerability count. Returns CWE IDs, names, short labels, exploit likelihood, and how many CVEs have that weakness. Use this when asked 'what are the most common vulnerability types?'
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, destructiveHint, idempotentHint, openWorldHint. Description adds specifics about the ranked output fields (CWE IDs, names, labels, likelihood, CVEs), providing additional context, but does not disclose further behavioral traits beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no redundant information. Front-loaded with purpose, followed by return fields and usage hint. Every sentence contributes value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and no output schema, the description fully covers purpose, return data, and usage context. No gaps identified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist; schema coverage is 100% by default. Baseline 4 applies as there are no parameters to document. No additional param info needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action (list), resource (CWE categories), and key differentiators (ranked by vulnerability count). Distinguishes from siblings including get_cwe and search_vulnerabilities by specifying the ranking and common-most use case.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Includes explicit usage example: 'Use this when asked what are the most common vulnerability types?' which provides clear context. Does not include when-not or alternative sibling names, but the provided example sufficiently guides typical use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List products for a specific vendor with vulnerability counts. Use this to discover exact product names for filtering. Product names in the database use CPE conventions (e.g. 'exchange_server' not 'exchange', 'windows_10' not 'windows 10'). Example: vendor='microsoft' returns products like exchange_server, windows_10, office, edge_chromium.
| Name | Required | Description | Default |
|---|---|---|---|
| vendor | Yes | Vendor name (e.g. 'microsoft', 'apache', 'fortinet') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false; the description adds context about vulnerability count returns and CPE naming conventions without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three efficient sentences, front-loaded purpose, no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with one parameter and no output schema, the description covers purpose, usage, naming conventions, and output content completely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline 3; description adds value by explaining CPE conventions and giving a real example, going beyond the schema's brief description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List products for a specific vendor with vulnerability counts' and distinguishes from sibling tools like list_vendors and search_vulnerabilities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says 'Use this to discover exact product names for filtering' and provides a concrete example, though it lacks when-not-to-use guidance or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List software vendors ranked by vulnerability count. Returns the top 200 vendors with their total CVE counts. Use this when asked 'which vendors have the most vulnerabilities?' or to understand the threat landscape by vendor.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, destructiveHint, idempotentHint, and openWorldHint, indicating safe, idempotent behavior. The description adds the specific limit of 200 vendors and the ranking by CVE count, which is useful behavioral context beyond what the annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, with the action and purpose in the first sentence and usage guidance in the second. It is front-loaded with the most important information and contains no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no output schema, the description clearly states what is returned (top 200 vendors with total CVE counts). This is sufficient for a simple list tool with no parameters, making the description complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters, so baseline is 4. The description does not need to add parameter information, and the schema coverage is 100%. No additional semantics required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('List') and resource ('software vendors'), with a clear sorting criterion ('ranked by vulnerability count') and output details (top 200, total CVE counts). It does not explicitly differentiate from sibling tools like list_authors or list_products, but the unique ranking by vulnerability count implies distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool: when asked 'which vendors have the most vulnerabilities?' or to understand the threat landscape. It does not mention when not to use it or provide alternatives, but the guidance is clear and relevant.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up a vulnerability by an alternate identifier such as an ExploitDB ID (EDB-XXXXX) or GitHub Security Advisory ID (GHSA-XXXXX). Returns the matching CVE-ID with basic severity info. Use this when you have an EDB number or GHSA ID and need to find the corresponding CVE.
| Name | Required | Description | Default |
|---|---|---|---|
| alt_id | Yes | Alternate ID (e.g. 'EDB-48537', 'GHSA-jfh8-c2jp-5v3q') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, destructiveHint, idempotentHint, openWorldHint. Description adds that it returns 'basic severity info' but does not conflict with annotations. No extra valuable disclosure beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with action verb 'look up,' no fluff. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given single parameter, rich annotations, and simple output, description covers all needed information. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters with description including examples. Description repeats examples but adds no new semantic depth beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool looks up a vulnerability by an alternate identifier (EDB, GHSA) and returns a CVE-ID with severity. It clearly distinguishes from sibling tools that search or get by CVE.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit context: 'Use this when you have an EDB number or GHSA ID and need to find the corresponding CVE.' No explicit when-not-to-use, but implied by specificity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Browse and filter exploits using STRUCTURED FILTERS ONLY (no free-text query). Use this to filter by source (github, metasploit, exploitdb, nomisec, gitlab, inthewild, vulncheck_xdb, patchapalooza, oscs, poc_monitor), language (python, ruby, etc.), LLM classification (working_poc, trojan, suspicious, scanner, stub, writeup, tool, no_code), author, min stars, code availability, CVE ID, vendor, or product. Also filter by AI analysis: attack_type (RCE, SQLi, XSS, DoS, LPE, auth_bypass, info_leak), complexity (trivial/simple/moderate/complex), reliability (reliable/unreliable/untested/theoretical), requires_auth. NOTE: To search by product name (e.g. 'OpenSSH', 'Apache'), use search_vulnerabilities instead — it has free-text query and get_vulnerability already includes exploits in the response. Examples: source='metasploit' for all Metasploit modules; attack_type='RCE' with reliability='reliable' for weaponizable RCE exploits; cve='CVE-2024-3400' for all exploits targeting a specific CVE; vendor='mitel' for all Mitel exploits.
| Name | Required | Description | Default |
|---|---|---|---|
| source | No | Filter by source | |
| language | No | Filter by language: python, ruby, go, c, etc. | |
| llm_classification | No | Filter by LLM classification | |
| attack_type | No | Filter by attack type from AI analysis (case-insensitive on input; canonical casing returned) | |
| complexity | No | Filter by exploit complexity | |
| reliability | No | Filter by exploit reliability | |
| requires_auth | No | Filter by whether exploit requires authentication | |
| author | No | Filter by author name | |
| min_stars | No | Minimum GitHub stars | |
| has_code | No | Only exploits with downloadable code | |
| cve | No | Filter by CVE ID (e.g. 'CVE-2024-3400') — returns all exploits for that CVE | |
| vendor | No | Filter by vendor name (e.g. 'mitel', 'fortinet') — returns exploits for all CVEs affecting that vendor | |
| product | No | Filter by product name (e.g. 'micollab', 'pan-os') | |
| sort | No | Sort order | |
| page | No | Page number (default: 1) | |
| per_page | No | Results per page (1-25, default: 10) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this as a safe, read-only, idempotent operation. The description adds the constraint of structured filters only but does not disclose much beyond what annotations and schema cover, such as return format or pagination details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with the primary constraint first, then filter categories, a note about alternatives, and examples. Some redundancy remains (e.g., listing enum values both in description and schema), but overall efficient for the content load.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers input semantics thoroughly given the complexity (16 parameters) and lack of output schema. However, it does not describe what the response contains (e.g., fields, pagination behavior), which would be helpful for a tool with no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters with individual descriptions, so baseline is 3. The description adds value by grouping filters into categories, giving composite usage examples (e.g., attack_type='RCE' with reliability='reliable'), and explaining the alternative for product search.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool browses and filters exploits using structured filters only. Distinguishes from sibling search_vulnerabilities by explicitly noting the lack of free-text query and directing product name searches to the alternative tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use and when not to use, including a direct reference to search_vulnerabilities for product name searches. Provides multiple concrete examples demonstrating filter combinations for typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the Exploit Intelligence Platform for vulnerabilities (CVEs). Returns a list of matching CVEs with CVSS scores, EPSS exploitation probability, exploit counts, CISA KEV status, VulnCheck KEV, InTheWild.io exploitation signals, and ransomware attribution. Supports full-text search, severity/vendor/product/ecosystem/CWE filters, CVSS/EPSS thresholds, plus any_exploited and ransomware filters. When sort is omitted, the API may automatically prefer newest exploitation, exploit, or nuclei-template activity based on the filters you set. Examples: query='apache httpd' with has_exploits=true; vendor='fortinet' with severity='critical' and is_kev=true sorted by epss_desc; any_exploited=true with ransomware=true for ransomware-linked CVEs; cwe='89' with min_cvss=9 for critical SQL injection CVEs.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | Search keywords (e.g. 'apache httpd', 'log4j'). Optional if filters are provided. | |
| severity | No | Filter by severity level | |
| has_exploits | No | Only return CVEs with public exploit code | |
| is_kev | No | Only return CISA Known Exploited Vulnerabilities | |
| any_exploited | No | Only return CVEs exploited in the wild (CISA KEV + VulnCheck KEV + InTheWild.io) | |
| ransomware | No | Only return CVEs with confirmed ransomware campaign use | |
| has_nuclei | No | Only return CVEs with Nuclei scanner templates | |
| vendor | No | Filter by vendor name (e.g. 'microsoft', 'fortinet') | |
| product | No | Filter by product name (e.g. 'exchange', 'pan-os') | |
| ecosystem | No | Filter by package ecosystem | |
| cwe | No | Filter by CWE ID (e.g. '79' or 'CWE-79') | |
| min_cvss | No | Minimum CVSS v3 score (0-10) | |
| min_score | No | Minimum score for the selected score_version (0-10) | |
| score_version | No | Score family for min_score / score_desc | |
| min_epss | No | Minimum EPSS score (0-1) | |
| year | No | Filter by CVE year (e.g. 2024) | |
| date_from | No | Start date for CVE publication (YYYY-MM-DD) | |
| date_to | No | End date for CVE publication (YYYY-MM-DD) | |
| sort | No | Sort order. Aliases are normalized to the current server schema. | |
| page | No | Page number (default: 1) | |
| per_page | No | Results per page (1-25, default: 10) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description details the return fields (CVSS, EPSS, etc.) and sorting behavior, adding value beyond annotations. No contradictions with readOnlyHint, destructiveHint, or idempotentHint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single well-structured paragraph that front-loads the main purpose, then lists features and examples. Every sentence serves a purpose, with no wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 21 parameters and no output schema, the description covers the key return fields and behavior. It could be more complete by specifying response structure (e.g., pagination details), but it provides sufficient context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all 21 parameters. The description adds concrete examples and clarifies sorting behavior, going beyond the schema definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches for vulnerabilities (CVEs) and returns a list with specific fields. It distinguishes from siblings like search_exploits by focusing on vulnerabilities, and provides explicit examples of search scenarios.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes multiple usage examples and explains sorting behavior when omitted. While it does not explicitly contrast with sibling tools, the examples implicitly guide appropriate use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool purposes are mostly distinct, with slight overlap between search_exploits and search_vulnerabilities, but descriptions clarify the difference. Each tool targets a specific aspect of exploit intelligence, reducing ambiguity.
All tool names follow a consistent verb_noun snake_case pattern (e.g., get_vulnerability, search_exploits, list_authors). No mixing of conventions occurs.
17 tools is slightly above the ideal range but still reasonable for a comprehensive exploit intelligence platform. Each tool serves a distinct function without being excessive.
The tool set covers major intelligence operations: search, retrieve, analyze, format, and list. Missing update/delete is expected for a read-only platform. Minor gaps like direct comparison tools are workable.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Real-time CVE, exploit, and vulnerability intelligence for AI assistants (350K+ CVEs, 115K+ PoCs)
Threat intel + your scans/findings/Shield posture. CVE, EPSS, KEV, package vuln lookup, DAST.
CVE lookups (NVD) and dependency-manifest audits (OSV) for AI agents. No API keys.
CVE search, vulnerability database, EPSS exploit prediction, KEV, IP reputation & threat feed.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/exploitintel/eip-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
