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., "@acunetix-mcp-server Show me recent vulnerabilities found across all targets"
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.
Model Context Protocol (MCP) server that lets any LLM (Claude, WorkBuddy, Cursor, etc.) directly operate an Acunetix / Invicti Web Vulnerability Scanner.
当前版本：v1.3.4
基于官方内置 API 文档（Swagger 2.0，111 路径 / 161 操作）与公开接口行为分析，将 Acunetix 的完整 API 协议（GraphQL + REST 双通道）封装为 23 个 LLM 可调用工具。官方已确认该产品提供完整 REST API，本 Server 是其 MCP 化封装。
双通道 API 桥：GraphQL（/graphql/，主 UI 通道）+ REST（/api/v1/，业务数据通道）
两种官方认证：
官方 API Key（Profile 页生成，X-Auth 头，纯认证无会话）— 推荐
会话登录（loginUser mutation，密码 SHA-256 预哈希）
15 个 MCP 工具：认证 / GraphQL 通用执行器 / REST 通用执行器 / 目标 / 扫描 / 漏洞 / 报告 / 配置 / 统计 / 用户
健壮错误处理：429 限流自动退避、401 会话失效识别、GraphQL errors 解析、TLS 自签名证书兼容
安全设计：凭据经环境变量注入（不硬编码）、token 仅存内存、写操作工具显式标注
Related MCP server: pentestMCP
工具是被调用的能力层，不是决策层。
工具只负责：接受 LLM 参数 → 执行对应系统操作 → 完整结构化返回结果
工具不拦截 LLM 调用、不自动替 LLM 做决定、不隐藏额外行为（如自动重登/自动续期）
判断、规划、决策全部归 LLM；工具通过"信息完备 + 调用便利"支持决策
错误返回是"信息"（说明发生了什么 + 可选方向），不是"指令"（不强制 LLM 怎么做）
长时间阻塞类操作返回状态快照，由 LLM 决定是否轮询
辅助查询（如查重）做成独立工具，供 LLM 按需调用，而非内嵌自动执行
💡 首次使用？ 请先阅读 examples/NEW_USER_GUIDE.md（5 步完整上手：获取 API Key → 填到哪 → 验证 → 使用 → 故障排查）。配置模板见 examples/.env.example 与 examples/mcp-config-absolute.example.json。
# 方式 A：源码运行（当前唯一方式，推荐）
pip install -r requirements.txt
凭据通过环境变量或 MCP 客户端的 environment 字段传入，不写进代码。
Linux / macOS（bash）:
# 方式一（推荐）：官方 API Key —— Acunetix 界面 → 你的用户名 → Profile → API Key → Generate new API key
export ACUNETIX_API_KEY="<your-api-key>"
# 方式二：账号密码（会话登录，有单会话约束）
export ACUNETIX_EMAIL="<your-email>"
export ACUNETIX_PASSWORD="<your-password>"
# 可选
export ACUNETIX_BASE_URL="https://localhost:3443"
export ACUNETIX_VERIFY_SSL="false"Windows（PowerShell）:
$env:ACUNETIX_API_KEY="<your-api-key>"
$env:ACUNETIX_BASE_URL="https://localhost:3443"
$env:ACUNETIX_VERIFY_SSL="false"Windows（CMD）:
set ACUNETIX_API_KEY=<your-api-key>
set ACUNETIX_BASE_URL=https://localhost:3443💡 通用建议：在 MCP 客户端（如 Claude Desktop / WorkBuddy）的配置文件
environment字段中设置凭据，即可跨平台免环境变量，各操作系统行为一致。
python -m acunetix_mcp --selftest预期输出：认证: 官方 API Key → REST me: <邮箱> → targets: <N> 个目标 → 自检通过。
# 方式 A：命令行直接启动（stdio 模式）
python -m acunetix_mcp
# 方式 B：MCP 客户端配置中声明（推荐，示例见 examples/mcp-config-absolute.example.json）
# 用 __main__.py 的绝对路径，无需依赖 PYTHONPATH，最稳妥{
"mcpServers": {
"acunetix-mcp": {
"type": "local",
"command": "python",
"args": ["-m", "acunetix_mcp"],
"environment": {
"ACUNETIX_BASE_URL": "https://localhost:3443",
"ACUNETIX_API_KEY": "<your-api-key>"
}
}
}
}没有预置凭据也能用：若客户端未配置 environment，可直接在对话中调用
acunetix_use_api_key("<key>")或acunetix_login(email="...", password="...")传入。
Tool | Type | Description |
| auth | 会话登录（方式二，回退） |
| auth | 官方 API Key 认证（方式一，推荐） |
| auth | 清理本地会话 |
| query | 当前用户信息（GraphQL） |
| generic | 任意 GraphQL query/mutation（覆盖任意功能） |
| generic | 任意 REST 端点调用（GET/POST/PUT/DELETE） |
| business | 目标列表（附登录配置摘要） |
| business | 单目标详情（附 auth_config 登录摘要） |
| business | 扫描列表 |
| business | 漏洞列表 |
| business | 报告列表 |
| business | 扫描配置 |
| business | 用户统计（最易受攻击目标） |
| write | 新增目标（criticality: 30/20/10/0） |
| query | 扫描前登录就绪检查（coverage_risk/guidance） |
| write | 启动扫描（描述含登录前置检查引导） |
| write | 写入自定义 Cookie 建立登录态（回读验证落盘） |
| query | 核查自定义 Cookie 配置状态 |
| write | 清空自定义 Cookie（不自动改 login.kind） |
| write | 上传 .lsr 登录序列文件（LSR 流程） |
| write | 应用登录序列（login.kind=sequence） |
| query | 查询登录序列配置状态 |
| write | 删除登录序列（幂等） |
通用执行器（
acunetix_gql/acunetix_rest）可覆盖官方 YAML 中全部 111 路径 / 161 操作。
1. acunetix_use_api_key("<key>") 或 acunetix_login()
2. acunetix_list_targets() # 查看目标 → 取 target_id
3. acunetix_list_scan_profiles() # 查看配置 → 取 profile_id
4. acunetix_start_scan(target_id, profile_id)
5. acunetix_list_scans() # 轮询扫描状态（注意：progress 在扫描中恒 0，用 severity_counts/threat 变化判断进展，见 PROTOCOL §9）
6. acunetix_list_vulnerabilities() # 获取漏洞
7. acunetix_gql(GetReport) # 生成报告
8. acunetix_logout()部分站点使用非标准登录（无表单 / 风控 / 加密提交），automatic 自动登录无法生效。
此时可先在浏览器完成登录，将登录 Cookie 注入目标，使扫描器以登录态爬取受限区域：
1. （浏览器自动化，可选）打开登录页 → 完成登录 → 提取完整 Cookie 串
2. acunetix_set_custom_cookies(target_id, cookie_str) # 写入 + 回读验证
3. acunetix_verify_custom_cookies(target_id) # 核查已配置
4. acunetix_start_scan(target_id, profile_id) # 以登录态扫描
5. acunetix_list_vulnerabilities() # 获取漏洞可选配套工具：若需浏览器自动化完成登录与 Cookie 提取，可接入第三方 MCP
js-reverse-mcp（npm 一行安装，见 docs/AUTH_WORKFLOW.md）：
{ "mcpServers": { "js-reverse": { "command": "npx", "args": ["js-reverse-mcp"] } } }Cookie 会过期（有效期取决于目标站点），过期后需重新获取并再次写入。
若需更强地对抗复杂登录流程（多步/动态验证），可用 Invicti 官方 Login Sequence Recorder
（GUI 录制一次真实登录生成 .lsr），再通过工具上传并应用：
1. Acunetix GUI 录制登录 → 生成 .lsr 文件（GUI 操作，AI 无法代做）
2. acunetix_upload_login_sequence(target_id, "<本地.lsr路径>") # 上传
3. acunetix_apply_login_sequence(target_id) # 应用（kind=sequence）
4. acunetix_start_scan(target_id, profile_id) # 按 .lsr 重放登录扫描
5. acunetix_get_login_sequence / acunetix_delete_login_sequence # 查询/删除上传要求 .lsr 来自 Login Sequence Recorder 录制（服务端校验格式）；未上传时 apply 会提示先上传。
docs/PROTOCOL.md — 协议说明（认证机制、双通道、限流、单会话约束）
docs/SECURITY.md — 安全性考量
docs/AUTH_WORKFLOW.md — 登录态重建工作流（Custom Cookies 全流程）
凭据安全：API Key / 密码仅通过环境变量传入，代码不落盘、不硬编码。
最小权限：建议为自动化创建独立低权限账号（本仓库默认凭据为演示用途）。
写操作：acunetix_add_target / acunetix_start_scan 为写操作，生产环境建议在 MCP 层加人工确认。
TLS：本机自签名证书默认 verify_ssl=False，生产环境必须开启证书校验。
MIT
本工具仅用于授权环境下的安全测试与自动化集成。使用前请确保你拥有目标系统的合法授权。Acunetix / Invicti 为相应公司的商标。
【写操作】新增扫描目标（POST /api/v1/targets）。
address: 目标 URL/IP，如 http://example.com
criticality: 官方枚举 Critical[30]/High[20]/Normal[10]/Low[0]，默认 10；其他值报 400
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | ||
| criticality | No | ||
| description | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the write nature, the criticality enum values, default, and validation error (400 for invalid values), which is useful. However, it omits response format, authentication prerequisites, and potential side effects, leaving some behavioral aspects untold.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, using a bullet list to present key information. Every sentence earns its place—no fluff or redundant content. The endpoint and operation are front-loaded for quick understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple add-operation tool with no output schema, the description covers the core purpose, key parameters, validation rule, and default values. It is mostly complete but misses the 'description' parameter and return value details, which are minor given the simplicity of the action.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds meaning for 'address' (URL/IP example) and 'criticality' (enum values, default, error behavior). However, it does not document the 'description' parameter, leaving that one without semantic enrichment.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '新增扫描目标' (add scan target) with the specific HTTP method and endpoint (POST /api/v1/targets). It distinguishes itself from sibling tools like list_targets and get_target by explicitly positioning this as the 'add' operation.
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 context is clear that this tool is used to create a new scan target, but no explicit alternatives or exclusion conditions are given. The write operation marker and endpoint make the usage context obvious, though it could have mentioned when to prefer this over acunetix_rest.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
获取单个目标详情（GET /api/v1/targets/{id}）。
| Name | Required | Description | Default |
|---|---|---|---|
| target_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It only discloses that this is a GET request, implying read-only, but does not mention what the response contains, error behavior, or authentication requirements. For a simple read tool, this is insufficient behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, to the point, with no wasted words. It front-loads the purpose and includes the API endpoint for reference.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter and no output schema, the description is minimal. It identifies the endpoint and purpose, but does not describe the returned details or state prerequisites like authentication. Given the tool's simplicity, this is a moderate gap.
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%, and the parameter target_id has no description. The tool description adds minimal meaning via the endpoint placeholder {id}, indicating it is the target identifier. Given the parameter name is self-explanatory, the description's contribution is marginal.
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 states '获取单个目标详情' (Get single target details) and includes the API endpoint, clearly indicating it retrieves details for a single target. This distinguishes it from sibling tools like acunetix_list_targets (list all targets) and acunetix_add_target (create a target).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving a specific target's details via the endpoint, but it does not explicitly mention when to prefer this tool over alternatives or provide exclusions. No alternatives are named, though the single-target scope is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
【通用 GraphQL 执行器】—— 大模型自主操作的核心通道。 向 /graphql/ 发送任意已确认可用的 query/mutation。
operation_name: 操作名（如 loginUser / getSharedUIData / getSystemInfo）
query: 完整 GraphQL 文本（依据官方文档与已知操作清单）
variables: 变量对象（可选） 注意：本系统 introspection 已禁用，必须使用已知操作名与字段结构。
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| variables | No | ||
| operation_name | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that the tool can execute both queries and mutations, and warns about disabled introspection. However, it omits potential side effects (e.g., mutations modifying data), authentication prerequisites, and error behavior, leaving the agent to infer risks of a raw GraphQL executor.
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 effectively structured with a title, purpose statement, parameter list, and a note. It is not overly verbose, though the Chinese phrasing is slightly repetitive. It front-loads the core purpose and keeps each element useful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, parameters, and constraints (introspection disabled). However, it lacks any mention of the response format (no output schema), lifecycle context (e.g., requiring prior login), or relationship to sibling tools. For a powerful generic executor, this is a notable gap, but it is still minimally viable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description compensates well. It explains operation_name with concrete examples (loginUser, getSharedUIData, getSystemInfo), defines query as the complete GraphQL text based on official docs, and notes variables is an optional object. This goes beyond the schema's bare type definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as a generic GraphQL executor that sends queries and mutations to /graphql/, with a specific verb ('sends') and resource ('GraphQL'). It distinguishes itself from sibling tools by being the generic core channel for arbitrary operations, while siblings are specific actions like login or list targets.
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?
It implies usage for any confirmed GraphQL operation and notes that introspection is disabled, requiring known operation names. However, it does not explicitly state when to prefer this generic tool over dedicated sibling tools (e.g., using loginUser here vs acunetix_login), nor does it mention exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
列出已生成报告（GET /api/v1/reports?l=N）。
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It reveals the HTTP GET endpoint, implying a read-only operation, but does not mention authentication requirements, pagination behavior, or any side effects. The description adds minimal behavioral context beyond the basic action.
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, concise sentence that is front-loaded with the core action and endpoint. Every word earns its place, with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple list operation with minimal schema and no output schema. The description gives the purpose and endpoint but lacks details on response format, pagination, or prerequisites. Given the absence of annotations and output schema, more context would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter 'limit' with 0% description coverage. The endpoint string '?l=N' maps the limit parameter to the query string, providing some context, but it does not explicitly explain that it controls the number of reports returned.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists generated reports and includes the specific API endpoint (GET /api/v1/reports?l=N). It uses a specific verb and resource, and is easily distinguished from sibling tools like acunetix_list_scans or acunetix_list_targets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is given on when to use this tool versus alternatives. The usage is implied by the tool's name and description, but it does not mention when to prefer this over other list tools or any exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
列出扫描配置（GET /api/v1/scanning_profiles），用于启动扫描时选 profile。
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden of behavioral disclosure. It mentions the HTTP GET method, implying a read-only operation, and provides the endpoint. However, it does not cover authentication needs, pagination, or any side effects, which are relevant for a complete understanding.
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 entire description is a single, compact Chinese sentence that packs both the endpoint and the usage purpose. Every element earns its place, with no redundancy or extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter list operation with no output schema, the description provides the API endpoint and the intended usage context. It does not describe the return structure, but that is easily inferred from the resource name and typical list semantics. Overall, it is sufficient for an agent to select and 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?
The tool has zero parameters, so the schema carries no documenation burden. The description adds useful context by explaining the purpose of the list operation (selecting a profile for a scan), which is sufficient given there is nothing to describe parameter-specific 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 uses the specific verb '列出' (list) with the precise resource '扫描配置' (scan profiles), and also cites the API endpoint GET /api/v1/scanning_profiles. This leaves no ambiguity about what the tool does and clearly differentiates it from sibling tools like list_targets and list_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 states '用于启动扫描时选 profile' (used to select profile when starting a scan), giving a clear use case and timing. It does not explicitly name alternative tools or exclusion scenarios, but the context makes it evident when this tool should be invoked.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
列出扫描任务（GET /api/v1/scans?l=N）。
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. The GET method and the verb 'list' implicitly indicate a read operation, but the description does not disclose any other behavioral traits such as authentication requirements, pagination behavior, rate limits, or response format. For a tool with no annotations and no output schema, this is a significant gap.
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, compact sentence that includes the resource verb, endpoint, and query parameter convention. Every word contributes useful information with zero filler, and it is immediately understandable.
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 (one optional parameter, no output schema, no annotations), the description covers the core purpose but lacks any context about return values, when to prefer this over sibling list tools, or how the limit parameter affects results. It is minimally viable but leaves an agent to guess on operational details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides the parameter name 'limit' with type integer and default 20, but no description. The tool description adds the concrete mapping to the query parameter 'l' via the endpoint (GET /api/v1/scans?l=N), which helps an agent construct the actual API request. This adds semantic value beyond the raw schema, though it does not explain the meaning of the limit value itself.
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 intended action ('列出扫描任务' = list scan tasks) and provides the specific API endpoint (GET /api/v1/scans), leaving no ambiguity about what the tool does. However, it does not distinguish this tool from sibling list tools (e.g., list_targets, list_vulnerabilities), so it falls short of a perfect 5.
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 gives no guidance on when to use this tool instead of alternatives. It neither states exclusions nor mentions any prerequisites or context. With 13 sibling tools present, an agent would have to infer the use case purely from the resource name, which is insufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
列出扫描目标（GET /api/v1/targets?l=N），含地址/ID/漏洞计数。
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It adds the returned fields, but does not disclose behavioral aspects like pagination behavior (beyond the implicit limit parameter), authentication requirements, or whether the operation is read-only. This is a minimal disclosure for a list operation.
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, tightly worded sentence that immediately states the purpose and key return fields. Every word contributes value, and there is no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list operation with one optional parameter, the description is mostly complete: it names the resource, the HTTP method, the parameter usage, and the returned fields. It lacks details on response structure and pagination behavior, but given the low complexity, these gaps are minor.
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 no parameter descriptions (0% coverage), so the description must compensate. It mentions the API query string '?l=N', which maps to the 'limit' parameter, providing some syntactic context. However, it does not explain the meaning of N (e.g., number of results) or the default behavior, leaving the parameter semantics incomplete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists scan targets and specifies the returned information (address/ID/vulnerability count). The verb '列出' (list) and resource '扫描目标' (scan targets) pinpoint the action, distinguishing it from sibling tools like 'acunetix_get_target' which implies a single target.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The description does not mention scenarios such as 'use this for an overview of targets; use get_target for details of a single target.' It relies on the tool name and sibling list for context, which is insufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
列出漏洞（GET /api/v1/vulnerabilities?l=N）。
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses only the GET method and the limit parameter, but does not mention pagination, sorting, authentication needs, or response format. The behavioral disclosure is minimal.
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 concise sentence with no wasted words. It states the resource and endpoint efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with one parameter, the description is minimally adequate. However, it lacks usage context, return value details, and authentication notes, making it incomplete for agents needing to understand the full behavior.
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 parameter 'limit' has 0% schema description coverage, but the description maps it to 'l=N' in the endpoint, adding a small semantic clue. The name and default make the parameter self-explanatory, though the description does not elaborate on its effect.
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 'List vulnerabilities' and provides the exact API endpoint, making the tool's purpose unambiguous. It distinguishes from sibling tools by the resource type (vulnerabilities vs targets, scans, etc.).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives like 'list_scans' or 'list_targets'. The description simply states the action without any context or preconditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
【会话登录】登录 Acunetix 系统并建立会话（方式二）。
email/password 省略时使用环境变量 ACUNETIX_EMAIL / ACUNETIX_PASSWORD
成功后 token 保存在内存中，后续工具自动携带认证
注意：系统有单会话约束，会话登录会顶掉其他在线会话 提示：官方推荐方式是 acunetix_use_api_key（无单会话约束）。
| Name | Required | Description | Default |
|---|---|---|---|
| No | |||
| password | No | ||
| otp_token | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully carries the transparency burden. It discloses that email/password can fall back to environment variables, the token is stored in memory and automatically used by subsequent tools, and that the system has a single-session constraint which will log out other online sessions. This reveals important side effects and authentication behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a concise bulleted list with the main purpose front-loaded. Each line provides valuable information (env var fallback, token storage, single-session warning, alternative recommendation) without any waste or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a login tool with three optional parameters and no output schema, the description covers the essential context: login purpose, session establishment, parameter fallback, side effects, and the recommended alternative. However, it omits any mention of the otp_token parameter and does not describe the response or error cases, leaving minor gaps in 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 description explains the email and password parameters, including the env var fallback when omitted. However, it does not mention the otp_token parameter at all, and the schema has no descriptions (0% coverage). Thus, while it adds meaning for two of three parameters, the third is left undocumented, creating a partial gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to log into Acunetix and establish a session (method 2). It distinguishes this from the alternative acunetix_use_api_key by noting the single-session constraint and official recommendation, so the agent can differentiate between sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says the official recommended approach is acunetix_use_api_key because it has no single-session constraint, providing clear guidance on when to use this login method versus the alternative. This is direct and actionable usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
登出并清理本地会话。
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 states that the tool logs out and cleans the local session, which communicates a state-changing behavior. However, it does not detail whether the server-side session is also invalidated, how tokens are handled, or if there are any side effects beyond local cleanup. The disclosed behavior is adequate for a simple logout tool but not rich in context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence in Chinese, front-loading the main action and object. Every word contributes meaning, with no padding or repetition. It is appropriately minimal for a no-parameter logout tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with no parameters and no output schema, the description conveys the core purpose and local effect. It could be slightly more complete by noting whether the server session is also terminated or if any cleanup steps are irreversible, but for the tool's simplicity, it is sufficiently complete for an agent to invoke it 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?
The tool has zero parameters, and the schema coverage is 100% (vacuously). The description does not need to explain parameters, and per the baseline for 0 params, a score of 4 is appropriate. It adds no unnecessary parameter-related noise.
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 uses a specific verb '登出' (logout) and specifies the resource '本地会话' (local session), clearly distinguishing it from sibling tools like acunetix_login and acunetix_use_api_key. The action is unambiguous and directly tied to the tool's name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention that it should be used after completing authenticated operations or that it is the counterpart to login. The expected usage is only implicit from the tool's name and sibling context, but the description itself offers no explicit direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
获取当前登录用户信息（GraphQL）。
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description is the sole source. It implies a read operation and indicates the GraphQL method, but does not disclose whether authentication is required, error scenarios, or what exact data is returned. This is a minimal disclosure appropriate for a simple getter, but not rich.
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, concise sentence that directly states the tool's purpose without extraneous information. It is well-structured and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (0 params, no output schema), the description is adequate but lacks detail on the return content (e.g., specific user fields) and any usage context such as verifying login status. This makes it somewhat incomplete for an agent to fully understand what to expect.
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, and the schema is empty, so there are no parameter semantics to clarify. The baseline of 4 applies as the description need not compensate for any undocumented parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves current user information via GraphQL, using a specific verb ('获取') and resource. However, it does not explicitly differentiate from sibling tools like acunetix_gql, so it doesn't fully meet the 5-criteria.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool instead of alternatives such as acunetix_gql or login-related tools. There is no mention of prerequisites or exclusions, leaving the agent without usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
【通用 REST 调用器】访问 /api/v1/* 端点。
method: GET/POST/PUT/DELETE/PATCH
path: 端点路径，如 targets / scans / vulnerabilities / reports / me
params: 查询参数（可选）
body: JSON 请求体（POST/PUT 等写操作需要） 高风险写操作请确保意图明确。
| Name | Required | Description | Default |
|---|---|---|---|
| body | No | ||
| path | Yes | ||
| method | Yes | ||
| params | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden. It only warns about high-risk write operations and does not disclose authentication requirements, response formats, error behavior, or other side effects. The warning adds a bit of value, but the behavioral details are largely absent.
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 remarkably concise, using a short header and a bullet list. Every line delivers useful information: the scope (/api/v1/*), accepted methods, example paths, parameter purposes, and a safety warning. No filler or redundancy exists.
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?
As a generic REST caller, this tool is inherently broad, and the description gives enough to start using it. However, it omits important context such as authentication mechanism, base URL, error responses, and rate limits. Given the absence of an output schema and the lack of any annotations, a bit more detail would make it complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description's parameter explanations (method, path, params, body) add some meaning beyond raw property types. It clarifies that params are query parameters and body is a JSON request body for write operations, but it lacks examples of value formats or constraints, so it only partially compensates.
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 identifies this as a generic REST caller for /api/v1/* endpoints and lists example paths (targets, scans, etc.), distinguishing it from the more specific sibling tools. However, it does not explicitly state that it is the fallback when no specific tool exists, so it stops short of a 5.
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 term '通用' (generic) implies it is intended for when specific wrapper tools are not suitable, but the description does not explicitly recommend using sibling tools or describe when not to use this tool. No exclusions are given, so guidance is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
【写操作】对目标启动扫描（POST /api/v1/scans）。
target_id: 目标 ID（acunetix_list_targets 获取）
profile_id: 扫描配置 ID（acunetix_list_scan_profiles 获取）
| Name | Required | Description | Default |
|---|---|---|---|
| target_id | Yes | ||
| profile_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only labels the operation as '【写操作】' (write operation) and gives the POST endpoint, which implies mutation. It lacks critical behavioral details like whether the scan runs asynchronously, what side effects occur, or how to monitor progress. For a state-changing action, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely compact, with a clear write-operation marker followed by two bullet points explaining parameters. Every element serves a purpose, no fluff, and it is immediately scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (2 required params, no nested objects), but with no output schema and no annotations, the description should cover return values or follow-up actions. It only explains how to invoke the scan, not what the response is or how to track the scan, leaving the user without enough context to use the result effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides no parameter descriptions (0% coverage), and the description compensates by explaining each parameter: target_id is the target ID sourced from acunetix_list_targets, and profile_id is the scan profile ID from acunetix_list_scan_profiles. This adds meaningful semantics beyond the bare schema, showing how to obtain valid values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: '对目标启动扫描' (start a scan on a target), identifying both the verb and resource. It also notes the HTTP endpoint and write operation, distinguishing it from siblings like acunetix_list_scans or acunetix_list_targets.
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 clear context by telling users to obtain target_id from acunetix_list_targets and profile_id from acunetix_list_scan_profiles, effectively guiding when to use this tool (after listing targets and profiles). It does not explicitly state when not to use it or mention alternatives, but the context is sufficiently clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
当前用户统计（GET /api/v1/me/stats）：扫描/目标/漏洞汇总。
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the transparency burden. It discloses the HTTP method (GET) and scope ('current user'), indicating a read-only operation. However, it does not describe the response format, potential data volume, or any caveats about the summary, leaving some behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single compact sentence that front-loads the core purpose and includes the endpoint plus the three summary categories. There is no redundancy or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple tool with no parameters and no output schema. The description covers the main functionality—providing a summary of scans, targets, and vulnerabilities for the current user. It could specify the exact metrics (e.g., counts) returned, but for a stats endpoint this is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and an empty schema, so there is no parameter information to provide. The description adds no semantics beyond the schema, but with no parameters to document, this is not a shortfall. The baseline for zero-param tools is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves current user statistics via a specific endpoint and summarizes scans, targets, and vulnerabilities. This distinguishes it from sibling list tools like acunetix_list_scans and acunetix_list_vulnerabilities, which return detailed records rather than aggregated summaries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is provided for when to use this tool versus alternatives. The word '汇总' (summary) implies it is intended for high-level overviews, but the description does not explicitly recommend this tool over list_* tools for summary data or clarify that detailed lists require other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
【官方推荐认证】使用 Profile 页生成的 API Key 认证（方式一）。
api_key: Profile 页 → API Key → Generate new API key 生成的 64 位密钥
纯 X-Auth 头认证：REST 与 GraphQL 均可用，无需登录、无单会话约束
若在环境变量 ACUNETIX_API_KEY 中配置，MCP server 启动时已自动启用，无需调用本工具
| Name | Required | Description | Default |
|---|---|---|---|
| api_key | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it explains key behavior: pure X-Auth header authentication, works for both REST and GraphQL, no login/session constraints, and automatic enablement from environment variables. It does not detail side effects like overwriting existing auth or persistence, but the disclosed traits are substantial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, front-loaded with '【官方推荐认证】', and structured as three bullet points. Each sentence adds unique value: the auth method, the parameter details, and the automatic-enablement caveat. No waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter authentication tool with no annotations or output schema, the description covers purpose, parameter, compatibility, and an important environment variable shortcut. It is self-contained and leaves no critical gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate, and it does admirably. It explains exactly how to obtain the api_key (Profile page → API Key → Generate new API key) and its format (64-bit key). This adds all needed meaning beyond the bare 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 identifies the tool's purpose: using an API key from the Profile page for authentication. It distinguishes itself from sibling login/logout tools by explicitly stating '无需登录' (no login) and that it works via X-Auth header. The verb+resource structure leaves no 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?
It provides an explicit when-not-to-use condition: if ACUNETIX_API_KEY is set in the environment, the MCP server already has it enabled and there is no need to call this tool. It also implies it is the recommended alternative to login by saying '官方推荐' (officially recommended) and '无需登录' (no login required), though it doesn't name the alternative tool directly.
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.1.5acunetix_add_targetacunetix_get_targetacunetix_gqlacunetix_list_reportsacunetix_list_scan_profilesacunetix_list_scansacunetix_list_targetsacunetix_list_vulnerabilitiesacunetix_loginacunetix_logoutacunetix_meacunetix_restacunetix_start_scanacunetix_statsacunetix_use_api_keyMost tools are clearly distinct (list_targets vs add_target vs start_scan), but acunetix_rest and acunetix_gql are generic executors that overlap with the specific list/get tools. The descriptions clarify their generic purpose, but an agent may still be uncertain whether to use the specific or generic tool for a given operation.
All tools share the acunetix_ prefix, but naming patterns vary: some are verb-only (login, logout), some are nouns (me, gql, rest, stats), and some are verb_noun (list_targets, add_target). This mixed convention is still readable but not fully consistent.
15 tools is within the typically well-scoped range, but the set feels slightly heavier because generic executors (acunetix_rest, acunetix_gql) are included alongside specific wrappers for the same endpoints. Each tool has some justification, though some redundancy exists.
Core workflows are covered: add target, start scan, list vulnerabilities, and list reports. However, there are no dedicated update/delete tools for targets or scans. The generic REST and GraphQL executors fill these gaps, so agents can work around them, but the dedicated tool surface is not fully complete.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP server for Pentest-Tools.com: run scans, manage findings and reports via your preffered LLM.
Security scanner for MCP servers. Detect vulnerabilities, prompt injection, and tool poisoning.
Zero-config MCP security scanner for AI-generated apps. 25K+ vulnerability patterns.
Zero-setup MCP gateway securely connecting AI to your tools with authentication and workflows
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/McxM123/acunetix-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
