Burpsuite MCP Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| BURP_API_KEY | Yes | The API key generated in Settings > Suite > REST API | |
| BURP_API_URL | Yes | Base URL of Burp's REST API service, e.g. http://localhost:1337 |
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
Server capabilities have not been inspected yet.
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| start_scanC | Start a new vulnerability scan on a target URL |
| get_scan_statusC | Check the status of a running scan |
| get_scan_issuesC | Get vulnerability issues found in a scan |
| get_proxy_historyC | Get HTTP/HTTPS traffic captured by Burp Proxy |
| get_site_mapB | Get the site structure discovered during scanning and browsing |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| Proxy History | HTTP/HTTPS traffic captured by Burp Proxy |
| Site Map | Structure of discovered websites |
TDQS
Scored across 5 tools
Each tool has a clearly distinct purpose with no overlap: get_proxy_history retrieves captured traffic, get_scan_issues fetches vulnerability findings, get_scan_status checks scan progress, get_site_map provides site structure, and start_scan initiates new scans. The descriptions make it unambiguous which tool to use for each specific task.
All tools follow a consistent verb_noun pattern with 'get_' or 'start_' prefixes followed by descriptive nouns (proxy_history, scan_issues, scan_status, site_map, scan). This uniform snake_case naming makes the tool set predictable and easy to understand.
Five tools is reasonable for a BurpSuite security testing server, covering core functions like traffic capture, scanning, and results retrieval. While slightly lean, it provides essential operations without being overwhelming. A few additional tools for scan configuration or issue management could enhance completeness but aren't critical.
The tools cover basic scanning workflow (start, check status, get results) and proxy history, but lack operations for managing scans (e.g., pause, stop, configure) or interacting with issues (e.g., export, filter, annotate). This creates minor gaps that agents might need to work around, though core functionality is present.