Loading ToolBench
A Python-based security analysis framework that combines Burp Suite's HTTP traffic capture with Claude Code's reasoning via MCP. Provides endpoint filtering, finding classification, scope validation, and report generation for security assessments.
This MCP server exhibits significant definition quality gaps across naming, descriptions, parameter validation, and output documentation. While 7 tools are registered, most lack proper schema depth and comprehensive error handling guidance. The naming follows some verb conventions (validate, report, filter_endpoints, format_finding, generate_report) but several tool names are generic or insufficiently descriptive. Parameter descriptions exist but are sparse and lack actionable constraints. Output schemas are not documented in the source code provided. The toolkit appears designed as a CLI wrapper around internal libraries (scope_validator, endpoint_filter, finding_formatter, report_generator) but does not expose enough structured metadata for LLM-driven tool selection and composition. Average per-tool score: 38/100.
Run a demo with sample data showing endpoint filtering and finding formatting capabilities
Filter and prioritize endpoints from Burp Suite traffic based on scope configuration and security indicators
Format a security finding into structured markdown output with evidence, impact, and remediation
Generate consolidated security report from findings with executive summary, statistics, and recommendations
Generate a report from findings
Validate a scope.yaml file
Show version information
Generic tool names create ambiguity and break LLM selection logic. 'report' vs 'generate_report' appear to do the same thing; 'demo' and 'version' lack verb-based clarity.
Parameter descriptions are missing or insufficient. 'scope_config' param in filter_endpoints lacks any description of its expected structure; 'config' param in generate_report references 'ReportConfig object' but schema is not visible.
Output schemas are not documented in tool definitions. LLMs cannot predict what fields are returned (e.g., does format_finding return a string or an object? does filter_endpoints return sorted array?). This forces agents to guess and breaks tool chaining.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 43 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 0 | - | v1 |
No error handling guidance provided. Tools return success/failure but do not explain recovery steps (e.g., validate: what specific errors can occur? report: what if output_dir doesn't exist?). Errors lack actionable next steps.
Parameter constraints are underspecified. 'scope_file' in validate tool has no description of file format, size, or path requirements. 'output_dir' in report and generate_report tools lack validation rules (must exist? must be writable?).
Tool descriptions are too short (p10 baseline is 34 chars; optimized range 50-200). 'validate' (27 chars), 'report' (33 chars), 'demo' (60 chars), 'version' (23 chars) all fall below optimal length and lack actionable context for LLM selection.
Object parameters lack nested schema visibility. 'scope_config' (filter_endpoints), 'finding' (format_finding), and 'config' (generate_report) are typed as objects but their properties, required fields, and types are not documented.
Tool composition is unclear. The relationship between filter_endpoints (filters entries) → format_finding (formats one finding) → generate_report (aggregates findings) is not documented. LLMs cannot infer the correct call sequence or required data structure transformations.
Functional duplication between 'report' and 'generate_report' creates LLM selection ambiguity. Both appear to generate reports from findings; the distinction is unclear from descriptions.
No pagination or result-limiting parameters visible. If 'filter_endpoints' returns a large array of endpoints, there is no limit or page parameter to prevent context window exhaustion.