Loading ToolBench
Open-source DNS & email security scanner providing comprehensive security checks for DNS records (SPF, DMARC, DKIM, DNSSEC, SSL/TLS, MTA-STS, NS, CAA, MX, BIMI, TLS-RPT) and subdomain takeover detection.
Scoring was not performed
Output schemas not documented. Tools return structured data (CheckResult, Finding objects per src/handlers/tool-formatters.ts) but the MCP tool definitions in tool-schemas.ts do not include outputSchema declarations. LLMs cannot plan downstream operations or extract specific fields without knowing the return structure.
Error handling descriptions lack recovery guidance. Most tool descriptions do not explain what to do if validation fails (e.g., domain invalid, DNS timeout, no records found). Per pattern:recovery-guide, error responses should tell the LLM what to do next. Descriptions should hint at fallback strategies or what to try if a check fails.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 24 | 2025-06-18+ | v2 |
| 2026-03-09 | D | 58 | - | v1 |
scan_domain description lacks clarity on what 'overall security score and grade' means and how it differs from individual checks. Users/LLMs need to understand the scoring methodology. Description should explain: Is it a weighted average? What ranges map to A/B/C grades? Does it include lookalike detection?
explain_finding parameter 'details' is optional but its role is underspecified. Description says 'Optional details from the check result' but does not explain: What structure does it expect? How does it affect the explanation? Can the LLM pass any string or only specific formats? This ambiguity may lead to suboptimal explanations if LLMs omit the field or pass poorly formatted data.
check_dkim selector parameter validation is strict (src/handlers/tool-args.ts) but description lacks guidance. Description says 'If omitted, common selectors are probed' but does not list which selectors are probed or explain what a 'valid selector' is (alphanumeric + hyphens, max 63 chars per DNS label). LLMs may pass invalid selectors and receive confusing errors.
explain_finding status enum is broad but lacks guidance on when to use each value. Description lists valid enum values (pass, fail, warning, critical, high, medium, low, info) but does not explain the mapping between check failures and severity levels. E.g., when should an LLM call this with 'critical' vs 'high'? Ambiguity may lead to wrong severity selections.