The Burp Suite MCP Server exposes Burp Suite's REST API as tools for AI assistants, enabling automated web application security scanning and vulnerability management.
Scan URLs for vulnerabilities – Initiate security scans against one or more target URLs, with optional scope configuration, and receive a task_id for tracking.
Check scan progress – Retrieve real-time scan status and findings by task_id, with the ability to filter results by severity (low, info, medium, high, or all).
Get scan summary – Obtain a high-level overview of scan results showing issue counts grouped by severity.
Wait for scan completion – Poll a scan until it finishes or a timeout is reached, with configurable polling interval — useful for CI/CD pipelines.
List active scans – View all currently running or pending scans (availability depends on Burp API version).
Cancel a scan – Stop an in-progress scan by its task_id (availability depends on Burp API version).
Query security issue definitions – Access Burp Suite's built-in knowledge base, including vulnerability names, descriptions, remediation guidance, and references.
Check Burp connectivity – Validate the connection and configuration to the Burp Suite REST API.
Allows interaction with Burp Suite's REST API to trigger vulnerability scans, monitor scan progress, retrieve security findings, and query Burp's security knowledge base.
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 Suite MCP Server Scan https://example.com and alert me of any high severity vulnerabilities"
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.
An MCP (Model Context Protocol) server that exposes Burp Suite's REST API as tools for AI assistants. Use Cursor or other MCP clients to trigger vulnerability scans, check progress, and query Burp's security knowledge base.
Burp Suite Professional (or Burp Suite DAST) with the REST API enabled
Python 3.11+
Burp running locally with REST API bound to a reachable address (e.g. http://127.0.0.1:1337)
Related MCP server: MCPPentestBOT
Open Burp Suite → Settings → Suite → REST API
Check Service running
Set the URL/port (e.g. port 1337)
Create an API key and copy it
uv sync # or: pip install -e .Copy .env.example to .env and fill in your values:
cp .env.example .envEdit .env:
BURP_REST_API_BASE=http://127.0.0.1:1337
BURP_REST_API_KEY=your-api-key-here
BURP_REST_API_VERSION=v0.1The server supports three transports, selected with --transport:
Flag | Transport | Use case |
| stdio (default) | Local MCP clients (Cursor, Claude Desktop) |
| Server-Sent Events | HTTP clients using the legacy SSE protocol |
| Streamable HTTP | HTTP clients using the modern MCP HTTP protocol |
For sse and http, bind address and port are configurable:
# Default: localhost only, port 8000
uv run python main.py --transport http
# Expose on all interfaces, custom port
uv run python main.py --transport http --host 0.0.0.0 --port 9000
# SSE transport
uv run python main.py --transport sse --host 127.0.0.1 --port 8000Add to your Cursor MCP config (e.g. ~/.cursor/mcp.json or project .cursor/mcp.json):
{
"mcpServers": {
"burp-suite": {
"command": "uv",
"args": ["run", "python", "/path/to/burp-mcp/main.py"],
"cwd": "/path/to/burp-mcp"
}
}
}Start the server with HTTP transport, then point your MCP client at it:
uv run python main.py --transport http --host 0.0.0.0 --port 8000{
"mcpServers": {
"burp-suite": {
"url": "http://localhost:8000/mcp"
}
}
}Tool | Description |
| Get Burp's security issue definitions (name, description, remediation, references) |
| Start a scan for given URLs. Returns a |
| Get scan status and findings by |
| High-level summary: total issues by severity |
| List running/pending scans (may not be supported by all Burp API versions) |
| Cancel a scan by task_id (may not be supported by all Burp API versions) |
| Test connectivity to Burp API; validates config |
| Poll until scan completes or times out (for CI/CD) |
Scan a URL:
"Scan https://example.com for vulnerabilities"
Check scan progress:
"Check scan progress for task_id 123"
Get high-severity issues only:
"Check scan 123 and show only high severity issues"
Security knowledge:
"What security issues does Burp know about?"
Run scans from scripts or the terminal:
uv run python examples/ci-scan.py https://your-target.com
# or
./examples/ci-scan.sh https://your-target.comEndpoint | Method | Description |
| GET | Security issue definitions |
| POST | Start scan (body: |
| GET | List scans (may not be supported) |
| GET | Scan progress and results |
| DELETE | Cancel scan (may not be supported) |
Interactive API docs: [BURP_REST_API_BASE]/[API_KEY]
MIT
Get all Burp Suite security issue definitions (name, description, remediation, references).
| 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 carries the full disclosure burden. It adds value by listing the returned data fields (name, description, remediation, references), but omits operational details like data volume ('all' implies large), caching behavior, or whether Burp must be running.
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, efficient sentence with no redundant words. Every element serves a purpose: the action verb, the scope ('all'), the resource, and the output field preview.
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 low complexity (no inputs) and existence of an output schema, the description is appropriately complete. It previews the return structure without redundantly documenting the full output schema, though noting it retrieves static reference data versus live findings would improve completeness.
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 contains zero parameters, which establishes a baseline score of 4. The description appropriately does not fabricate parameter details, though the parenthetical field list could be misinterpreted as parameter documentation.
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 specific verb ('Get') and resource ('Burp Suite security issue definitions'), distinguishing it from sibling scan-operation tools like scan_urls_for_vulnerabilities or get_scan_summary which handle dynamic scan execution and results.
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?
While the tool's purpose is distinct from operational scan management siblings (implied by 'definitions' vs 'scan'), there is no explicit guidance on when to use this versus get_scan_summary for actual findings, or prerequisites like requiring Burp connectivity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Cancel a scan by task_id. May not be supported by all Burp API versions.
Args:
task_id: Task ID of the scan to cancel
| Name | Required | Description | Default |
|---|---|---|---|
| task_id | Yes |
| 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 adds the version compatibility warning but fails to disclose critical mutation behaviors: whether cancellation preserves partial results, if the operation is reversible, error handling for invalid task IDs, or whether this is a graceful or forceful termination.
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 appropriately brief with no filler. It front-loads the action in the first sentence and uses a standard docstring Args format for the single parameter. The version warning is appropriately placed as a secondary caveat.
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 only one parameter and an output schema exists (relieving the description from explaining return values), the description is minimally complete. However, for a destructive operation with no annotations, it lacks important context about side effects or data retention that would aid an agent in making informed invocation decisions.
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%, requiring the description to compensate. The Args section provides basic semantics ('Task ID of the scan to cancel'), which minimally compensates for the lack of schema documentation, though it does not clarify the dual-type nature (string/integer) or source of the task_id.
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 'Cancel[s] a scan by task_id,' providing a specific verb and resource. However, it does not explicitly differentiate from the sibling tool 'wait_for_scan_completion' regarding when to cancel versus allowing a scan to finish naturally.
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 notes a version compatibility constraint ('May not be supported by all Burp API versions'), but provides no guidance on when to use cancellation versus alternatives like waiting for completion, nor does it mention prerequisites or data retention implications.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Test connectivity to the Burp REST API. Validates config and performs a simple request.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| 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 adds useful context that the tool validates configuration and performs a simple request, but lacks details on error handling, idempotency, or what specific connectivity failures look like.
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 efficient sentences with zero waste. The first sentence establishes the core purpose (testing connectivity), and the second clarifies the mechanism (config validation and simple request), making it appropriately front-loaded for a no-argument utility function.
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 (zero parameters) and the presence of an output schema, the description adequately covers what the tool does without needing to explain return values. A minor gap is the lack of error scenario documentation, but this is sufficient for a health check utility.
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 tool has zero parameters, which per guidelines establishes a baseline of 4. The description does not need to compensate for missing parameter documentation since the schema is trivially complete at 100% 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?
The description clearly states the tool tests connectivity to the Burp REST API and distinguishes itself from scanning-focused siblings (scan_urls_for_vulnerabilities, cancel_scan, etc.) by specifying it validates configuration and performs a simple request rather than actual security testing.
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?
While the description implies this is a diagnostic/health check tool, it lacks explicit guidance on when to use it (e.g., 'use before scanning operations' or 'call when troubleshooting connection issues') or sequencing relative to the other Burp suite tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieves scan progress and details using the task_id.
Args:
task_id: Task ID from an initiated scan (numeric ID or full path)
severity: Filter issues: low, info, medium, high, or "all" (default)
| Name | Required | Description | Default |
|---|---|---|---|
| task_id | Yes | ||
| severity | No | all |
| 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. It successfully discloses that the severity parameter filters issues in the results (behavioral trait). However, it omits other operational context like read-only safety, error handling for invalid task_ids, or rate limit 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?
Highly efficient structure with zero waste. Front-loaded purpose statement followed by Args section. Every sentence earns its place; the severity filter documentation doubles as parameter description and behavioral disclosure.
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?
Appropriately complete given the existence of an output schema (which handles return value documentation). Input parameters are fully covered. Minor gap: does not state the read-only/safe nature of the operation, which would be helpful given the absence of annotations.
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?
Excellent compensation for 0% schema description coverage. Documents both parameters thoroughly: task_id includes format guidance ('numeric ID or full path') and source context ('from an initiated scan'), while severity enumerates valid values ('low, info, medium, high') and default behavior ('all').
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?
States specific action (retrieves) and target (scan progress and details) clearly. Mentions the required task_id input. However, it does not explicitly differentiate from sibling tools like get_scan_summary or wait_for_scan_completion, which could cause selection ambiguity.
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 prerequisite by stating task_id comes 'from an initiated scan,' but provides no explicit guidance on when to use this tool versus alternatives like get_scan_summary or wait_for_scan_completion. No 'when-not-to-use' or alternative recommendations are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a high-level summary of scan results: total issues by severity.
Args:
task_id: Task ID from an initiated scan
| Name | Required | Description | Default |
|---|---|---|---|
| task_id | Yes |
| 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. It adds valuable behavioral context by specifying the aggregation level ('total issues by severity'), indicating the output is counts rather than detailed findings. However, it omits safety characteristics (read-only nature), error handling for invalid task IDs, or whether this consumes API quotas.
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 tight with zero waste: one sentence for purpose, one line for the parameter explanation. The 'Args:' format is efficient and scannable. Every word 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 the tool's simplicity (single parameter), the presence of an output schema (handling return value documentation), and the description's compensation for zero schema coverage, the description is appropriately complete. It covers the essential semantic and usage context needed for an agent to invoke the tool correctly.
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% (only title 'Task Id' exists). The description compensates effectively by explaining that task_id is 'from an initiated scan,' providing critical semantic context about the parameter's origin and expected value source that the schema lacks.
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 (Get), resource (scan results), and specific scope (high-level summary, total issues by severity). It implicitly distinguishes from siblings like check_security_scan_progress (which checks status) and scan_urls_for_vulnerabilities (which initiates), though it could explicitly clarify this is for completed/completing scans.
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 prerequisites by noting the task_id comes from 'an initiated scan,' suggesting when to use it (after starting a scan). However, it lacks explicit guidance on when to use this versus check_security_scan_progress or wait_for_scan_completion, and doesn't mention if the scan must be finished.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List running and pending scans. May not be supported by all Burp API versions.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| 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 disclosure burden. It adds the API version compatibility caveat, but lacks details on pagination, error handling when no scans exist, or whether 'pending' includes paused vs. queued 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?
Two sentences with zero redundancy: first states core function, second states critical limitation. Every word 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 the presence of an output schema (not shown but indicated), the description appropriately omits return value details. It adequately covers the simple list functionality, though could clarify if 'active' excludes completed/failed scans explicitly.
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, which per guidelines establishes a baseline of 4. The description appropriately does not invent parameter documentation where none exist.
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 'List[s] running and pending scans' with specific verbs and scope. It implicitly distinguishes from siblings like get_scan_summary (single scan details) and cancel_scan (action on specific scan) by emphasizing the 'list' aggregation function.
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?
While it warns 'May not be supported by all Burp API versions,' it provides no guidance on when to use this versus check_security_scan_progress or get_scan_summary, nor does it mention prerequisites like requiring an active Burp connection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Scan URL(s) for security vulnerabilities.
Args:
urls: List of URLs to scan
scope: Optional scope configuration (passed to API if supported)
| Name | Required | Description | Default |
|---|---|---|---|
| urls | Yes | ||
| scope | 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 full disclosure burden but reveals minimal behavioral traits. It fails to mention whether the scan is asynchronous (implied by wait_for_scan_completion sibling), duration expectations, destructive potential, or auth requirements. Only behavioral hint is the parenthetical '(passed to API if supported)' regarding scope handling.
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 with no wasted words. The 'Args:' format efficiently delivers parameter documentation necessitated by the empty schema. Main purpose is front-loaded in the first sentence. Minor mechanical feel due to docstring-style formatting, but appropriate for the information density required.
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 (covering return values), the description inadequately contextualizes the tool within the evident workflow. Given siblings like wait_for_scan_completion and check_security_scan_progress, the description should explicitly state that this initiates a potentially long-running asynchronous scan requiring subsequent monitoring, which is absent.
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?
Given 0% schema description coverage, the description compensates by documenting both parameters: urls is a 'List of URLs to scan' and scope is 'Optional scope configuration'. However, 'scope configuration' lacks semantic depth—no indication of expected format, valid values, or purpose. Baseline compensation achieved but not enriched semantics.
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 'Scan URL(s) for security vulnerabilities', identifying the verb (scan), resource (URLs), and objective (security vulnerabilities). It sufficiently distinguishes from siblings like check_burp_connectivity or cancel_scan, though it could explicitly state it 'initiates' a scan to contrast with check_security_scan_progress.
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 provided on when to use this tool versus siblings like check_security_scan_progress or wait_for_scan_completion. No mention of prerequisites (e.g., checking connectivity first) or workflow sequencing, which is critical given the sibling tools suggest an async multi-step process.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Poll scan progress until the scan completes or times out.
Useful for long-running scans in CI/CD.
Args:
task_id: Task ID from an initiated scan
poll_interval_seconds: Seconds between polls (default: 10)
max_wait_seconds: Maximum time to wait (default: 3600 = 1 hour)
| Name | Required | Description | Default |
|---|---|---|---|
| task_id | Yes | ||
| poll_interval_seconds | No | ||
| max_wait_seconds | 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 successfully conveys the polling mechanism and timeout concept, but omits critical behavioral details: whether the tool blocks execution during waiting, what specific value/object is returned upon completion vs. timeout, and whether timeout raises an exception or returns a specific status.
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?
Highly efficient structure with zero waste. The description uses two sentences for purpose and context, followed by a clean Args section that mirrors the schema parameters exactly. Information density is high with no filler text.
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 3-parameter complexity with 0% schema coverage, the description successfully documents all inputs. Since an output schema exists, the description appropriately doesn't detail return values, though it could briefly mention what successful completion yields (e.g., final scan status) to aid agent decision-making.
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?
Excellent compensation for 0% schema description coverage. The Args section clearly defines all three parameters: 'task_id' is contextualized as coming from 'an initiated scan,' and both optional parameters include their default values with helpful unit explanations ('default: 3600 = 1 hour'). This provides complete semantic meaning missing from the structured 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 'Poll scan progress until the scan completes or times out,' specifying the verb (poll), resource (scan progress), and termination conditions. However, it doesn't explicitly differentiate from the sibling tool 'check_security_scan_progress,' which likely performs a single check rather than continuous polling.
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 context with 'Useful for long-running scans in CI/CD,' indicating appropriate usage scenarios. However, it lacks explicit guidance on when NOT to use this (e.g., for quick checks) or mention of the sibling 'check_security_scan_progress' as a lightweight alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.0burp_suite_security_issue_definitionscancel_scancheck_burp_connectivitycheck_security_scan_progressget_scan_summarylist_active_scansscan_urls_for_vulnerabilitieswait_for_scan_completionMost tools have distinct purposes, but there is some potential overlap between check_security_scan_progress and get_scan_summary, as both retrieve scan results using a task_id, which could cause confusion. However, their descriptions clarify that one provides detailed progress and filtered issues while the other gives a high-level summary, helping to differentiate them.
All tool names follow a consistent snake_case pattern with clear verb_noun structures, such as cancel_scan, check_burp_connectivity, and scan_urls_for_vulnerabilities. This uniformity makes the tool set predictable and easy to navigate, with no deviations in naming conventions.
With 8 tools, the server is well-scoped for managing Burp Suite security scans, covering connectivity testing, scan initiation, progress monitoring, result retrieval, and cancellation. Each tool serves a specific role in the scanning lifecycle, and the count is appropriate for the domain without being excessive or insufficient.
The tool set provides comprehensive coverage for security scanning workflows, including initiation, monitoring, and result analysis, with minor gaps such as the lack of tools for configuring scan settings or managing scan history. However, core operations are well-covered, and agents can perform essential tasks without significant dead ends.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
AI pentesting: run scans, triage vulnerabilities, review PRs, manage schedules and assets.
Real-time CVE, exploit, and vulnerability intelligence for AI assistants (350K+ CVEs, 115K+ PoCs)
Query your team's drift, vulnerability, and upgrade data from any AI assistant. OAuth 2.1, 51 tools.
Pay-per-call cybersecurity for AI agents: vuln scans, threat intel, compliance, code security.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/jayluxferro/burp-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
