Loading ToolBench
Local-first Burp Suite MCP extension with operator-controlled capabilities and complete in-Burp AI activity auditing
BurpSuiteMcp provides 9 tools with complete input schemas and descriptions, but quality is uneven. All tools have descriptions (10 - 200 chars, within baseline range) and typed parameters with descriptions. However, output schemas are not documented in the source code provided, and several tools lack actionable error guidance. Tool naming follows verb_noun convention (proxy_history_list, http_send, scanner_audit_start) but some names are overly specific (http_timing_compare vs timing_compare). No tool annotations (readOnlyHint/destructiveHint) are visible despite clear risk classifications. Error handling is minimal, no recovery guidance or actionable error messages evident. Composition is sound: tools are single-responsibility and chainable (e.g., http_exchange_get returns artifact_id usable by http_timing_compare). Parameter descriptions are adequate but lack format constraints (e.g., base64 encoding, timing thresholds). Overall: solid foundation, but missing output documentation and error recovery patterns that distinguish A-grade tools.
Retrieves a specific HTTP exchange artifact with request/response data, headers, and metadata based on exposure profile
Sends an HTTP request through Burp Suite proxy with timing comparison capability, requires operator to enable active HTTP
Compares timing of HTTP responses for baseline and probe requests to detect timing-based vulnerabilities
Lists HTTP evidence from Burp Suite proxy history with pagination support, filtering by scope and exposure profile
Initiates an active scanner audit on an in-scope HTTP artifact, requires operator to enable Active Scanner
Returns the current status of the MCP server including name, version, state, endpoint, uptime, and concurrent tool call metrics
Output schemas not documented. Tool descriptions state what is returned (e.g., 'HTTP evidence', 'timing comparison') but no structured schema is visible in source. LLMs cannot plan downstream tool calls or extract specific fields without knowing response structure.
No tool annotations (readOnlyHint/destructiveHint/idempotentHint) despite clear risk classifications. Tools marked WRITE (http_send, scanner_audit_start, websocket_connect, websocket_send) should declare destructiveHint=true; READ_ONLY tools should declare readOnlyHint=true. This enables agents to reason about side effects.
Error handling lacks recovery guidance. No evidence of actionable error messages (e.g., 'Invalid artifact_id: not found in proxy history. Call proxy_history_list() to discover available artifacts.'). Errors should categorize as retryable, user-fixable, or fatal.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 61 | 2025-06-18+ | v2 |
Establishes an active WebSocket connection with upgrade request, requires operator to enable Active WebSocket
Receives messages from an active WebSocket connection with cursor-based pagination
Sends a message over an active WebSocket connection, requires operator to enable Active WebSocket
Parameter format constraints missing. 'request_bytes' and 'upgrade_request_bytes' are described as 'Base64-encoded' but no minLength, maxLength, or pattern constraint is visible. 'timing_comparison' boolean lacks explanation of what 'true' triggers. Format constraints prevent LLM hallucination.
Pagination cursor semantics unclear. proxy_history_list and websocket_receive accept 'cursor' (string/integer) but no documentation of cursor format, initial value, or end-of-results signal. LLMs cannot reliably iterate without explicit pagination contract.