Loading ToolBench
External reconnaissance server for network and domain enumeration
This server has moderate definition issues that would require significant refinement for production use. Tool names are action-oriented (setup_prompt, dns_lookup, etc.), which is positive. However, parameter descriptions are minimal or missing context, output schemas are inferred rather than explicitly documented, and error handling is minimal. The tool descriptions are generally adequate (60-120 chars), but parameters lack the contextual detail needed for reliable LLM invocation. The setup_prompt tool is atypical, it returns a plain string prompt rather than performing reconnaissance, which violates single-responsibility principle.
Check for email security measures like SPF, DMARC and DKIM
Perform DNS lookups for A, MX, NS, TXT, and SOA records
Scan for open ports on a target IP or domain
setup external reconnaissance by domain name
Perform a WHOIS lookup on a domain
Output schemas not formally documented. Tools return Dict[str, Any] with inferred field structure. LLMs cannot predict conditional fields (e.g., spf_error only on DMARC lookup failure), forcing unreliable parsing.
Parameter descriptions are minimal and lack context. 'domain' appears in three tools with identical trivial descriptions; 'target' in scan_ports doesn't clarify IP vs FQDN resolution behavior; 'ports' default is hidden in function signature, not schema.
setup_prompt violates single-responsibility principle (pattern:tool). It returns a static prompt string rather than performing reconnaissance. This should either be removed, merged into server initialization, or restructured to actually enumerate the domain.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 49 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 42 | - | v1 |
Error handling is minimal. Exceptions are caught and converted to error strings in responses (e.g., 'Error: {str(e)}'), but LLMs receive no guidance on whether errors are retryable, what to do next, or what input caused the failure. Violates pattern:recovery-guide.
No input validation or constraint documentation. scan_ports accepts arbitrary port lists; whois_lookup calls external subprocess without timeout or sanitization; dns_lookup does not validate domain format. LLMs cannot predict invalid inputs.
Port scan timeout is hardcoded to 1 second (sock.settimeout(1)). No configuration option or documentation about expected latency. External scans may fail silently on slow networks.
whois_lookup relies on the external 'whois' command-line tool. If not installed, the tool fails silently. No error message guides the user or LLM to install the dependency. Server readiness is not self-contained.
Tool descriptions do not clarify composition or workflow. Users don't know which tool to call first, or in what sequence, to accomplish reconnaissance. Missing dependency hints like 'Call dns_lookup first to resolve IPs before scan_ports'.
No result limits documented. scan_ports could return many open ports; dns_lookup could return very long TXT record lists. No pagination, no cap, risk of context window exhaustion.