Loading ToolBench
The server defines 13 DNS management tools with explicit schemas and descriptions visible in src/index.ts. Naming follows consistent verb_noun patterns (create_*, list_*, delete_*, update_*). Most tools have descriptions (10-100+ chars) and input schemas with property-level documentation. However, multiple critical gaps emerge: (1) Output schemas are completely undocumented, no tool declares what it returns, forcing LLMs to guess field names and structure; (2) Error handling is absent, no guidance on retryability, recovery actions, or invalid input scenarios; (3) Parameter descriptions lack actionable constraints (e.g., no regex, min/max, or enum definitions for string fields like 'type' which accepts A, AAAA, CNAME, MX, TXT, SRV, NS, CAA, SOA); (4) Sensitive operations (delete_dns_records, all create_* tools) have no confirmation mechanism or dry-run option; (5) The delete_dns_records tool has an overly complex schema with multiple optional fields (value, cname, address, exchange, preference) that create ambiguity, LLMs will struggle to know which field to pass for each record type. Baseline: 100% of A+ tools document return types; 100% of A+ tool params have descriptions with constraints. This server has 0% documented return types and many params lack constraint guidance.
Create an A record (IPv4 address) for a domain
Create an AAAA record (IPv6 address) for a domain
Create a CAA record (Certification Authority Authorization) for a domain
Create a CNAME record (canonical name/alias) for a domain
Create a new DNS record for a domain
Create an MX record (mail exchange) for a domain
Create an NS record (nameserver) for a domain
No output schemas documented for any tool. LLMs cannot plan downstream calls or extract fields without knowing return structure. Critical for agent composition.
Parameter 'type' in create_dns_record, update_dns_records, and delete_dns_records accepts free-form strings but should be an enum (A, AAAA, CNAME, MX, TXT, SRV, NS, CAA, SOA). Enums are self-documenting and prevent hallucinated invalid values.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 61 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 39 | - | v1 |
Create an SOA record (Start of Authority) for a domain
Create an SRV record (service) for a domain
Create a TXT record for a domain
Delete DNS records for a domain. Requires full record data matching the existing record.
List all DNS records for a domain
Update DNS records for a domain
delete_dns_records schema is ambiguous: multiple optional fields (value, cname, address, exchange, preference) with unclear rules for which apply to each record type. LLMs will guess wrong. Should use type-specific nested schemas or clear conditional documentation.
No error handling guidance. Tools lack descriptions of what happens on invalid input (e.g., invalid domain, duplicate record, permission denied). No recovery hints for LLMs.
Destructive operations (delete_dns_records, all create/update tools) lack confirmation mechanism or dry-run support. Agents have no safety net before irreversible changes.
Parameter 'domain' appears in all tools but lacks constraint documentation (e.g., valid domain format, max length, allowed characters). LLMs may pass invalid values.
TTL parameter descriptions note '(optional)' with default 3600, but schema does not show this in the 'required' array. Inconsistent signaling to LLMs about whether TTL is required.