Loading ToolBench
An MCP server that integrates with Burp Suite via the Montoya API, providing tools for HTTP request manipulation, collaborator payload generation, and interaction retrieval
BurpMCP provides 8 tools with mostly complete schemas and descriptions, but has moderate gaps in naming clarity, parameter documentation, and error handling guidance. Tool names are generally action-oriented (generate-, get-, http1-, http2-, retrieve-, save-), which is positive. However, descriptions vary in depth, some are quite detailed (http1-resend, http2-send) while others are generic. Parameter descriptions are present for most tools but lack constraint documentation (ranges, enums, format hints). No input validation guidance or recovery hints are visible. Output schemas are not documented. Error handling responses show basic error wrapping but lack actionable recovery guidance per the pattern:recovery-guide standard.
Generates a new collaborator payload for out-of-band applicationsecurity testing
Retrieves a stored request/response pair and any notes from the saved request list by ID
Resends a saved HTTP/1.1 request with partial replacements using regex patterns for data and full replacement for host/port/secure
Sends an HTTP/1.1 request using Burp's HTTP client
Resends a saved HTTP/2 request with partial replacements using regex patterns for body/headers/path and full replacement for authority/method/host/port/secure
Sends an HTTP/2 request using Burp's HTTP client
Missing output schema documentation for all tools. Callers cannot see what fields are returned, which breaks the pattern:tool-chain expectation that tool A's output contains IDs tool B needs.
Parameter descriptions lack constraint documentation. For example, 'id' parameters show only 'ID of the...' with no mention of valid range. 'port' parameters lack min/max bounds. 'count' in retrieve-collaborator-interactions has a natural language default ('10 to limit token usage') but no formal min/max or enum constraints.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 69 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 47 | - | v1 |
Retrieves collaborator interaction details
Saves an HTTP/1.1 request to the saved requests list
Error handling in source code (GenerateCollaboratorPayloadTool.java) shows 'ERROR: ' + exception message concatenation, which is not actionable per pattern:recovery-guide. LLMs receiving raw exception messages have no guidance on whether to retry, what to fix, or which tool to call next.
http1-resend and http2-resend tools accept complex nested regex replacement objects but lack guidance on escape sequences, special characters, or what happens if a regex is invalid. No description of error recovery.
Tools http1-send, http2-send, http1-resend, http2-resend have high risk (WRITE) and make network requests but no confirmation/dry-run pattern is visible. Agents could inadvertently send malicious payloads or probe unintended targets.
Naming: 'http1-resend' vs 'http1-send' and 'http2-resend' vs 'http2-send' are visually similar and risk LLM confusion. The distinction (saved request + replacements vs raw data) is not obvious from names alone. Consider 'resend-saved-http1-request' and 'send-raw-http1-request' for clarity.