burp-mcp-plus is a Python MCP wrapper that enhances Burp Suite's official MCP server with structured HTTP request building and local file ingestion, enabling efficient, token-cheap, and reliable LLM-driven security testing.
Live Burp Proxy History Interaction:
list_history — Browse recent proxy history entries with pagination
search_history — Search proxy history using regex patterns, returning compact summaries
inspect_history_entry — Pretty-print a specific history entry's headers, body, and target details
sitemap — Synthesize a host→method→paths tree from proxy history, with optional host regex filtering
Request Crafting & Sending:
repeater_from_history — Clone a history entry into Burp Repeater with optional structured overrides (method, path, headers, body)
repeater_from_template — Build a request from scratch using a URL and send to Repeater, with optional auth/cookie inheritance from a history baseline
send_request — Send an HTTP request immediately (no Repeater tab) and return the response
intruder_from_history — Push a request to Burp Intruder with automatic §…§ payload markers around specified substrings
Every request is built from typed fields plus a baseline, auto-generating correct CRLF, Host, Content-Length, User-Agent, and inherited cookies/auth to prevent malformed requests.
Out-of-Band Testing:
collaborator_generate — Generate Burp Collaborator OOB canary payloads (SSRF, blind XSS, etc.)
collaborator_check — Poll Burp Collaborator for received interactions, optionally filtered by payload
Local Deduplicated HTTP Traffic Ingestion:
dedup_load — Load a deduped_requests.txt export from the bundled Burp extension
dedup_list — List all registered dedup sources
dedup_search — Regex-search dedup entries across url, request, response, params, or all fields, returning token-efficient snippets
dedup_get — Fetch a specific dedup entry by index (preview or full request/response)
dedup_to_repeater — Send a dedup entry to Burp Repeater with optional structured overrides
Local JavaScript File Ingestion:
js_load — Load a _manifest.csv from the bundled JS Exporter Burp extension
js_list — List all registered JS sources
js_files — Browse JS files in a source, optionally filtered by host regex
js_search — Grep across all on-disk JS files returning file:line snippets
js_read — Read full content of a specific JS file by index, URL, path, or basename
Provides tools for interacting with Burp Suite, enabling AI agents to replay requests, search proxy history, send requests to Repeater/Intruder, generate and check Collaborator payloads, and synthesize sitemap from history, all with structured input to prevent malformed HTTP requests.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@burp-mcp-plus replay history entry 3 with modified Authorization header"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
You hook up an LLM to Burp's official MCP server and ask it to "replay this request with a tampered cookie." It dutifully crafts a Repeater payload — and silently drops the Cookie header, gets a 401, and confidently tells you the endpoint requires no auth.
Or it forgets Content-Length. Or Host. Or uses LF instead of CRLF. Or pastes a JSON body with no headers at all.
This happens because the upstream Burp MCP takes a free-form content string. Whatever the model emits goes straight to the wire. There's no schema, no validation, no help.
The other thing that breaks long pentest sessions: token cost. Each get_proxy_http_history call ships kilobytes of repeated headers back to the model. Triage a target for an hour and you've burned a fortune re-paginating the same proxy history.
Related MCP server: Burp Suite MCP Analyzer
burp-mcp-plus is a Python MCP wrapper that sits between your LLM and Burp's official MCP server. Two big ideas:
Every tool that touches HTTP takes typed fields — method, path, set_headers, body — and a baseline (a real entry from Burp's history, or a URL). The wrapper builds the wire format itself. Correct CRLF, auto-Host, auto-Content-Length, default User-Agent, inherited cookies. The LLM literally cannot produce a malformed request because there's no content parameter to put a malformed request in.
If you've already triaged a target with the bundled Deduped HTTP History + JS Exporter Burp extension, the wrapper indexes the exports on disk. dedup_search and js_search return file:line + 60-char snippets — meaningfully cheaper than re-hitting Burp every time the model wants to look at past traffic. Full content is only fetched on demand.
Plain Python stdio MCP server. Talks SSE to Burp's mcp-proxy-all extension on localhost:9876. Reads dedup/JS exports off disk. Works with any MCP host: Claude Desktop, Claude Code, Cursor, Continue, anything that speaks the protocol.
list_history / search_history — paginate or regex over proxy history. Returns compact summaries (id + method + url + status), not raw bytes.
inspect_history_entry — pretty-print one entry's headers, body, target.
repeater_from_history — clone a baseline, mutate any subset of (method, path, headers, body), push to Repeater. All other headers preserved verbatim from the baseline. Cookies, auth tokens, Sec-Fetch-, custom Anthropic- / X-* headers — all carry through.
repeater_from_template — build from scratch with a URL. Optionally inherit auth from a history baseline.
send_request — same shape, but actually sends and returns the response. Skip the Repeater dance when you just want to test.
intruder_from_history — push to Intruder with §…§ payload markers wrapped automatically around substrings you specify.
sitemap — host → method → paths tree, synthesized from history. Burp's MCP doesn't expose Target; we synthesize one.
collaborator_generate / collaborator_check — OOB canary payloads + interaction polling.
Point at a deduped_requests.txt produced by the bundled extension and the model can search/replay endpoints from past sessions without round-tripping through Burp.
dedup_load / dedup_list — register file(s) under a name.
dedup_search — regex over url / request / response / params / all. Returns 60-char snippets.
dedup_get — preview by default, full request/response on demand.
dedup_to_repeater — replay a stored entry into a fresh Repeater tab with optional mutations. HTTP/2 lines auto-coerced to HTTP/1.1.
Point at a _manifest.csv produced by the bundled extension's JS Exporter and the model can grep across all the JavaScript captured for a target.
js_load / js_list — register an export.
js_files — browse the manifest, filter by host regex.
js_search — grep across all on-disk JS. Returns file:line + snippet, max N matches per file (default 3). Transparently decodes the legacy array('b', [...]) byte-list format that older versions of the extension produced.
js_read — fetch full content for files of interest.
Tolerates Burp's NDJSON-with-no-separators history format.
Recovers parse-mid-stream when Burp truncates a long response with ... (truncated).
strict=False JSON decoding for raw control bytes inside body strings.
Specific error messages for empty inputs, status markers, malformed entries — pointing the model at the next tool to call.
20 tests covering wire-format building and edge cases (no Burp required to run them).
Install MCP Server from Burp's BApp Store. Confirm it's listening on http://127.0.0.1:9876 (Output tab).
If you want the dedup/JS ingestion features, install the bundled extension:
Set up Jython 2.7 in Burp → Settings → Extensions → Python environment.
Burp → Extensions → Installed → Add → Python → burp-extension/deduped_history.py from this repo.
Two new tabs appear: Deduped History and JS Exporter.
Before you start capturing, two things the extension needs:
Set your target scope. Burp → Target → Scope → add the host(s) you're testing (e.g. https://app.acme.com/.*). The extension only dedupes/exports in-scope traffic, so this keeps the output clean and avoids ingesting random third-party noise (CDNs, analytics, etc.).
Pick an output directory for the JS Exporter. In the JS Exporter tab, set the output dir + project name before browsing. Files land at <output_dir>/<project>/<host>/<flattened-path>/<file>.js along with a _manifest.csv that the wrapper indexes.
Then browse the target. The Deduped History tab fills as new endpoints appear; the JS Exporter tab fills as new .js / .mjs responses come through. Hit Export in the Deduped History tab to write deduped_requests.txt.
Requires Python 3.11+ and uv.
git clone https://github.com/titaniumtushar/burp-mcp-plus.git
cd burp-mcp-plus
uv sync
uv run pytest # offline tests; no Burp requiredThe configs below use four placeholders. Fill them in for your OS — quick reference at the bottom of this section.
Placeholder | What it is |
| Path to the |
| Path to |
| Where you cloned this repo |
|
|
Edit your Claude Desktop config file:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
Linux (unofficial builds only — Claude Desktop isn't officially distributed for Linux): ~/.config/Claude/claude_desktop_config.json
{
"mcpServers": {
"burp": {
"command": "<BURP_JAVA>",
"args": [
"-jar", "<BURP_MCP_JAR>",
"--sse-url", "http://127.0.0.1:9876"
]
},
"burp-plus": {
"command": "<UV>",
"args": [
"run", "--directory", "<REPO_DIR>", "burp-mcp-plus"
]
}
}
}(Sample at examples/claude_desktop_config.json.)
Restart the host. Tools appear as mcp__burp-plus__*.
Run from the repo directory (uses $PWD as <REPO_DIR>):
# Add the wrapper (user scope = available in every project)
claude mcp add burp-plus --scope user -- \
uv run --directory "$PWD" burp-mcp-plus
# Add the upstream Burp MCP too — substitute your <BURP_JAVA> and <BURP_MCP_JAR>
claude mcp add burp --scope user -- \
<BURP_JAVA> -jar <BURP_MCP_JAR> --sse-url http://127.0.0.1:9876On Windows PowerShell, replace $PWD with (Get-Location).Path. On cmd.exe, replace it with %CD%.
Verify with claude mcp list. Tools appear in any Claude Code session as mcp__burp-plus__* and mcp__burp__*. Use --scope project if you want it scoped to the current repo only (writes to .mcp.json), or --scope local for just-this-machine config.
Edit ~/.cursor/mcp.json (global, available in every workspace) — same path on macOS / Linux / Windows (Cursor maps ~ to your home dir on every OS). Create the file if it doesn't exist:
{
"mcpServers": {
"burp": {
"command": "<BURP_JAVA>",
"args": [
"-jar", "<BURP_MCP_JAR>",
"--sse-url", "http://127.0.0.1:9876"
]
},
"burp-plus": {
"command": "<UV>",
"args": [
"run", "--directory", "<REPO_DIR>", "burp-mcp-plus"
]
}
}
}Then: Cursor → Settings → MCP → toggle both servers on. The status dot should go green; if it stays red, click View logs in the same panel to see why. Use .cursor/mcp.json in a workspace root instead of ~/.cursor/mcp.json if you want it scoped to one project.
Same JSON shape, host-specific config path. The wrapper itself doesn't care which host launches it — all it needs is a stdio pipe.
<BURP_JAVA> — the JRE bundled inside Burp:
OS | Typical path |
macOS |
|
Linux |
|
Windows |
|
<BURP_MCP_JAR> — downloaded by Burp's BApp Store when you install the MCP Server extension:
OS | Typical path |
macOS / Linux |
|
Windows |
|
To find the exact path on your machine: find ~/.BurpSuite -name "*.jar" (macOS / Linux) or look in %APPDATA%\BurpSuite\bapps\ (Windows).
<REPO_DIR> — wherever you ran git clone. Get it with pwd (POSIX shells) or cd (Windows cmd).
<UV> — most users can just use "uv" (the literal string) and let the system PATH resolve it. If your MCP host can't find uv that way, use the absolute path:
Install method | Typical path |
macOS Homebrew (Apple Silicon) |
|
macOS Homebrew (Intel) |
|
Linux / |
|
Windows |
|
| check |
To find it: which uv (POSIX) or where uv (Windows).
burp-extension/deduped_history.py is a Jython extension that produces the dedup/JS exports the wrapper indexes.
Tab 1: Deduped History. Watches proxy traffic. Adds a row only when a new (method, host, path, parameters) tuple appears. Re-fires when new query/body parameter names show up on an endpoint. Export the whole thing to deduped_requests.txt.
Tab 2: JS Exporter. Watches for JavaScript responses, saves each unique JS file to <output>/<project>/<host>/<flattened-path>/<name>.js, writes a _manifest.csv. Detects version strings from filenames and content hashes.
Rough numbers from a typical pentest session:
Action | Upstream Burp MCP | burp-mcp-plus | Reduction |
List 50 history entries | ~60 KB | ~3 KB | 95% |
Search history (regex, 30 hits) | ~90 KB | ~4 KB | 95% |
Replay one auth'd request | ~5 KB request + ~5 KB confirmation | ~1 KB | 80% |
Find an endpoint in past triage | re-paginate proxy (~60 KB) | dedup_search (~600 B) | 99% |
Grep all JS for a pattern | not feasible | ~2 KB w/ snippets | — |
The wrapper's job is to keep the model focused on the smallest bytes that answer the question.
Burp Suite Pro 2025.x
Anthropic MCP Server BApp 1.x
Claude Desktop on macOS
Python 3.11, 3.12, 3.13
macOS arm64, Linux x86_64
Should work on Windows but I haven't tested it. Reports welcome.
This is a defensive tool for authorized testing. It's no more dangerous than Burp itself — but:
The MCP exposes your Burp's full power to whatever model you connect. Don't connect untrusted models.
File ingestion (dedup_*, js_*) reads paths you provide. There's no sandbox; treat the wrapper's host as trusted.
The wrapper doesn't authenticate to Burp's MCP — it relies on Burp's localhost-only binding. Don't expose Burp's MCP port externally.
Pentest scope discipline applies. The wrapper makes it easier to fire requests; it doesn't validate that you should.
Issues and PRs welcome. A few ground rules:
Tests stay green. uv run pytest before opening a PR. The builder in src/burp_mcp_plus/builder.py is pure logic and easy to test offline.
No new free-form content parameters. That's the whole anti-pattern this tool exists to prevent. Add structured fields instead.
Compact returns. If a new tool would return more than a few KB by default, add a limit / field / preview knob.
No hidden network calls. Tool side effects should be obvious from the name.
MIT.
PortSwigger — Burp Suite and the official MCP server.
Anthropic — the MCP spec and Python SDK.
Everyone running long pentest sessions who got tired of debugging "why did my LLM drop the Cookie header again."
Poll Burp Collaborator for received interactions.
Returns whatever Burp's get_collaborator_interactions returns. If
payload is given, the result is filtered to interactions referencing
that payload string (best-effort substring match).
| Name | Required | Description | Default |
|---|---|---|---|
| payload | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior. It explains the polling action, return value (underlying function), and filtering mechanism with substring match. Missing details on potential latency or error handling, but sufficient for a simple read tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: three sentences with no unnecessary words. Information is front-loaded and directly useful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a simple tool with one optional parameter and an output schema presumably documenting return values, the description covers core functionality. Minor gap: does not mention that it is typically used after collaborator_generate, but it remains complete enough for most use cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% parametric descriptions, but the description fully compensates by explaining the single parameter 'payload' as a substring filter with 'best-effort substring match'. This adds valuable meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool polls Burp Collaborator for received interactions, using a specific verb and resource. It distinguishes from sibling tools like collaborator_generate, which generates payloads.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. While context signals list sibling tools, the description does not explain prerequisites or context (e.g., after generating a payload with collaborator_generate).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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_check to see who phoned home.
| Name | Required | Description | Default |
|---|---|---|---|
| count | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses the OOB testing nature and the need to save payloads for later checking. However, it could mention that generated payloads are unique and time-limited, though not strictly required.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: two short paragraphs, front-loaded with the action and purpose, no wasted words. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple parameter (count) and presence of output schema, the description fully covers what the agent needs: what the tool does, how to use it, and next steps. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% (no descriptions in schema), but description compensates by implying 'count' through 'one or more'. It adds value by explaining how to use the parameter (generate multiple). Could explicitly mention 'count' default, but still strong.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (generate), resource (Burp Collaborator payloads), and purpose (out-of-band injection canaries). It distinguishes from siblings like collaborator_check by specifying a different role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use this tool: for SSRF, blind XSS, OOB SQLi, etc. It also provides the workflow: generate, save, plant, then poll collaborator_check, which guides the agent on the correct sequence.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch a dedup entry by its 1-based index.
By default returns metadata + truncated request/response previews. Set
full=True to get the complete raw request and response.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| index | Yes | ||
| full | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It clearly states that by default it returns metadata plus truncated previews, and setting full=True gives complete raw data. This provides a solid behavioral contract, though it avoids discussing error behavior or index bounds.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two-sentence description: first sentence states purpose, second explains default behavior and option. No extraneous text, efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Has output schema, so return values do not need detailed explanation. Description covers default vs full modes adequately. Could mention that entries are from a dedup store or index validity, but overall complete for its complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. Description clarifies that index is 1-based and full is a boolean for full vs truncated output. However, the 'name' parameter is not explained, leaving its purpose ambiguous. The description adds value but not complete coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Fetch a dedup entry by its 1-based index', identifying the action and resource. It distinguishes from siblings like dedup_list (lists all) and dedup_search (searches) by specifying indexed retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like dedup_list or dedup_search. The context of '1-based index' implies usage when the index is known, but no when-not-to or alternative references are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all registered dedup sources.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. However, it only states the operation without mentioning side effects, permissions, or that it is a safe read operation, leaving ambiguity about behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no extraneous information, perfectly concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and includes an output schema, the description sufficiently conveys the purpose. It does not need to explain return values as the schema covers that, and for a simple list-all function, it is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters (100% coverage trivially), and the description does not need to add parameter meaning. Baseline for 0 parameters is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all registered dedup sources' uses a specific verb ('list') and clearly identifies the resource ('registered dedup sources'), distinguishing it from siblings like dedup_get and dedup_search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for listing all possible sources, but provides no explicit guidance on when to use this tool versus alternatives (e.g., dedup_search for filtered queries, dedup_get for individual source details).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Load a deduped_requests.txt file produced by the user's Burp
Deduped HTTP History + JS Exporter extension.
path: filesystem path (absolute or ~-expandable).
name: identifier to address this source by in later calls. Default:
parent directory name.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | ||
| name | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavior. It only states 'load' without explaining side effects, permissions, or what happens on load (e.g., parsing, storage). The presence of an output schema is not leveraged to describe output.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences and parameter definitions, front-loaded with the core action. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains parameters but omits behavioral details like error handling or output format. Given the output schema exists, the description could be more complete about the loading process, making it adequate but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description adds meaningful detail: path is filesystem path (absolute or ~-expandable), name is an identifier defaulting to parent directory name. This goes beyond the schema's type-only definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool loads a 'deduped_requests.txt' file from a specific Burp extension, using a specific verb and resource. This distinguishes it from sibling tools like dedup_get and dedup_list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for loading files from the named extension, but it does not explicitly state when to use this tool versus alternatives (e.g., dedup_get for already-loaded data). Some context is provided but no direct comparison.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Regex-search a registered dedup source.
field: one of url, request, response, params, or all.
Returns matches with index + url + status + a short snippet (token-thrifty).
Use dedup_get to fetch the full request/response.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| pattern | Yes | ||
| field | No | url | |
| limit | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility. It discloses the token-thrifty nature (short snippet) and regex search behavior, but lacks details on error handling, case sensitivity, or performance implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief yet complete, using a list for field values and separate lines for clarity. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the existence of an output schema and siblings, the description adequately explains the tool's purpose, parameters, and return format. It could mention how to discover valid 'name' values (via dedup_list), but overall is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description partially compensates by explaining the 'field' parameter options and implying 'pattern' is a regex. However, 'name' and 'limit' are not elaborated, leaving gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies a clear verb ('Regex-search') and resource ('registered dedup source'), enumerates field options, and states the return format (index, url, status, snippet). It distinguishes itself from the sibling tool dedup_get, which fetches full data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides guidance on field values and explicitly directs to use dedup_get for full request/response, offering an alternative. However, it does not include explicit when-to-use or when-not-to-use context relative to other siblings like dedup_list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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
create_repeater_tab.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| index | Yes | ||
| tab_name | No | ||
| method | No | ||
| path | No | ||
| set_headers | No | ||
| remove_headers | No | ||
| body | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It explains that the dedup entry provides baseline cookies/UA, overrides can be applied, and the wrapper uses Burp's API. However, it does not disclose side effects, permissions needed, or error conditions, leaving gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences that are front-loaded with purpose, then provide behavioral detail. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (8 params, no per-param docs) and presence of an output schema, the description provides sufficient high-level context but lacks detail on prerequisites (e.g., must have dedup entries loaded) and return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'optional structured overrides' but does not individually explain any of the 8 parameters (name, index, tab_name, etc.), leaving agents to infer meanings from names alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Send' and the resource 'a dedup entry to Burp Repeater', and adds context about optional overrides and baseline inheritance, which distinguishes it from sibling tools like repeater_from_history.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as repeater_from_history or intruder_from_history. The description does not provide when-not-to-use or selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch and pretty-print a Burp proxy history entry by index.
history_id is the 0-based index into the most recent page_size entries
(Burp's MCP doesn't expose stable IDs; addressing is positional).
Use this to inspect cookies/headers before crafting a mutated request.
| Name | Required | Description | Default |
|---|---|---|---|
| history_id | Yes | ||
| page_size | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explains the positional addressing limitation ('Burp's MCP doesn't expose stable IDs; addressing is positional') and that the tool fetches from proxy history. It does not mention return format, but an output schema exists to cover that.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, with two short paragraphs. The first sentence immediately states the purpose. Inline code clarifies the parameter semantics. The usage guidance adds context without unnecessary detail. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists (documenting return values), the description covers all essential aspects: purpose, parameter semantics, behavioral quirk (positional addressing), and usage context. An agent has enough information to select and correctly invoke this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate. It fully explains both parameters: history_id is a 0-based index into the most recent page_size entries, and page_size determines the window. This adds significant meaning beyond the schema's bare titles and types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Fetch and pretty-print') and the resource ('Burp proxy history entry by index'), making the purpose immediately clear. It distinguishes from sibling tools like list_history and search_history by specifying inspection of a single entry by positional index.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a concrete usage scenario: 'Use this to inspect cookies/headers before crafting a mutated request.' This helps an agent decide when to invoke this tool. However, it does not explicitly list alternatives or when not to use it, which would have made it stronger.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send a request to Burp Intruder, built from a history baseline.
payload_markers: list of substrings in the final request to wrap with
Burp's '§' insertion markers. The substring must appear verbatim in the
final wire format (after overrides are applied). Markers are added in
order; duplicate substrings are wrapped only once each.
| Name | Required | Description | Default |
|---|---|---|---|
| history_id | Yes | ||
| tab_name | No | ||
| method | No | ||
| path | No | ||
| set_headers | No | ||
| remove_headers | No | ||
| body | No | ||
| payload_markers | No | ||
| page_size | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description details the behavior of payload_markers (order, duplicate handling) but omits other behavioral traits such as whether the original history entry is modified, authentication requirements, or rate limits. Since no annotations are provided, this is a moderate effort.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the main purpose, then details payload_markers. It uses two concise sentences without superfluous words, though it could benefit from listing other parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 9 parameters and an output schema, the description is very incomplete. It covers only one parameter and lacks context on the rest, making it difficult for an agent to use the tool correctly without additional knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain parameters. It only explains payload_markers, leaving eight other parameters (tab_name, method, path, set_headers, remove_headers, body, page_size, history_id) completely undescribed. This is insufficient for a 9-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose ('Send a request to Burp Intruder, built from a history baseline'), but does not differentiate it from sibling tools like repeater_from_history, which have similar names and operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., repeater_from_history). The description does not mention context, prerequisites, or scenarios where this tool is preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List JS files in a source, optionally filtered by host regex.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| host_filter | No | ||
| limit | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must carry full burden. It discloses basic behavior (list, filter) but omits details like read-only nature, authentication needs, or what 'source' means. The description adds little beyond the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with key action. Concise but sacrifices necessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given three parameters and no annotations, the description is insufficient. It does not explain 'name' or 'limit', nor differentiate from sibling list tools. An output schema exists, so return values are covered, but input semantics are lacking.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%; description only hints at host_filter purpose. The required parameter 'name' and optional 'limit' are not explained at all, leaving the agent to infer meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists JS files in a source with optional host regex filtering. However, it does not distinguish from sibling tool 'js_list', which could be similar.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives (e.g., js_list, js_search). No exclusions or prerequisites mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all registered JS sources.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It only states 'List all registered JS sources' without mentioning side effects, permissions, or whether it is read-only. The description lacks crucial behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, straightforward sentence with no unnecessary words. It is concise but could benefit from additional structure or context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, existing output schema), the description is largely adequate. It explains the core functionality, and the output schema can provide return value details. However, it could be more complete by noting that the list includes all sources without filtering.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so schema description coverage is trivially 100%. The description adds no parameter-specific information, but none is needed. A baseline of 3 is appropriate, raised slightly due to the absence of required elaboration.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'List' and the resource 'registered JS sources'. It is specific and distinguishes from siblings like 'js_search' or 'js_files', though it does not explicitly differentiate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'js_search' for filtering. There are no use case examples or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Load a _manifest.csv produced by the JS Exporter side of the user's
Burp extension.
| Name | Required | Description | Default |
|---|---|---|---|
| manifest_path | Yes | ||
| name | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits, but it only states 'Load a _manifest.csv'. It does not mention side effects, whether it modifies state, requires authentication, or any other operational details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, making it concise, but it lacks necessary detail. It is not well-structured to convey the core functionality effectively.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the existence of an output schema and two parameters, the description is severely incomplete. It fails to explain what the tool does with the manifest, expected output, or parameter constraints.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% parameter description coverage, and the description adds no meaning to the parameters (manifest_path, name). The agent gets no clues about what these parameters represent or how to use them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool loads a _manifest.csv file, which is a specific resource and action. However, it does not differentiate from sibling tools like js_read or js_list, leaving ambiguity about what 'load' entails versus 'read'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description does not mention any prerequisites, context, or scenarios where js_load is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read one JS file from a source.
ref: either the integer index (as string), the full URL, the path, the
saved_as path, or the basename. The first matching record wins.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| ref | Yes | ||
| max_bytes | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden for behavioral disclosure. It explains the ref parameter flexibility but omits critical details like what the output contains (e.g., file content, metadata), error behavior (e.g., file not found), and side effects. The max_bytes parameter is not explained.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: two sentences. The first states the purpose, the second explains the ref parameter. Information is front-loaded and every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description is incomplete. It fails to describe what the tool returns (e.g., file content), does not explain the name and max_bytes parameters, and omits error handling or size limit behavior, making it insufficient for reliable use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must add meaning. It does for ref, detailing multiple formats (integer index, full URL, path, saved_as path, basename) and that the first match wins. However, it does not explain the 'name' parameter or 'max_bytes', leaving those unclear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Read one JS file from a source,' specifying the verb (read) and resource (JS file). This distinguishes it from sibling tools like js_list (list files), js_search (search), and js_load (load bulk), which have different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention context, prerequisites, or exclusions, leaving the agent to infer usage solely from the name and purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Grep across all on-disk JS files in a source.
Returns file:line + small context snippets (token-thrifty). Use js_read
to fetch full content for files of interest.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| pattern | Yes | ||
| limit | No | ||
| max_matches_per_file | No | ||
| context | No | ||
| host_filter | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must carry burden. It reveals output format and token thriftiness but does not explicitly state it's read-only or mention permissions. Adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with clear front-loading of purpose. No extraneous information; every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 params and no schema descriptions, the description is thin. Output format is noted, but missing details on pattern syntax, source definition, and parameter constraints. Adequate for a simple tool but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description fails to explain any parameters. The agent must rely on parameter names and defaults, which is insufficient for proper usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it performs a grep across on-disk JS files, specifying the verb and resource. It also distinguishes itself from sibling tool js_read for fetching full content.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Describes when to use (searching JS files) and suggests alternative js_read for full content. However, it does not explicitly exclude cases like non-JS files or other siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List recent Burp proxy history entries with their history_index.
Use this to browse and find an entry to feed into the repeater/intruder tools when a regex search isn't precise enough.
| Name | Required | Description | Default |
|---|---|---|---|
| count | No | ||
| offset | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behaviors. It doesn't mention ordering (e.g., reverse chronological), pagination details beyond the parameters, or any limits. It adds 'recent' but is vague.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: first states purpose, second provides usage guidance. No redundancy, front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with pagination parameters and an output schema (not shown), the description is mostly adequate but lacks details on ordering (e.g., recent by time) and pagination usage. Given sibling tools, it could mention that history entries are from the current project.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% coverage, and description does not explain count or offset parameters. While names are self-explanatory, description should clarify their role (e.g., pagination) to add value beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it lists Burp proxy history entries with history_index, distinguishing it from search_history (regex search) and repeater_from_history (which sends one entry to repeater).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says to use this when regex search isn't precise enough, and mentions feeding entries into repeater/intruder tools, providing clear context for when to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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
| Name | Required | Description | Default |
|---|---|---|---|
| history_id | Yes | ||
| tab_name | No | ||
| method | No | ||
| path | No | ||
| set_headers | No | ||
| remove_headers | No | ||
| body | No | ||
| page_size | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that the baseline contributes Host, cookies, auth, UA, etc., and overrides modify only specified fields. It also explains the page_size parameter for scanning history. However, it does not discuss behavior on missing id, conflicting overrides, or error states.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (about 10 lines) and well-structured: a clear one-sentence purpose, a brief explanation of the baseline concept, and a bulleted list of arguments. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers input parameters well and acknowledges an output schema exists. However, it omits prerequisites (e.g., having a history entry), possible errors, or the fact that it opens a new Repeater tab. Still, it is fairly complete for a tool with an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the tool description's Args section provides essential meaning. Each parameter (history_id, tab_name, method, etc.) is briefly explained. While not exhaustive, the descriptions are sufficient to interpret parameter purposes and defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: 'Send a request to Burp Repeater, built from a history baseline plus optional structured overrides.' It specifies the resource (Burp Repeater using history) and distinguishes from siblings like 'repeater_from_template' by emphasizing the baseline and overrides.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context but does not explicitly instruct when to use this tool versus alternatives (e.g., repeater_from_template, intruder_from_history). It mentions scanning history entries to find the id, which hints at a use case, but lacks direct guidance on when-not or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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
headers arg then overrides them. Host/Content-Length always
re-derived from the new url+body.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| method | No | GET | |
| headers | No | ||
| body | No | ||
| tab_name | No | ||
| inherit_from_history_id | No | ||
| page_size | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explains key behavioral traits: inheritance mechanism (inherit_from_history_id copies headers, then headers arg overrides), automatic re-derivation of Host/Content-Length. However, it does not mention error handling, rate limits, or output behavior. Since no annotations are provided, the description shoulders the burden well but has minor gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: a single-paragraph overview followed by a bulleted list of arguments. Every sentence adds value, and the structure is clear. No extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While parameter semantics are well-covered, the context is incomplete: no explanation of return values (though output schema exists, it's not referenced), no mention of prerequisites, error cases, or success cues. For a tool with 7 parameters and no annotations, more contextual completeness is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds significant meaning for all parameters: URL includes an example, method default is stated, headers override inherited, body, tab_name, and inheritance mechanics are explained. This compensates fully for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Send' and the resource 'Burp Repeater', and specifies it's built from scratch with URL and structured fields. It distinguishes from siblings like 'repeater_from_history' by emphasizing 'from scratch' and optional inheritance.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for constructing a new request from scratch with optional inheritance, but does not explicitly state when to use this tool versus alternatives like 'send_request' or 'intruder_from_history'. No clear 'when not to use' guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Burp proxy history with a regex; returns a compact list of
matching entries with their history_index (0-based position in the
returned page). Feed history_index into the other tools as history_id.
| Name | Required | Description | Default |
|---|---|---|---|
| regex | Yes | ||
| count | No | ||
| offset | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description only states it searches and returns results. No disclosure of read-only nature, side effects, rate limits, or other behavioral traits. For a search tool with no annotations, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first defines action and output, second gives usage instructions. Perfectly front-loaded with no filler. Every sentence is valuable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a search tool with output schema (present, so return value details covered). Lacks parameter descriptions and pagination guidance, but covers the key integration point (history_index). Could be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage 0%; description only mentions regex (implied) and history_index (returned, not parameter). No explanation of count (pagination size) or offset (page offset). Adds minimal value beyond the schema's field names and defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states verb 'Search', resource 'Burp proxy history', and method 'with a regex'. Differentiates from siblings like list_history and inspect_history_entry by specifying regex search and returning compact list with history_index. Also explains how history_index feeds into other tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage for regex-based searches and hints at integration with other tools via history_index. However, no explicit exclusions or when-not-to-use guidance compared to alternatives like inspect_history_entry or list_history.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Issue an HTTP/1.1 request via Burp (no Repeater tab) and return the response. Two usage modes:
Mutate a history entry: pass history_id plus any of method/path/
set_headers/remove_headers/body.
Build from scratch: pass url + method + headers + body. Optionally
inherit_from_history_id to copy cookies/auth from a baseline.
| Name | Required | Description | Default |
|---|---|---|---|
| history_id | No | ||
| url | No | ||
| method | No | ||
| path | No | ||
| set_headers | No | ||
| remove_headers | No | ||
| headers | No | ||
| body | No | ||
| inherit_from_history_id | No | ||
| page_size | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility. It states the tool issues an HTTP/1.1 request, does not open a Repeater tab, and returns the response. It also explains the mutation mode modifies a history entry. It does not cover potential side effects like rate limiting or authentication details, but the core behavior is clear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, with two usage modes clearly listed. Every sentence adds value without redundancy. It is appropriately front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is mostly complete given the existence of an output schema (which explains return values). It covers parameters, modes, and behavior. However, it lacks examples or error handling info, and the page_size parameter is undocumented. For a complex tool with 10 parameters, it is adequate but not exhaustive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It explains 9 of 10 parameters (history_id, url, method, path, set_headers, remove_headers, headers, body, inherit_from_history_id) but does not mention 'page_size', which has a default of 200 and likely controls response pagination. This is a minor gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Issue an HTTP/1.1 request via Burp (no Repeater tab) and return the response.' It specifies the exact function (sending a request) and distinguishes it from siblings like 'repeater_from_history' by noting it does not open a Repeater tab.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on two usage modes (mutate history entry or build from scratch) and when to use each. It mentions optional parameter inheritance. However, it does not explicitly state when not to use this tool or suggest alternatives like Repeater or inspect_history_entry.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 host_filter (regex) to scope to a specific target.
| Name | Required | Description | Default |
|---|---|---|---|
| host_filter | No | ||
| page_size | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes the tool's behavior (reading proxy history, grouping, counting) and output format. However, with no annotations, it fails to disclose potential side effects, auth needs, or limits. It implies a read operation but does not explicitly state non-destructive nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Fairly concise and front-loaded with the action. The output format is well described, but some minor redundancy or missing details slightly reduce clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists and the tool has two parameters, the description provides some context but lacks explanation for page_size and usage scenarios. It covers the structure but misses completeness for a 2-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Description explains host_filter as a regex for scoping, adding meaning beyond the schema (which has 0% coverage). However, page_size is not mentioned at all, leaving its purpose unclear. Description covers only one of two parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool builds a sitemap from Burp proxy history, groups entries, counts occurrences, and returns a specific tree-style JSON. This distinctly describes its function and differentiates it from sibling tools like dedup_* or search_history.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides some context by noting there is no upstream Target tool, implying it's the sole sitemap builder. It mentions using host_filter for scoping, but does not specify when to use this tool versus alternatives or provide explicit when-not scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Agent-readiness scanner (0-5 score), robots.txt + llms.txt generators, managed agent enablement.
The WAF for agents. Pattern-based + heuristic firewall scans prompts, RAG documents, tool argume...
Turn PRDs and product ideas into structured specs so coding agents build your intent, not theirs.
OCR, transcription, file extraction, and image generation for AI agents via MCP.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/titaniumtushar/burp-mcp-plus'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
