Loading ToolBench
MCP server for domain security checks — SPF, DKIM, DMARC, MTA-STS, TLS certificates and protocol support, and HTTP security headers.
Three tools with clear, domain-specific descriptions (150-250 chars each) and well-defined input schemas. Naming follows verb_noun pattern (scan_domain, check_tls, check_spf). However, output schemas are not formally documented, only plain-text formatting logic visible in code. No error handling guidance, no parameter validation rules stated, no enum constraints. Descriptions are good but lack WHEN-to-use context and dependency hints. No tool annotations (readOnlyHint present in metadata but not in schema). Average across tools: 62.
Analyse a domain's SPF record: whether it exists, what it says, how many DNS lookups it requires (and whether that exceeds the RFC 7208 limit of 10), which services are authorised to send mail, and any issues or warnings.
Inspect a domain's TLS configuration in detail: certificate validity and expiry, issuer, key strength, the full certificate chain including whether intermediates are missing, and which TLS protocol versions the server actually accepts. Use this for certificate problems, expiry checks, "which TLS versions are enabled", PCI DSS protocol questions, or when a site works in browsers but fails in curl or other clients.
Check a domain's full security posture: SPF, DKIM, DMARC and MTA-STS email authentication, TLS certificate and protocol support, and HTTP security headers. Use this whenever asked whether a domain is configured securely, whether it can be spoofed, or to review a domain's email or web security. Returns live results from public DNS records and TLS handshakes.
Output schemas not formally documented. Code shows plain-text formatting (formatScan, formatSsl, formatSpf) but no JSON Schema definition of response structure. LLMs cannot plan downstream tool calls or extract structured data.
No error handling guidance in descriptions. Tools call external API (posturecheck.io) with 30s timeout and rate-limit handling, but descriptions do not explain what happens on failure, whether errors are retryable, or what the LLM should do next.
Parameter descriptions lack format/constraint details. 'domain' param says 'e.g. example.com' but does not state: required format, length limits, allowed characters, or what happens if invalid (e.g. 'example.com:8080' or 'https://example.com').
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 55 | 2026-07-28+ | v2 |
Descriptions lack WHEN-to-use context and dependency hints. E.g., scan_domain says 'Use this whenever asked whether a domain is configured securely' but does not explain: Is this for email security only? Web security? Both? When should I call check_tls vs scan_domain?
No tool annotations in schema. Risk metadata (READ_ONLY) is present in metadata but not exposed as readOnlyHint in the tool schema. LLMs cannot infer idempotency or destructiveness from the definition alone.