Loading ToolBench
Comprehensive DNS query tools for domain information. Provides tools to query all DNS record types and perform DNS lookups
The DNS MCP Server has fundamental definition quality issues that prevent production use. While all 6 tools have basic descriptions and simple parameter schemas, the descriptions are minimal (10-60 characters), lack actionability, and do not explain when to use each tool or what the outputs contain. Parameter descriptions are single-line and bare. No output schemas are documented. The test client (mcp-test-client.py) demonstrates tool invocation but does not show actual server implementation, parameter validation, or error handling patterns. The tool names follow verb_noun convention (query_*, check_*, whois_*) which is acceptable, but descriptions fail to meet the 50-200 character baseline for LLM-optimized tool docs (rubric baseline: avg 194 chars). No schemas for output structures are visible. Error handling guidance is absent.
Check DNSSEC status and validation for a domain
Query A records (IPv4 addresses) for a domain
Query AAAA records (IPv6 addresses) for a domain
Query CAA records (Certificate Authority Authorization) for a domain
Query CNAME records (canonical name/alias) for a domain
Query MX records (mail exchange servers) for a domain
Query NS records (nameservers) for a domain
Query PTR record (reverse DNS lookup) for an IP address
Tool descriptions are too short and lack actionability. Average length ~30 chars vs. production baseline of 194 chars. Descriptions do not explain WHEN to use each tool, WHAT it returns, or how it differs from similar tools (e.g., query_a_record vs query_mx_record vs query_txt_record). LLMs cannot reliably select the right tool with such sparse descriptions.
No output schemas documented. The test client shows that tools return JSON results (e.g., A record results, DNSSEC data, WHOIS records), but the server does not expose output field names, types, or structures to the MCP client. This prevents downstream tool composition and forces LLMs to infer response formats.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 6 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 34 | - | v1 |
Query SOA record (Start of Authority) for a domain
Query SRV records (service location) for a domain
Query TXT records for a domain (includes SPF, DKIM, DMARC, verification records)
Perform WHOIS-style lookup to get domain registration information
Parameter descriptions are missing or trivial. The input schema shows 'domain' and 'ip_address' as parameters, but descriptions are either absent or single-word (e.g., 'The domain name to query'). No constraints documented (e.g., valid domain format, IPv4 vs IPv6 for IP queries). Rubric requires 'every parameter needs a non-empty description explaining what it controls'.
No error handling guidance or recovery patterns visible. Test client does not show error cases, fallback behavior, or how to interpret DNS lookup failures (e.g., NXDOMAIN, SERVFAIL, timeout). Rubric requires: 'Error responses must tell the LLM what to do next.' Agents cannot recover from failures without guidance.
Tool overlap and naming ambiguity. Six DNS query tools (query_a_record, query_mx_record, query_txt_record, query_ptr_record) and check_dnssec operate on similar domains/IPs with overlapping purposes. Descriptions do not explain the distinction or guide when to use each (e.g., use query_txt_record for SPF/DKIM/DMARC validation, not check_dnssec). Rubric: 'When multiple tools operate on the same resource, their names must make the distinction obvious.'
No validation rules or constraints in descriptions. Rubric requires: 'Describe the expected format, range, and allowed values directly in the parameter description.' For example, are international domain names (IDNs) supported? Does query_ptr_record accept only IPv4, or IPv6 too? Are WHOIS lookups limited to certain TLDs? No constraints are documented.