burp-mcp-plus
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| inspect_history_entryA | Fetch and pretty-print a Burp proxy history entry by index.
Use this to inspect cookies/headers before crafting a mutated request. |
| repeater_from_historyA | Send a request to Burp Repeater, built from a history baseline plus optional structured overrides. The baseline contributes Host, cookies, auth, UA, etc. so the resulting request is always complete. Overrides modify only what you specify. Args: history_id: id of the proxy history entry to clone tab_name: optional Repeater tab label method/path/body: override the corresponding field set_headers: replace or add these headers (case-insensitive) remove_headers: header names to delete page_size: how many recent history entries to scan to find the id |
| repeater_from_templateA | Send a request to Burp Repeater, built from scratch (URL + structured fields). Optionally inherit cookies/auth/UA from a history baseline. Args:
url: full URL, e.g. https://api.example.com/v1/users?id=1
method: HTTP method (default GET)
headers: additional headers (overrides any inherited values)
body: request body
tab_name: Repeater tab label
inherit_from_history_id: copy headers from this baseline first; the
|
| send_requestA | Issue an HTTP/1.1 request via Burp (no Repeater tab) and return the response. Two usage modes:
|
| intruder_from_historyC | Send a request to Burp Intruder, built from a history baseline.
|
| search_historyA | Search Burp proxy history with a regex; returns a compact list of
matching entries with their |
| list_historyA | List recent Burp proxy history entries with their Use this to browse and find an entry to feed into the repeater/intruder tools when a regex search isn't precise enough. |
| collaborator_generateA | Generate one or more Burp Collaborator payloads. Use these as out-of-band injection canaries (SSRF, blind XSS, OOB SQLi,
etc.). Save the returned payloads, plant them, then poll
|
| collaborator_checkA | Poll Burp Collaborator for received interactions. Returns whatever Burp's |
| sitemapA | Build a sitemap from Burp proxy history (no upstream Target tool exists). Groups entries by (host, path, method) and counts occurrences. Returns
a tree-style JSON: { host: { method: [{path, count, last_status}] } }.
Use |
| dedup_loadA | Load a
|
| dedup_listA | List all registered dedup sources. |
| dedup_searchA | Regex-search a registered dedup source.
|
| dedup_getA | Fetch a dedup entry by its 1-based index. By default returns metadata + truncated request/response previews. Set
|
| dedup_to_repeaterB | Send a dedup entry to Burp Repeater, with optional structured overrides. The dedup entry is the baseline (cookies, UA, etc. inherited). The
wrapper rebuilds the wire format and pushes it via Burp's
|
| js_loadC | Load a |
| js_listB | List all registered JS sources. |
| js_filesC | List JS files in a source, optionally filtered by host regex. |
| js_searchA | Grep across all on-disk JS files in a source. Returns file:line + small context snippets (token-thrifty). Use |
| js_readB | Read one JS file from a source.
|
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 20 tools
Each tool targets a distinct Burp feature or action: collaborator generation vs. polling, dedup management (load, list, get, search, send to repeater), JS file handling (load, list, get, search), history browsing (list, search, inspect), repeater/intruder creation from history or template, direct request sending, and sitemap building. Overlaps like multiple tools that send to repeater are differentiated by source (history entry vs. template vs. dedup entry).
Tool names follow a consistent verb_noun pattern (e.g., collaborator_check, dedup_get, list_history, send_request) with occasional prepositions for specificity (e.g., dedup_to_repeater, repeater_from_history). The naming is predictable and readable across the entire set.
With 20 tools, the server covers multiple distinct aspects of Burp interaction (history, repeater, intruder, collaborator, dedup, JS files) without being overbearing. Each tool serves a clear purpose, and the count is well-scoped for a comprehensive Burp automation interface.
The tool set provides a solid coverage of core Burp workflow needs: history inspection, mutation and forwarding to repeater/intruder, collaborator interaction, dedup management, and JS file analysis. Minor gaps exist—such as no direct way to manage scope or proxy settings—but the surface is sufficient for typical automated testing scenarios.