Loading ToolBench
MCP server that integrates with Burp Suite to provide AI-driven security testing capabilities including vulnerability scanning, request analysis, authentication testing, and custom check creation
BurpMCP-Ultra provides 28 tools with generally complete schemas and descriptions. Most tools have clear verb-noun naming (access_control_sweep, analyze_request, collaborator_poll) and descriptions ranging 100-400 chars. However, several critical gaps reduce quality: (1) Many parameter descriptions are minimal or missing type constraints (e.g., 'Identities: each {name, header_name?, header_value?}' lacks format guidance). (2) Output schemas are undocumented, no tool explicitly declares what fields the response contains, forcing LLMs to infer structure. (3) Error handling is generic ('Unknown error') with no recovery guidance. (4) Some tools conflate multiple concerns (e.g., api_import_openapi both parses AND sends requests). (5) Tool annotations (readOnlyHint, destructiveHint) are absent despite clear risk levels. Naming is strong; descriptions are adequate but not LLM-optimized; schemas are present but incomplete.
Batch broken-access-control / IDOR test: replays each request under every identity and flags where a lower-privilege or unauthenticated identity gets a response matching a higher-privilege one. Scales auth_diff across many endpoints in one call. Provide 'identities' as [{name, header_name?, header_value?}] — a name of none/unauth strips auth headers. Scope-gated (mcp_scope_mode).
Send a prompt to Burp Suite's built-in AI and receive a response. Useful for security analysis, vulnerability explanation, and remediation advice. Parameters: messages (required, array of strings forming the prompt), context (optional string providing additional background context for the AI). Requires Burp Suite Professional with AI enabled.
Check whether Burp Suite's AI feature is enabled and available. Returns the current AI status. This feature is only available in Burp Suite Professional 2025+ editions.
Extract all parameters from an HTTP request including URL query params, body params, cookies, headers, JSON body fields (recursively flattened), and XML element/attribute values. Parameters: request (string, the raw HTTP request).
Find reflected parameter values in an HTTP response. Extracts all parameter values from the request (URL, body, cookies) and searches for each in the response body. For each reflection, determines the surrounding context (html_body, html_attribute, javascript, css, url, html_comment). Parameters: request (string, raw HTTP request), response (string, raw HTTP response), additional_values (optional array of extra strings to check for reflection).
Output schemas undocumented. No tool declares what fields the response contains (e.g., analyze_request returns 'method, URL, path, headers, cookies, parameters, body, content_type' but this is only in description text, not in a structured output schema). LLMs cannot plan downstream tool calls without knowing response structure.
Tool annotations missing. Despite clear risk levels (READ_ONLY, WRITE, DESTRUCTIVE), no tools declare readOnlyHint, destructiveHint, or idempotentHint. This prevents agents from reasoning about safety and retry logic.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 63 | 2026-07-28+ | v2 |
Identify all potential injection/insertion points in an HTTP request. Returns URL parameters, body parameters, cookies, injectable headers (User-Agent, Referer, X-Forwarded-For, etc.), and URL path segments. Parameters: request (string, raw HTTP request), host (string, target hostname), port (number, target port), use_tls (boolean, whether to use HTTPS).
Parse and analyze a raw HTTP request. Returns the method, URL, path, headers, cookies, parameters (URL, body, cookie), body content, and content type. Parameters: request (string, the raw HTTP request to analyze).
Parse and analyze a raw HTTP response. Returns the status code, reason phrase, headers, cookies (with domain, path, expiration), body, stated and inferred MIME types. Parameters: response (string, the raw HTTP response to analyze).
Import an OpenAPI/Swagger JSON specification. Parses all endpoints, generates HTTP requests with sample parameters and bodies, and optionally sends them through Burp (populating sitemap and proxy history). Supports OpenAPI 3.x and Swagger 2.0. Parameters: spec_json (required, the full JSON spec), base_url (optional override), auth_header/auth_value (optional auth for all requests), add_to_scope (bool), add_to_sitemap (bool), send_requests (bool, actually send and get responses).
Authorization level diffing: sends the same request with different auth levels (admin, user, unauthenticated) and compares responses to detect IDOR, privilege escalation, and broken access control. Provide auth_levels as an array of objects: [{"name": "admin", "header_name": "Authorization", "header_value": "Bearer admin-token"}, {"name": "user", "header_name": "Authorization", "header_value": "Bearer user-token"}, {"name": "none"}] The tool automatically strips auth headers for "none"/"unauth" levels. Analyzes status codes, body content, body length, and headers for differences. Flags critical findings like identical responses across auth levels.
Import a Bambda script into Burp Suite. Bambda expressions are Java-like lambda expressions used to customize Burp Suite's behavior, such as proxy history filters, HTTP match-and-replace rules, and custom column definitions. Parameters: script (required, the Bambda script content as a Java lambda expression string).
Generate and deploy a BCheck custom scan check from structured parameters. BChecks are Burp Suite's DSL for defining custom vulnerability detection rules that run during scanning. Parameters: name (required, check name), description (required, what it detects), type (required, one of: passive_response, passive_request, insertion_point, host_level, path_level, collaborator), match_pattern (regex/string to match), match_location (where to match: response_body, response_headers, request_body, request_headers, status_code), match_condition (matches, contains, or is), payloads (array of payload strings for active checks), response_match_pattern (what to look for in response after injection), collaborator_payload_type (dns or http), severity (required, one of: high, medium, low, information), confidence (required, one of: certain, firm, tentative), author (optional, defaults to BurpMCP-Ultra AI Agent), tags (optional, comma-separated tags), issue_detail (detailed issue description), issue_remediation (how to fix the issue). Use bcheck_templates first to understand the BCheck DSL patterns before creating checks.
Import a raw BCheck script directly into Burp Suite. Use this when you have a complete BCheck script in BCheck DSL format. The script must include a metadata block with language, name, and description fields, followed by the check logic. Parameters: script (required, the full BCheck DSL script as a string). Use bcheck_templates to see the correct syntax and available DSL constructs.
Get the command line arguments that were used to launch Burp Suite. Returns the arguments as a list of strings.
Export Burp Suite project-level configuration as JSON. Parameters: paths (optional string array of configuration paths to export, e.g. ["proxy", "scanner"]. If omitted, exports all project options).
Export Burp Suite user-level configuration as JSON. Parameters: paths (optional string array of configuration paths to export. If omitted, exports all user options).
Import project-level configuration into Burp Suite from a JSON string. Parameters: config_json (required, the JSON configuration string to import).
Import user-level configuration into Burp Suite from a JSON string. Parameters: config_json (required, the JSON configuration string to import).
Set the state of Burp Suite's task execution engine. Parameters: state (required, must be 'running' or 'paused'). Pausing the engine suspends all background tasks (scans, crawls).
Get the current state of Burp Suite's task execution engine (running or paused). The task engine controls whether background tasks like scanning and crawling are actively executing.
Get Burp Suite version information including product name, version number, build number, and edition (Professional/Community).
Create a new Burp Collaborator client for generating out-of-band (OOB) interaction payloads. Returns a client ID and the Collaborator server address. Pro edition only.
Generate a unique Collaborator payload (subdomain) for OOB interaction detection. Use this payload in injection points to detect blind vulnerabilities (SSRF, blind XSS, etc.). Optionally embed custom data in the payload for identification.
Get the secret key for a Collaborator client. Store this key to restore the client in a future session and continue polling for interactions.
Poll for Collaborator interactions (DNS lookups, HTTP requests, SMTP connections) that have been triggered by injected payloads. Optionally filter by interaction type or payload ID.
Restore a previously created Collaborator client using its secret key. This allows resuming interaction polling from a prior session. Pro edition only.
Get the Collaborator server address and metadata for a given client.
Send data items to Burp Suite's Comparer tool for side-by-side comparison. Useful for comparing HTTP requests, responses, or any text data to identify differences. Parameters: data (array of strings, each string becomes a separate item in the Comparer). At least one item is required; typically two items are sent for comparison.
Parameter descriptions lack format constraints. E.g., 'Identities: each {name, header_name?, header_value?}' does not specify that header_name/header_value are strings, or that name is required. 'Payloads (array of payload strings)' does not explain what constitutes a valid payload or size limits.
Error handling is generic and non-actionable. All tools return 'Unknown error' or raw exception messages. No guidance on retry, user action, or recovery. E.g., 'Parameter requests (array of objects) is required' does not explain what fields each object must contain.
Tool composition concerns. api_import_openapi combines parsing, request generation, and sending in one tool. This violates single-responsibility and prevents agents from composing steps independently. Should split into api_import_openapi (parse only) and api_send_requests (execute).