Loading ToolBench
Model Context Protocol server for DNS and email security scanning using basicsec
BasicSec has 7 tools with complete input schemas and descriptions, but quality is uneven. All tools are READ_ONLY and well-intentioned, but descriptions are generic (avg ~120 chars, below the 194-char baseline for A+ tools). Parameter descriptions exist but lack actionable constraints (no enums, ranges, or format specs). Error handling returns raw exceptions rather than recovery guidance. No output schema documentation. Tool naming is clear (verb_noun pattern), but composition shows redundancy: passive_scan, active_scan, scan_multiple_domains, and quick_domain_check overlap significantly, agents will struggle to choose between them. Missing idempotency guarantees and pagination for batch operations.
Perform an active email security scan that includes both DNS checks and SMTP server connectivity tests.
Get and validate DMARC record for a domain.
Get MX records for a domain.
Get and validate SPF record for a domain.
Perform a passive email security scan that only checks DNS records without making SMTP connections.
Perform very quick checks on multiple domains to avoid MCP timeouts. Optimized for speed with minimal DNS lookups.
Scan multiple domains with specified scan type. Optimized for faster execution to avoid MCP timeouts.
Tool composition redundancy: passive_scan, active_scan, scan_multiple_domains, and quick_domain_check all perform overlapping security scans. LLMs will struggle to choose between them. Consolidate into a single scan tool with a 'mode' enum (passive|active|quick) and 'domains' array parameter.
Parameter descriptions lack actionable constraints. 'dns_timeout' and 'smtp_timeout' have no min/max bounds; 'smtp_ports' has no format spec; 'check_types' in quick_domain_check has no enum constraint. LLMs will pass invalid values (negative timeouts, out-of-range ports). Add ranges and enums to all numeric and choice parameters.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 54 | <=2025-11-25 | v2 |
Error handling returns raw exception strings ('error': str(e)) without recovery guidance. When a scan fails, the LLM has no actionable next step. Implement pattern:recovery-guide: categorize errors (retryable vs user-fixable), include the invalid value and constraint violated, and suggest corrective actions.
Output schema not documented. Tool descriptions do not specify what fields are returned (e.g., does passive_scan return 'mx_records', 'spf_valid', 'dmarc_policy'?). LLMs cannot plan downstream calls or extract the right data. Add explicit return type documentation to each tool.
Tool descriptions are generic and under-optimized for LLM selection. 'Get MX records for a domain' (50 chars) lacks context on when to use it vs active_scan. Descriptions should be 50 - 200 chars and answer: What does it do? When should the LLM call it? What does it return? Current descriptions average ~120 chars but lack these elements.