A Model Context Protocol (MCP) server that calls Burp Suite Professional's built-in local REST API to launch scans and retrieve scan status/issues.
This MCP server allows AI assistants to drive Burp Suite Professional's scanner for web security testing. It provides tools for:
- Starting vulnerability scans on target URLs
- Checking scan status
- Retrieving vulnerability issues found by a scan
It talks to Burp Suite Professional's own local REST API — the same API surface Burp exposes for its own automation, not a separate hosted product. (Burp Suite Enterprise has a different, GraphQL-first API aimed at CI/CD; this server does not use it.)
get_proxy_history and get_site_map are kept in the tool list for interface compatibility with earlier versions of this server, but Burp Suite Professional's REST API has no endpoint for proxy history or the site map — see Known limitation below.
- Open Burp Suite Professional, go to Settings > Suite > REST API.
- Check "Service running".
- Note (or change) the service URL/port — the default is
http://127.0.0.1:1337(loopback only by default; PortSwigger advises against binding to a non-loopback interface on an untrusted network). - Create an API key. The key is only shown once, at creation — copy it somewhere safe.
Burp's REST API is accessed as http://<host>:<port>/<api-key>/v0.1/.... It is also self-documenting: once the service is running, browsing to http://<host>:<port>/<api-key>/v0.1/<api-key> shows the exact request/response schema for your installed Burp version. PortSwigger does not publish a full static schema for this API, so if a tool's output looks off, that page is the source of truth.
This server requires two environment variables — it will refuse to start without them:
| Variable | Description |
|---|---|
BURP_API_URL |
Base URL of Burp's REST API service, e.g. http://localhost:1337 |
BURP_API_KEY |
The API key generated in Settings > Suite > REST API |
The server exposes the following tools:
-
start_scan: Start a new vulnerability scan on a target URL (
POST /v0.1/scan). This launches a real scan against the target and generates live traffic to it.- Parameters:
target(required): Target URL to scan (e.g.,https://example.com)scope(optional): Passed through as-is to Burp's request body (e.g.{ include: [...], exclude: [...] }). The exact shape isn't published by PortSwigger — check your instance's self-documenting API if unsure.scan_configurations(optional): Passed through as-is (e.g. references to named configurations from Scanner > Scan configurations). If omitted, Burp uses its default crawl-and-audit configuration.application_logins(optional):[{ username, password }, ...]for authenticated scanning, passed through as-is.
- Parameters:
-
get_scan_status: Check the status of a scan (
GET /v0.1/scan/{task_id})- Parameters:
scan_id: Task id of the scan (returned bystart_scan)
- Parameters:
-
get_scan_issues: Get vulnerability issues found so far by a scan. Issues come back embedded in the same
GET /v0.1/scan/{task_id}response as scan status — there's no separate issues endpoint.- Parameters:
scan_id: Task id of the scanseverity: Filter issues by severity (high,medium,low,info, orall)
- Parameters:
-
get_proxy_history / get_site_map: Not supported by Burp Suite Professional's REST API. Calling either returns a clear explanatory error rather than fabricated data. See Known limitation.
Note: earlier versions of this server accepted a scan_type (passive/active/full) parameter on start_scan. That parameter had no real equivalent in Burp's REST API and has been replaced with the scope/scan_configurations/application_logins fields above, which map onto Burp's actual request body.
Burp Suite Professional's REST API only supports launching scans and reading scan status/issues — it has no endpoint for HTTP proxy history or the site map. That data is only reachable through:
- Burp's separate Montoya extension API (a Java/Kotlin/Python extension you write and load into Burp, which can expose whatever data you need over its own interface), or
- The desktop UI directly (Proxy > HTTP history, Target > Site map).
Rather than remove get_proxy_history/get_site_map outright (which could silently break existing configurations that reference them by name) or fake their output (which is the exact problem this rewrite fixes), both tools are kept and simply return an explanatory error when called.
All tools call the real Burp REST API and surface real failures instead of falling back to mock data:
- Connection refused / Burp not running / REST API not enabled: returns a clear message telling you to check that Burp is running with the REST API enabled and that
BURP_API_URLis correct. - 401/403 (bad API key): returns a message telling you to check
BURP_API_KEY. - 404: returns a message covering the two likely causes — an unknown/expired scan id, or a
BURP_API_URL/BURP_API_KEYmismatch. - Any other non-2xx response is surfaced with the HTTP status and response body.
To install Burp Suite Server for Claude Desktop automatically via Smithery:
npx -y @smithery/cli install @Cyreslab-AI/burpsuite-mcp-server --client claude-
Build the server:
cd /path/to/burpsuite-server npm install npm run build -
Add the server to your MCP settings configuration file:
{ "mcpServers": { "burpsuite": { "command": "node", "args": ["/path/to/burpsuite-server/build/index.js"], "env": { "BURP_API_URL": "http://localhost:1337", "BURP_API_KEY": "your-api-key-here" }, "disabled": false, "autoApprove": [] } } }
Here are some examples of how to use the Burp Suite MCP server with an AI assistant:
Use the Burp Suite MCP server to scan example.com for vulnerabilities.
What's the status of scan <scan_id>?
What high severity vulnerabilities were found in scan <scan_id>?