Burp Suite MCP Server

by jayluxferro

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation4/5
Most 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.
Naming Consistency5/5
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.
Tool Count5/5
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.
Completeness4/5
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.
Average 3.6/5 across 8 of 8 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness4/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters5/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose4/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters5/5
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.
Purpose4/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![burp-mcp MCP server](https://glama.ai/mcp/servers/jayluxferro/burp-mcp/badges/card.svg)](https://glama.ai/mcp/servers/jayluxferro/burp-mcp)

Score Badge

Copy to your README.md:

[![burp-mcp MCP server](https://glama.ai/mcp/servers/jayluxferro/burp-mcp/badges/score.svg)](https://glama.ai/mcp/servers/jayluxferro/burp-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

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