MCP workflows

Follow complete examples for active scanning, passive analysis and results.

These blocks are tool arguments, not standalone HTTP POST bodies. Let an MCP client handle initialization, JSON-RPC and sessions. Examples name profiles supplied with this documentation; install those files in your test catalogue or replace the names with exact results from list_profiles.

Active HTTPS scan

After discovering Example_Marker_Reflection:

{
  "requests": ["GET /search?q=hello HTTP/1.1\r\nHost: app.example.test\r\n\r\n"],
  "services": ["https://app.example.test:443"],
  "profile_names": ["Example_Marker_Reflection"],
  "mode": "active",
  "rps": 10,
  "concurrency": 5,
  "payload_strategy": "all",
  "retain_results": true
}

services identifies the connection destination. Host: app.example.test:443 alone does not establish HTTPS. A virtual Host header can differ from the destination, but approval checks and destination confinement use the parsed service origin.

Passive request and response analysis

No application request is sent by this passive scan:

{
  "requests": ["GET /?debug=1 HTTP/1.1\r\nHost: app.example.test\r\n\r\n"],
  "responses": ["HTTP/1.1 200 OK\r\nContent-Length: 2\r\nX-Debug-Mode: enabled\r\n\r\nOK"],
  "services": ["https://app.example.test:443"],
  "profile_names": ["Example_Debug_Query_Parameter", "Example_Debug_Header"],
  "mode": "passive",
  "retain_results": true
}

For request-only analysis, select only passive-request profiles and omit responses. Response profiles with missing/empty response input are rejected. The approval gate still applies to creation.

Follow one scan

Save the connection alias and returned scan ID, then poll:

{"scan_id": "scan_REPLACE_WITH_RETURNED_ID"}

Use this with get_scan_status, typically at intervals of 5–10 seconds with backoff for longer scans. Read status, finished/failed counts and warnings. On completion, request summaries:

{"scan_id": "scan_REPLACE_WITH_RETURNED_ID", "offset": 0, "limit": 20}

Call get_scan_issues again with the returned next_offset until it is null. Fetch selected evidence with get_scan_issue:

{"scan_id": "scan_REPLACE_WITH_RETURNED_ID", "issue_id": 0}

Use an actual issue_id from the summary. Empty findings, missing prerequisites and unavailable results are different outcomes.

Example instruction to an agent

Use the burp-bounty-server skill and the server named burp_bounty_local. Inspect server_info and list_profiles first. Analyze the supplied request using the enabled SQLi profiles at 10 RPS and concurrency 5. Keep its HTTPS service and authentication. If approval is pending, report it and wait for the operator. Poll compact progress, retrieve all finding summaries, and fetch evidence only for relevant findings. Report warnings and failed requests alongside the findings.

For a single parameter, explicitly add the marker requirement. For two servers, include a division of work and a combined budget as described in distributed scanning.

Submit an exported profile and configure tokens

Create the profile in Pro's graphical editor, save it and validate the generated .bb file. If submitting it inline, the MCP client reads that complete file and serializes its contents into the profiles string. This is transport of an exported profile, not a requirement to hand-write its JSON options. Do not also supply names or tags. Creating a scan to discover the profile schema can launch traffic and is not a validation-only operation.

The MCP tool has no custom-token map argument. Use configured engine tokens, a deliberately prepared profile with concrete values, or the REST tokens configuration. Do not invent a tokens parameter for create_scan.

Compact status, paginated summaries and selective evidence retrieval reduce repeated context volume. The scanner performs its HTTP loop without asking the model to generate every probe. There is no fixed token-saving percentage: tool schemas, polling frequency and returned evidence still consume context.