Loading ToolBench
DNSDumpster MCP Server for querying DNS information
This server has two tools with adequate naming and documented schemas, but critical gaps in parameter descriptions and output documentation prevent a higher score. Both tools start with action verbs (query_, get_) which is positive. However, parameter descriptions are minimal ('The domain name to query (e.g., example.com)' is the only parameter doc), and output schemas are completely undocumented, the tools return JSON strings with no documented structure. Error handling exists but lacks guidance for LLM recovery. The codebase shows thoughtful internal engineering (rate limiting, caching, retries, domain validation) but this value is not exposed in the tool contract. Without documented output schemas and richer parameter/error descriptions, LLMs cannot reliably understand what these tools return or how to handle failures.
Get A records for a domain.
Query DNSDumpster for all DNS records related to a domain.
No output schemas documented. Both tools return JSON strings via json.dumps() with no documentation of the returned fields, structure, or data types. LLMs cannot parse or reason about the response structure.
Incomplete parameter descriptions. Both tools accept only 'domain' parameter with minimal description. No guidance on format constraints, validation rules, or examples of valid/invalid inputs for LLM reference.
Error responses lack recovery guidance. Tools return bare error JSON (e.g., '{"error": "API key not configured..."}') without actionable next steps for the LLM. No error categorization (retryable vs. fatal) or suggestions for remediation.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 44 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 0 | - | v1 |
No distinction between query_domain and get_a_records in documentation. query_domain claims to return 'all DNS records', but get_a_records specifically retrieves A records. The difference in tool responsibilities is not evident in descriptions, risking LLM confusion about which to use.
Tool descriptions reference example values ('example.com') which LLMs tend to reuse literally in subsequent calls, violating the constraint-first pattern. Should replace with format specification or enum.