一个 MCP (Model Context Protocol) 服务器，将 Burp Suite 的 REST API 作为工具暴露给 AI 助手。使用 Cursor 或其他 MCP 客户端来触发漏洞扫描、检查进度并查询 Burp 的安全知识库。
Burp Suite Professional (或 Burp Suite DAST)，并已启用 REST API
Python 3.11+
Burp 在本地运行，且 REST API 绑定到可访问的地址 (例如 http://127.0.0.1:1337)
Related MCP server: MCPPentestBOT
打开 Burp Suite → Settings → Suite → REST API
勾选 Service running
设置 URL/端口 (例如端口 1337)
创建一个 API 密钥并复制它
uv sync # or: pip install -e .将 .env.example 复制为 .env 并填入你的值：
cp .env.example .env编辑 .env：
BURP_REST_API_BASE=http://127.0.0.1:1337
BURP_REST_API_KEY=your-api-key-here
BURP_REST_API_VERSION=v0.1服务器支持三种传输方式，通过 --transport 选择：
标志 | 传输方式 | 使用场景 |
| stdio (默认) | 本地 MCP 客户端 (Cursor, Claude Desktop) |
| Server-Sent Events | 使用传统 SSE 协议的 HTTP 客户端 |
| Streamable HTTP | 使用现代 MCP HTTP 协议的 HTTP 客户端 |
对于 sse 和 http，绑定地址和端口是可配置的：
# 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 8000添加到你的 Cursor MCP 配置中 (例如 ~/.cursor/mcp.json 或项目 .cursor/mcp.json)：
{
"mcpServers": {
"burp-suite": {
"command": "uv",
"args": ["run", "python", "/path/to/burp-mcp/main.py"],
"cwd": "/path/to/burp-mcp"
}
}
}使用 HTTP 传输启动服务器，然后将你的 MCP 客户端指向它：
uv run python main.py --transport http --host 0.0.0.0 --port 8000{
"mcpServers": {
"burp-suite": {
"url": "http://localhost:8000/mcp"
}
}
}工具 | 描述 |
| 获取 Burp 的安全问题定义 (名称、描述、修复建议、参考资料) |
| 为给定的 URL 启动扫描。返回用于跟踪的 |
| 通过 |
| 高级摘要：按严重程度统计的问题总数 |
| 列出正在运行/挂起的扫描 (并非所有 Burp API 版本都支持) |
| 通过 task_id 取消扫描 (并非所有 Burp API 版本都支持) |
| 测试与 Burp API 的连接；验证配置 |
| 轮询直到扫描完成或超时 (用于 CI/CD) |
扫描 URL：
"Scan https://example.com for vulnerabilities"
检查扫描进度：
"Check scan progress for task_id 123"
仅获取高严重性问题：
"Check scan 123 and show only high severity issues"
安全知识：
"What security issues does Burp know about?"
从脚本或终端运行扫描：
uv run python examples/ci-scan.py https://your-target.com
# or
./examples/ci-scan.sh https://your-target.com端点 | 方法 | 描述 |
| GET | 安全问题定义 |
| POST | 启动扫描 (body: |
| GET | 列出扫描 (可能不支持) |
| GET | 扫描进度和结果 |
| DELETE | 取消扫描 (可能不支持) |
交互式 API 文档：[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.
v1.0.0burp_suite_security_issue_definitionscancel_scancheck_burp_connectivitycheck_security_scan_progressget_scan_summarylist_active_scansscan_urls_for_vulnerabilitieswait_for_scan_completionScored across 8 tools
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.
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.
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.
