Loading ToolBench
An MCP wrapper for Burp Suite that builds complete, well-structured HTTP requests and ingests dedup/JS exports for token-efficient pentesting.
Strong tool naming (verb_noun pattern consistently applied: inspect_, repeater_, intruder_, list_, search_, dedup_, js_). All 18 tools have descriptions (avg ~150 chars, within baseline 34-392). Input schemas present for all tools with proper JSON Schema types. However, output schemas are NOT documented, critical gap for LLM planning. Error handling descriptions exist but lack recovery guidance (e.g., 'history_index out of range' explains the problem but doesn't suggest next steps like 'call list_history() to see current indices'). Parameter descriptions are generally good (72 char baseline met), but some lack format constraints (e.g., 'regex' params don't specify PCRE vs Python re syntax). No tool annotations (readOnlyHint/destructiveHint) despite clear risk stratification (READ_ONLY vs WRITE). Composition is sound, tools are single-responsibility and chainable (e.g., list_history → inspect_history_entry → repeater_from_history). Security: no secrets in params (good), but no permission gates or audit trail declarations.
Fetch a single dedup entry by index.
List all loaded dedup sources and their entry counts.
Load a deduped HTTP history export file (from the Burp extension).
Search a dedup source by regex pattern (across URL, request, response, parameters).
Send a dedup entry to Burp Repeater, with optional overrides.
Fetch and pretty-print a Burp proxy history entry by index. `history_id` is the 0-based index into the most recent `page_size` entries (Burp's MCP doesn't expose stable IDs; addressing is positional). Use this to inspect cookies/headers before crafting a mutated request.
Output schemas not documented. LLMs cannot plan downstream tool calls or extract required fields (e.g., what does dedup_search return? Is it a list of entries with URLs and request bodies?). This forces agents to guess structure and wastes tokens on parsing.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). Tools are marked with Risk: READ_ONLY or WRITE in metadata, but MCP tool definitions lack these hints. Agents cannot distinguish safe from destructive operations without reading descriptions.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 64 | <=2025-11-25 | v2 |
Send a request to Burp Intruder, built from a history baseline plus optional overrides.
Send a request to Burp Intruder, built from scratch via URL + structured fields.
List JS files in a source, optionally filtered by host.
List all loaded JS sources and their file counts.
Load a JS Exporter manifest file (from the Burp extension).
Read the full content of a JS file by index, URL, or path.
Grep across all JS files in a source.
List recent Burp proxy history entries (paginated).
Send a request to Burp Repeater, built from a history baseline plus optional structured overrides. The baseline contributes Host, cookies, auth, UA, etc. so the resulting request is always complete. Overrides modify only what you specify.
Send a request to Burp Repeater, built from scratch via URL + structured fields.
Search Burp proxy history by regex pattern.
Send a raw HTTP/1.1 request directly (no Repeater/Intruder tab).
Error messages lack recovery guidance. Example: 'history_index out of range; page has N entries' explains the problem but doesn't suggest 'call list_history() to see current indices' or 'indices shift when new traffic arrives'. Agents need actionable next steps.
Regex parameters lack format specification. 'search_history' and 'js_search' accept 'regex' and 'pattern' params but don't specify Python re syntax, PCRE, or other dialect. LLMs may pass invalid patterns.
No pagination guidance for large result sets. 'js_search' returns up to 20 files with up to 3 matches per file, but no total count or next_cursor. If a pattern matches 1000 files, the agent has no way to iterate.