Loading ToolBench
A modular MCP server for penetration testing tools and utilities
Server has 8 tools with explicit schema definitions visible in pentest/tools.py. All tools have basic descriptions and well-formed JSON Schema inputs. However, there are notable gaps in parameter descriptions, no documented output schemas, no error handling guidance, no pagination support for tools that may return large result sets, and missing tool annotations. Tool names follow verb_noun conventions appropriately (nmap_scan, dns_lookup, whois_lookup, nikto_scan, dirb_scan, gobuster_scan, sublist3r_enum, zap_baseline). Descriptions are present but often generic (120-180 chars on average) without explaining WHEN to use each tool vs similar alternatives, dependency chains, or what fields agents should expect in responses. Parameters have types and reasonable defaults but lack constraint documentation (e.g., valid values for scan_type, timing templates, record_type enums are mentioned in descriptions but not enforced in schema as enums). No documentation of output structure, no pagination parameters, and no error recovery guidance.
Perform directory and file brute forcing using DIRB
Perform DNS lookups for various record types
Perform directory/DNS brute forcing using Gobuster
Perform web vulnerability scanning using Nikto
Perform comprehensive port scanning using Nmap
Enumerate subdomains using Sublist3r with multiple search engines
Perform WHOIS lookup for domain information
No output schema documented for any tool. LLMs cannot plan downstream operations or extract required fields without knowing what structure each tool returns. This violates pattern:tool and mxe:response-field-naming.
Parameter constraints mentioned in descriptions but not enforced in schema. For example, scan_type ('quick', 'full', 'stealth', 'udp', 'version', 'os'), record_type ('A', 'AAAA', 'MX', 'NS', 'TXT', 'CNAME', 'SOA'), timing ('paranoid', 'sneaky', 'polite', 'normal', 'aggressive', 'insane'), and level ('Low', 'Medium', 'High') should be declared as enums in the inputSchema, not just in descriptions. LLMs cannot reliably parse and validate free-form text constraints.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 52 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 38 | - | v1 |
Perform OWASP ZAP baseline security scan
No pagination support or result limits documented. Tools like gobuster_scan, sublist3r_enum, and dirb_scan may return hundreds of results. Without limit/offset parameters and a documented maximum result count, agents risk context window exhaustion and degraded reasoning.
Descriptions lack WHEN-to-use guidance and distinction from similar tools. For example, dirb_scan and gobuster_scan both perform directory brute forcing, but the descriptions do not clarify when to prefer one over the other. Agents will waste reasoning cycles or pick wrong tools. Similarly, nmap_scan vs nikto_scan (port discovery vs web vulnerability) should be explicitly differentiated.
No error handling or recovery guidance. Tools do not document what happens on common failures (e.g., target unreachable, invalid hostname, scan timeout, permission denied). Pattern:recovery-guide requires error responses to tell the LLM what to do next.
Tool names do not distinguish sublist3r from other enumeration tools. 'sublist3r_enum' is acceptable but could be more consistent with the verb_noun pattern used elsewhere. Consider 'enumerate_subdomains' for clarity and consistency with 'nmap_scan', 'dns_lookup'.
zap_baseline tool is commented out in get_all_tools() (line marked 'Temporarily disabled'). If the tool is not fully implemented, it should be removed from the tool registry to avoid misleading agents. If it is implemented, uncomment and test it.
Parameter descriptions do not include format constraints or examples as guidance. For instance, 'target' in nmap_scan says 'Target IP address, hostname, or CIDR range' but does not specify the format for CIDR ranges (e.g., '192.168.1.0/24'). This forces LLMs to guess and risks malformed inputs.