MCP server for searching Exploit-DB using searchsploit
The server has 6 tools with complete input schemas and basic descriptions. Naming follows verb-noun convention (search_exploits, get_exploit_path, etc.). However, descriptions are brief and lack context about when to use each tool relative to others. Parameter descriptions are present but sparse, many lack format guidance or constraints. Output schemas are undocumented; LLMs cannot predict the structure of results. Error handling is minimal: the code returns raw stderr and stdout without actionable recovery guidance. The tool set is reasonably composed (single responsibility per tool), but descriptions do not mention idempotency, side effects, or prerequisites. Baseline: production tools average 194 chars in tool descriptions and 72 chars in parameter descriptions; this server averages ~80 chars for tool descriptions and ~50 chars for parameters.
Retrieve and display the full content of an exploit by its EDB-ID.
Get the full local filesystem path to an exploit by its EDB-ID.
Copy an exploit to a specified directory by its EDB-ID.
Search for exploits by CVE (Common Vulnerabilities and Exposures) identifier.
Search for exploits in Exploit-DB using search terms. Returns a formatted list of matching exploits with titles and paths.
Update the local Exploit-DB database to the latest version.
Output schemas undocumented. LLMs cannot predict result structure. Tools return raw searchsploit output (formatted text) but this is not formally declared. Agents cannot plan follow-up operations (e.g., extracting EDB-IDs from search results to feed into get_exploit_content).
Error handling lacks recovery guidance. The code returns raw stderr and stdout when searchsploit fails (e.g., 'searchsploit command not found') but does not guide the LLM on corrective action. A missing error should suggest: 'Install exploitdb via: pip install exploitdb' or 'Update your exploitdb database with update_exploitdb tool.'
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-21 | D | 54 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 49 | - | v1 |
Descriptions lack context and dependency hints. 'Search for exploits in Exploit-DB' does not explain WHEN to use search_exploits vs search_cve, or that search_exploits returns paths which feed into get_exploit_content. Baseline: production tools average 194 chars and include 'Call this first to...' or 'Returns X, which you can pass to Y.'
Destructive/side-effect operations not annotated. 'mirror_exploit' copies files to a destination (WRITE risk) and 'update_exploitdb' modifies local state, but tool descriptions do not warn the LLM of consequences. Baseline: production tools state 'This will modify X' or 'Cannot be undone.' Tool annotations (destructiveHint) are not used.
Parameter format/constraint guidance missing. 'cve' parameter in search_cve accepts both '2021-44228' and 'CVE-2021-44228' but this is not documented in the parameter description. The code strips the prefix, but LLMs should not have to guess. The description should read: 'CVE identifier (format: YYYY-NNNNN or CVE-YYYY-NNNNN; both are accepted).'
No pagination or result limits documented. search_exploits and search_cve may return very large result sets that exhaust context. Baseline production tools cap results at 20-50 items and include pagination guidance. No limit is declared in descriptions or schemas.
Idempotency not declared. If an LLM retries 'mirror_exploit' after a timeout, will it create a duplicate copy or overwrite? If it retries 'update_exploitdb', will it re-download the entire database? Descriptions should state: 'Idempotent: safe to retry' or 'Non-idempotent: may cause duplicate side effects.'