Loading ToolBench
AI-powered security tools via any MCP client. Provides security tools including penetration testing, reconnaissance, and vulnerability scanning against authorised targets. Supports passive reconnaissance (free tier) and web application scanning (pro+).
CyberSorted MCP provides 2 security-focused tools with HTTP/FastMCP transport. Both tools have clear, detailed descriptions (195 - 265 chars each) explaining what they do, when to use them, and expected outcomes. Input parameters are documented with descriptions and appropriate defaults. However, output schemas are not visible in the provided source code, the tool implementations reference abstract functions (recon_passive, scan_web_application) whose return contracts are not shown. Parameter validation and error handling appear minimal: scan_level accepts an arbitrary string and validates it only inside the function (ValueError catch), but the error response lacks guidance for recovery. The server lacks structured error reporting and tool annotations (readOnlyHint, etc.). Despite good naming conventions (verb_noun: recon_passive_tool, scan_web_application_tool) and parameter type hints, the missing output schemas and incomplete error guidance prevent this from reaching 70+.
Run passive reconnaissance against a target domain. Gathers DNS records, subdomains (via Certificate Transparency), WHOIS data, technology fingerprints, and certificate information. No packets are sent to the target — all data comes from DNS resolvers and public APIs.
Run a web application vulnerability scan using OWASP ZAP. Launches a security scanner against the target URL to discover vulnerabilities. Returns structured findings with severity ratings, descriptions, and remediation guidance. Scan levels: - "light": Spider + passive analysis only (~5-10 minutes). No active probing. - "deep": Spider + active vulnerability scanning (~30-60 minutes). - "aggressive": Full active scan with no time limit.
Output schemas not documented. Neither recon_passive_tool nor scan_web_application_tool shows return type structure in visible source code. Tools return dicts, but what fields? What types? What pagination? LLMs cannot plan downstream chaining without knowing the response shape.
scan_level parameter is a free-form string, not a formal enum. Valid values ('light', 'deep', 'aggressive') are documented in the description but not enforced in schema. LLMs may hallucinate invalid values ('medium', 'quick', 'full'). Per pattern:constrained-input, known-value params must be enums in schema, not description-only.
Error handling lacks recovery guidance. scan_web_application validates scan_level inside the function and returns {'error': '...'} on ValueError. However, the error message does not guide the LLM: 'Invalid scan_level: light, deep, or aggressive.' is present in code but does not appear in MCP response shown. No per-tool confirmation or dry-run pattern for destructive scans (active scanning can probe vulnerabilities).
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 12 | 2026-07-28+ | v2 |
| 2026-03-09 | C | 65 | - | v1 |
No structured error reporting or MCP error codes. Errors are returned as {'error': 'message'} dicts, loose, unstructured, no categorization. Per MCP spec, tools should use ToolError/ToolException with codes (retryable, not_found, unauthorized, etc.) so agents know whether to retry, ask user, or fail. Pattern:error-classification not implemented.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). Both tools are security-sensitive: recon_passive is read-only (safe), scan_web_application is destructive/exploratory (probes the target, may trigger WAF/IDS). MCP annotations would clarify risk profile to agents.
depth parameter in recon_passive_tool is not an enum. Valid values ('standard', 'deep') are documented but not schema-constrained. LLMs may pass 'quick', 'full', 'thorough'. Should be enum in schema per pattern:constrained-input.
No pagination or result limits documented. If recon_passive returns hundreds of subdomains or scan_web_application returns hundreds of vulnerabilities, no limit or pagination mechanism is visible. Per pattern:paginated-result and mxe:enforce-result-limits, large result sets must be capped and paginated to avoid context window exhaustion.