acunetix-mcp-server

Server Quality Checklist

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

Latest release: v1.1.5
Disambiguation3/5
Most 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.
Naming Consistency3/5
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.
Tool Count4/5
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.
Completeness4/5
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.
Average 3.8/5 across 15 of 15 tools scored. Lowest: 3.2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 2 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
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?
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters4/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines3/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters4/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
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 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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.

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:

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

Score Badge

Copy to your README.md:

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

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/McxM123/acunetix-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server