Loading ToolBench
Comprehensive DNS reconnaissance tools for threat intelligence
The server provides 7 well-named tools with clear action verbs (dns_query, dns_reverse_lookup, dns_bulk_query, etc.) following verb_noun conventions. However, definitions suffer from critical gaps: descriptions are present but relatively terse (10-50 characters on average), parameter descriptions lack depth and constraint specification, and output schemas are not explicitly documented in the code. Tools 1-3 show complete input schemas with typed parameters and sensible defaults, but parameters like 'resolver_type' lack enum constraints despite accepting specific values (system, public, google, cloudflare, quad9, opendns). Error handling exists in implementation but is not reflected in tool descriptions. No error guidance is provided to help LLMs understand what recovery actions to take. Output structure is mentioned in code (format_bulk_response, format_error_response) but schemas are not visible or documented. The server lacks documentation of output fields, pagination guidance, and dependency hints between tools.
Perform concurrent bulk DNS queries for multiple domains
Perform concurrent bulk reverse DNS lookups for multiple IP addresses
Check DNS propagation across multiple resolvers to detect inconsistencies
Async DNS query for specific domain and record type
Query all DNS record types concurrently for comprehensive domain profiling
Async reverse DNS lookup (PTR) for an IP address
Check if domain has wildcard DNS entries by testing random subdomains
Missing enum constraints for categorical parameters. 'resolver_type' accepts specific values (system, public, google, cloudflare, quad9, opendns) but is defined as a free-form string with default='system'. LLMs will hallucinate invalid resolver types without enum constraints.
Output schemas not documented. Tools return dict/structured responses via format_bulk_response and format_error_response, but the field structure, types, and presence of critical fields (success count, failure details, per-item results) are not visible in tool definitions. LLMs cannot plan downstream operations without knowing output shape.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 49 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 43 | - | v1 |
Terse descriptions lack LLM-actionable guidance. 'Async DNS query for specific domain and record type' (48 chars) is functional but does not state WHEN to use this tool vs dns_query_all, what edge cases it handles, or what the response structure contains. Descriptions should be 50-200 characters with usage context.
Parameter descriptions lack constraint documentation. 'timeout' is described as 'Query timeout in seconds' (29 chars) without stating valid range (minimum 1, maximum 600?, sensible default 10). 'test_count' in dns_wildcard_check lacks any description of valid range or what happens if null/unset.
No error recovery guidance in tool descriptions. Error handling exists in code (format_error_response) but tool descriptions do not hint at what errors may occur or how LLMs should respond (retry, check input, request user clarification, etc.). LLMs have no recovery path when a tool fails.
Bulk tool results structure unclear. dns_bulk_query and dns_bulk_reverse_lookup return dict with 'results' array, but it is not stated whether per-item failures are captured, how to distinguish success from partial success, or whether the response includes success_count and failed_count. Without documented output schema, LLMs cannot reliably interpret responses.
Parameter relationships undocumented. In dns_propagation_check, 'resolvers' param defaults to None (uses defaults), but it is not explained what the 'defaults' are or when an LLM should pass a custom resolvers dict. In dns_wildcard_check, test_count defaults to None and 'uses default from config' but the default value is not stated.
No pagination or result limiting guidance. dns_bulk_query and dns_bulk_reverse_lookup accept arrays of domains/IPs but do not document whether there are practical limits (e.g., max 1000 domains per call) or recommend batch sizes. LLMs may pass unbounded lists.