Loading ToolBench
All-in-one Bug Bounty MCP server with AI integration, Caido, PostgreSQL, Redis, and Burp Suite support
Scoring was not performed
NO INPUT SCHEMAS VISIBLE. All 12 tools lack documented JSON Schema. The server.ts framework accepts 'inputSchema: any' but no tool files (recon.ts, js.ts, security.ts, etc.) are provided in the source excerpt. Cannot verify parameter types, required fields, or constraints. Baseline: 100% of A+ tools have documented schemas.
GENERIC CATEGORY DESCRIPTIONS. Tool descriptions are 6-50 character category-level labels ('Reconnaissance tools (subfinder, httpx, amass, dns)', 'JavaScript analysis (download, beautify, endpoints, secrets)') rather than LLM-actionable per-tool docs. No explanation of WHEN to use each tool, WHAT it returns, or HOW it differs from related tools. Baseline: descriptions should be 10-1024 chars, explaining what/when/how.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 27 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 13 | 2024-11-05+ | v1 |
WILDCARD TOOL NAMES. Tools are named with namespace prefixes (recon.*, js.*, db.*) rather than explicit verb_noun naming. Standard MCP expects individual tool names like 'recon_run_subfinder', 'recon_run_httpx', 'js_download', 'js_beautify'. Wildcard notation is non-standard and leaves LLM unsure which specific action to invoke. Violates naming baseline: 90% of A+ tools start with action verbs.
NO PARAMETER DOCUMENTATION. No evidence of per-parameter descriptions in source. The patterns indicate every parameter needs a description explaining what it controls, allowed values, range, and format. Cannot verify LLM can reason about parameters like 'status', 'limit', 'query', 'url'. Baseline: 100% of A+ tool params have descriptions.
NO OUTPUT SCHEMA DOCUMENTATION. Baseline: 100% of A+ tools document return types. No visible schema or example output for what recon.* returns (list of domains? JSON object? Raw text?), what js.* returns (beautified code? Secret list?), what db.save_finding returns (success? Finding ID?). LLMs cannot plan downstream tool chains without knowing output structure.
TOOL COMPOSITION UNCLEAR. 12 tools span recon, JS analysis, security testing, DB operations, and training data. No documentation on tool sequences (e.g., 'call recon.* first, then security.* to test findings'). Baseline: tools should be composable via clear input/output naming (tool A's output contains IDs tool B needs). Cannot verify.
NO ERROR HANDLING GUIDANCE. Baseline: error responses must tell LLM what to do next ('User not found. Try search_users()...'). No evidence of error classification (retryable, user-fixable, fatal) or recovery paths. handleToolCall in server.ts returns generic 'Tool not found' or 'Internal error' with data field but no actionable guidance.
SECURITY TOOLS LACK DRY-RUN / CONFIRMATION. security.*, csrf.*, burp.*, zap.* are testing/scanning tools that likely modify state (send requests, inject payloads, run active scans). Baseline: irreversible operations should support dry-run or confirmation. No evidence of this pattern.
DATABASE OPERATIONS LACK PERMISSION GATES. db.save_finding, db.init are destructive operations. Baseline: gate destructive tools behind permission checks and declare required scopes. No evidence of permission validation or audit logging in source.
INTEGRATION ENDPOINTS NOT SPECIFIED. burp.*, caido.*, zap.* integrate with external security tools. No documentation of required API keys, endpoint URLs, authentication method, or how the server discovers/configures these tools. Baseline: dependencies and prerequisites must be explicit in descriptions.