Loading ToolBench
Security audit toolkit for MCP marketplaces with domain, web, and repository checks including DNS/TLS analysis, HTTP headers inspection, and GitHub security features assessment
This MCP server has 3 tools with basic definitions and good parameter descriptions, but significant gaps in naming clarity, output schema documentation, and error handling guidance. Tool names (check_domain, check_web, check_repo) use imperative verbs appropriately but are generic and don't clearly distinguish their scopes. Parameters are documented with types and descriptions, but output schemas are not visible in the provided code, and error responses lack actionable guidance for recovery. The security audit domain is narrow (3 tools, all READ_ONLY), but implementations show defensive programming (subprocess timeouts, command injection prevention). Average parameter documentation is solid (each tool has 1-2 params with type + description), but the lack of output schema documentation and minimal error handling guidance pull the score below 60.
Perform all domain checks including DNS records, TLS certificate validation, and provider detection
Perform repository checks including security files detection, organization verification, activity metrics, and GitHub security features assessment
Perform web checks including HTTP headers analysis, security headers validation, path probing, content analysis, tracker detection, and mixed content scanning
Output schemas not documented. Tools return structured objects internally (DomainResult, TLSCertificate, DNSRecords dataclasses visible in domain.py) but the tool definitions in __init__.py do not expose what fields the LLM receives. LLMs cannot plan downstream calls or extract specific data without knowing the response shape.
Generic tool names with unclear scope boundaries. 'check_domain' could mean DNS validation, reputation check, availability, or ownership verification. 'check_web' bundles HTTP headers, security headers, trackers, and mixed content, multiple concerns that should hint at sub-tools or narrower names like 'audit_domain_dns', 'audit_web_headers', 'audit_web_security'. LLMs conflate similar names when making tool selection decisions.
No error handling guidance. Code shows subprocess timeouts (124 exit code, 'timeout' message) and missing dependencies (127 exit code), but tool definitions do not document what errors are possible, whether they are retryable, or what the LLM should do (e.g., 'If dig command not found, ensure bind-utils is installed'). A bare timeout or FileNotFoundError forces the LLM to guess recovery steps.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 52 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 43 | - | v1 |
check_repo accepts optional 'token' parameter as string|null, but no guidance on format, scope, or consequences. Should clarify: 'GitHub API token (optional; defaults to public-only access; provide a personal access token for private repo checks or higher rate limits).' Current description is incomplete.
No pagination or result limits documented. check_domain returns DNS records including up to 10 TXT records (cap visible in _check_dns); check_web likely returns large lists of headers and trackers; check_repo scans organization, activity, security features. Tools should declare maximum result counts and offer pagination if unbounded (e.g., 'Returns up to 50 GitHub repos. Use page/offset for more.'). Without this, large responses could blow context windows.