Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations only indicate a mutating, non-destructive operation. The description adds a non-obvious behavioral detail: the contact is created with a random email that must be changed afterward in Invapi. This goes beyond the annotations, though it could say more about side effects.

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 two short sentences with no filler. The main purpose comes first, followed by a critical warning, and every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with one boolean parameter and no output schema, the description is largely sufficient. It highlights the essential post-creation caveat about the random email. A small gap is that it does not explicitly point to update_contact as the follow-up tool.

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 100%; the only parameter, confirm, is already described as 'Must be true to run the operation.' The description does not add extra meaning to the parameter, so the baseline score of 3 applies.

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 a specific action ('add an additional contact'), the target resource ('account'), and even the underlying endpoint (whmcs/add_contact). This clearly distinguishes it from sibling tools like update_contact, delete_contact, and get_contacts.

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 usage context is implied: it adds a contact, and the warning about the random email signals when this tool may need follow-up. However, it does not explicitly say when to prefer this over update_contact or mention any exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate that the operation is non-read-only and non-destructive. Beyond that, the description usefully discloses the explicit permission requirement (pdns/edit) and the fact that both a DNS zone and a domain-table entry are affected. It does not mention return values or idempotency, but that is not critical here.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences, front-loaded with the primary action, followed by the permission requirement. No filler, no repetition of schema content, and every clause earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple two-parameter mutation with complete schema coverage and no output schema, the description provides the essential action and access constraint needed to call the tool correctly. The only gap is not explicitly disambiguating from add_dns_zone, but that is more of a usage-guidance issue than a completeness issue.

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 100%, with both name and confirm already documented in the input schema. The description adds no parameter-level meaning beyond the schema, so the baseline of 3 applies.

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?

Description states a specific compound action: 'Создать DNS-зону и добавить домен в таблицу доменов' and even names the underlying internal method (pdns/add_domain). This makes the resource and effect clear. It does not explicitly differentiate from the sibling add_dns_zone, so it misses the top score.

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 such as add_dns_zone or add_dns_subdomain. The only contextual note is the permission requirement 'Требует права pdns/edit', which is a prerequisite rather than a usage rule.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond annotations, it discloses the authorization requirement and warns that `mname/rname` may be mandatory for SOA checks, which affects whether the call succeeds. It also implies upsert semantics via 'add or modify'.

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?

Three sentences, front-loaded with purpose and permissions, then conditional guidance. The phrasing 'в документации отмечены' is slightly indirect but not wasteful.

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 15 parameters and no output schema, the description covers the trickiest cases (SRV, SOA) but leaves `confirm`, `old_name`, and `increase_soa_serial` to the schema, which already explains them. An agent can call correctly if it reads the schema.

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 100%, so the schema documents each parameter. The description adds group-level semantics: it names the SRV parameter set and explains that `mname/rname` are conditionally required.

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 a clear verb ('add or change') and resource ('DNS record in zone'), and includes the internal endpoint `pdns/add_dns`. It does not explicitly contrast with sibling tools like `delete_dns_record` or `add_dns_subdomain`, but the scope is unambiguous.

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 a prerequisite (`requires pdns/edit`) and record-type-specific guidance for SRV and SOA fields. However, it lacks explicit when-to-use vs alternatives or any exclusions, so an agent must infer tool selection from context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=false and destructiveHint=false, indicating a non-destructive write operation. The description adds the permission requirement (pdns/edit) and the internal endpoint name, which are beyond the structured metadata. It does not contradict the annotations and provides useful operational context about access control.

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 two concise sentences with no filler. The primary action is front-loaded, followed by the permission requirement. Every word contributes to understanding the tool's function, and the internal endpoint reference adds precision without bloat.

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 straightforward add operation with a required confirm flag and schema that already references list_dns_domains for domain_id, the description provides adequate context. It covers the action and permission but does not mention potential failure modes (e.g., duplicate subdomain) or side effects beyond the table insertion. However, given the simplicity and existing structured data, the description 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?

Schema description coverage is 100%, so each parameter (server_id, domain_id, name, confirm) is already documented with a short description. The tool description adds no additional meaning beyond the schema, such as relationship between parameters or formatting rules. Per the calibration baseline, a score of 3 is appropriate when the schema carries the parameter documentation burden.

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 ('Add a subdomain'), the resource ('to the subdomains table'), and even names the underlying API endpoint (pdns/add_subdomain). This distinguishes it from sibling tools like add_dns_domain (which adds a domain) and edit_dns_subdomain (which modifies). An agent can immediately understand what this tool does without inspecting the schema.

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 the essential prerequisite (requires pdns/edit permissions) but does not explicitly mention when to use this tool versus alternatives like add_dns_domain or edit_dns_subdomain. While the purpose is clear from the name, there is no explicit guidance on selection criteria or exclusions, leaving the agent to infer usage context from sibling tool names.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate a non-read-only, non-destructive operation, and the description aligns with that. It adds valuable context by explicitly stating the required permission ('Требует права pdns/edit') and identifying the authoritative PowerDNS backend. It does not discuss idempotency or duplicate-zone behavior, but the annotations carry much of the safety profile.

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 two short, front-loaded sentences with no wasted words. It conveys the core action, target system, endpoint, and permission requirement 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?

Although the schema richly documents all 8 parameters, the description does not mention what happens after a successful creation, whether any confirmation/return value is produced, or how to choose this over related DNS tools. For a creation operation with no output schema, this is adequate but leaves some operational context to inference.

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 100%, so the schema already documents every parameter, including defaults for kind, dnssec, rrsets, and nameservers. The description contributes no additional parameter-level meaning, and no compensation is needed given the high schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Создать DNS-зону') and the specific resource ('авторитетном сервере PowerDNS'), also referencing the underlying endpoint 'pdns/add_zone'. It is unambiguous about what the tool does, but it does not explicitly differentiate it from closely related siblings like add_dns_domain or add_dns_subdomain.

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 mentions required permissions but never states conditions, exclusions, or points to related DNS tools such as add_dns_domain, add_dns_subdomain, or delete_dns_zone. Usage context is only implied by the tool name.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already convey that this is a write operation (readOnlyHint: false) and non-destructive (destructiveHint: false). The description adds useful context that the created user is temporary and intended for web access, but it does not disclose lifecycle details such as expiration, permissions, or how the temporary user relates to an existing IPMI user.

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, front-loaded sentence that states the action and purpose clearly. The parenthetical '(eq/add_ipmi_user)' is redundant and does not earn its place, but the overall description is concise and easy to parse.

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 low-complexity tool with only two required parameters and no output schema, the description plus the schema is mostly complete. It explains what the tool does and why it is used, though it could be more complete by noting that the confirm parameter must be true and by mentioning the temporary nature in operational terms.

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 100%, so the schema already documents both parameters clearly. The description adds no parameter-specific detail beyond the general purpose, which is acceptable given the high schema coverage but does not go above the baseline.

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 ('Создать' / create), a specific resource ('временного IPMI-пользователя'), and a clear purpose ('для веб-доступа к IPMI'). This clearly distinguishes it from related siblings like remove_ipmi_user and reset_ipmi, so an agent can identify what the tool does without opening the schema.

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 when to use the tool: when temporary web access to IPMI is needed. However, it does not explicitly mention alternatives, exclusions, or related cleanup actions such as remove_ipmi_user, nor does it explain when this option should be preferred over other IPMI/VNC/KVM access tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the annotations, the description discloses that the operation is an upsert by name and that the 'add' permission is required. This adds useful behavioral and authorization context, though it does not explain what happens to an existing image when it is updated.

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 two-clause sentence that leads with the action, includes the endpoint and permission requirement, and contains no filler. Every element contributes useful 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 simple three-parameter mutation with full schema coverage and no output schema, the description plus input schema is largely sufficient. The main gap is not explicitly distinguishing this tool from upload_iso, but the 'by name' add/update wording narrows the ambiguity.

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 100%, and the input schema already documents name, url, and confirm. The description adds only the 'by name' matching detail, but with full schema coverage the baseline of 3 applies.

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 a specific action ('add a new ISO image or update an existing one by name') and names the endpoint (iso/add), clearly identifying the resource and operation. It does not explicitly contrast with sibling tools like upload_iso or mount_iso, so differentiation is mostly implicit.

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 a clear prerequisite — the special 'add' permission — but provides no explicit when-to-use vs alternatives or when-not-to-use guidance. The intended use case is implied by the verb and resource, so an agent can infer it, but it is not spelled out.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the annotations (mutating, non-destructive), the description adds the important fact that the message is visible to the client, which materially affects how an agent should use the tool. It does not cover auth or rate limits, but the safety profile is already established by annotations.

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?

A single compact sentence with no redundancy. It front-loads the key behavior and uses a parenthetical to anchor the feature area without adding unnecessary words.

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 mutation tool with three required parameters and no output schema, the description plus schema is sufficient: it states what to do, where, and that the message is client-visible. Nothing needed for a correct invocation is missing.

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 100%, and each parameter already has a clear description: id comes from list_rhr_requests, confirm gates execution, and message is the text. The tool description adds no further parameter-level meaning, so the baseline score of 3 applies.

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 names the action ('Добавить' / add), the object (message visible to the client), and the location (request history rhr/chat). This clearly distinguishes it from sibling tools like create_rhr_request or discard_rhr_request and makes the operation immediately understandable.

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 intended use is implied: adding a client-visible message to a request's history. However, there is no explicit guidance about when to prefer this tool over sibling RHR tools or when it should not be used. For a simple append-style operation this is acceptable, but not fully explicit.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description adds a key behavioral detail beyond annotations: the operation is asynchronous and status must be checked via check_task. This is valuable context that annotations do not provide. No contradiction with readOnlyHint=false or destructiveHint=false.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences with no filler. The core purpose is front-loaded, the API path is included, and the async behavior is stated compactly. Every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple two-parameter asynchronous action, the description gives enough context: what it creates, for which server type, and how to track completion. No output schema exists, and the description appropriately points to check_task rather than attempting to describe return values.

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 100%, so parameters are already documented. The description does not add significant new meaning to id or confirm beyond saying the DNAT is for IPMI, which is useful but not essential.

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 ('Create static DNAT to IPMI server') and its purpose (public IP for IPMI access). It names the method path and is immediately distinguishable from siblings like remove_static_nat and clear_static_nat.

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 when to use it: whenever a static DNAT/public IP is needed for IPMI access. However, it does not explicitly state when not to use it or identify alternatives such as add_ipmi_user or remove_static_nat.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description adds a critical behavioral disclosure—'списывает средства со счёта' (debits funds from the account)—which goes beyond the annotations (readOnlyHint=false, openWorldHint=true). It also clarifies that partial or full payment is possible. However, it does not mention irreversibility or refunds, though destructiveHint=false suggests no destructive deletion. The added context is valuable.

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 two short sentences, front-loading the main action and then adding the financial impact. Every word serves a purpose, with no redundancy or filler. It is concise and well-structured for quick comprehension.

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 financial operation, the description covers the core behavior (payment from credit) and the money debiting, which are the most important contextual elements. It does not mention return values or failure modes, but given the simplicity of the operation and the schema covering all parameters, the description is sufficiently complete for an agent to call 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?

Schema coverage is 100%, meaning all three parameters have descriptions in the schema. The description does not add extra meaning to any parameter; it only repeats the general purpose. Since the schema already documents the confirm, amount, and invoice_id fields, the description adds no additional parameter-specific insight.

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 (pay an invoice) and the source (credit balance), using a specific verb and resource. It distinguishes itself from siblings like get_invoice, mass_pay, and create_addfunds_invoice by focusing on applying credit. The mention of 'полностью или частично' adds nuance, making the tool's scope unambiguous.

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 the use case (paying an invoice from credit balance) but does not explicitly contrast it with alternative payment tools or state when not to use it. There is no mention of alternatives or exclusions, so the agent must infer the appropriate context from the description alone.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=false and destructiveHint=false, so the agent knows this is a mutating operation. The description adds that the block happens at the Hostkey network level and mentions the optional four_hours auto-unblock behavior in the schema, but the description itself does not disclose side effects, reversibility, or confirmation requirements beyond the schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence that front-loads the action and resource, then adds a practical use case. No wasted words.

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 mutating tool with no output schema, the description is adequate but minimal. It does not explain the effect of 'confirm', the four_hours option, or what happens after blocking (e.g., whether unblocking requires a separate call). The sibling 'unblock_ip' exists, but the description does not reference it.

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 100%, so the schema already documents all parameters. The description adds no extra meaning beyond the schema, but the baseline of 3 applies because the schema carries the full burden.

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 a specific verb ('Заблокировать' = block), a resource (IP-address on server at Hostkey network level), and a use case (abuse requests). It is clear enough to distinguish from the sibling 'unblock_ip', though it does not explicitly name that sibling.

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 a clear context ('Полезно для abuse-запросов' = useful for abuse requests), which implies when to use it. However, it does not explicitly state when not to use it or mention alternatives like 'unblock_ip' or firewall-level blocking.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond annotations, the description discloses the mandatory confirm=true requirement and the additional HOSTKEY_ALLOW_DESTRUCTIVE=1 gate for destructive/paid actions. This is valuable behavioral context for a dangerous raw-call tool and aligns with the destructiveHint=true annotation.

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 compact and front-loaded: it states what the tool is, when to use it, the critical safety requirements, and where to find more details. Every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a generic raw-call tool with no output schema, the description is complete enough: it covers purpose, scope, safety gates, examples, and documentation. The openWorldHint and destructiveHint annotations are reinforced rather than contradicted.

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 100%, so the schema already documents all five parameters. The tool description adds useful resource examples and the confirm restriction, but does not add significant parameter-level meaning beyond the 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 states a specific verb and resource pattern: a universal direct call to InvAPI by 'resource' and 'action'. It explicitly scopes the tool to resources without typed instruments (iso, s3, rhr) and names those examples, clearly distinguishing it from the many typed 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 tells the agent when to use this tool: for resources without typed tools. It also gives a clear exclusion: 'Prefer typed instruments if they exist for the needed operation.' It even links to external documentation for the full action list.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the readOnlyHint and openWorldHint annotations, the description reveals important behavior: the callback key is single-use and 'burns' after successful completion, status values are 'Not ready' vs 'OK', and deployment can take 10–30 minutes. This is meaningful context an agent needs for polling 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 compact, front-loaded with the core purpose, and every sentence adds useful detail: callback source, result statuses, key consumption, and timing. No filler 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 single-parameter polling tool with no output schema, the description covers what the tool does, how to call it, what results mean, and the side effect of key consumption. An agent has enough guidance to use it correctly without further documentation.

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 already fully documents the single 'key' parameter with 100% coverage, so the description is not required to add parameter semantics. It does reinforce that the key comes from an async operation, but this is essentially the same information as the schema description.

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 a specific action ('Проверка статуса асинхронной операции') and a clear resource (callback-key). It also explains how this is distinct: it is the companion to operations that return a callback key, so an agent can tell it apart from the many 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?

It explicitly explains when to use the tool: when an InvAPI operation returns a callback key, pass that key here. It also describes expected result values and that the key is consumed on success corrected. It does not name alternatives because no sibling tool covers async status checks, but the usage context is clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The annotation destructiveHint=true is reinforced and expanded with a concrete consequence: failing to run this tool may cause an unexpected reinstallation at the next reboot. This adds meaningful behavioral context beyond the annotation.

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: two short sentences that pack the action, step context, endpoint hint, and a critical safety warning. Every part earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the simple parameter set, fully documented schema, and destructive annotation, the description provides all necessary operational context. It explains why this step is mandatory and what happens if skipped; no return value is needed since there is no output schema.

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 100%, with each parameter already documented (id, hostname, confirm). The tool description does not add parameter-level details, so the baseline score of 3 is appropriate.

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 ('удалить PXE-конфиг') and the specific resource (PXE config), plus the internal endpoint reference 'eq/clear_pxe'. It distinguishes itself from sibling tools like create_pxe_config by framing it as Step 7 of the PXE reinstallation flow.

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 explicitly states when to use the tool: after PXE reinstallation completion. The strong warning ('ОБЯЗАТЕЛЬНО после завершения') makes the usage context clear, though it does not explicitly name sibling alternatives or state when not to use it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations exist (readOnlyHint=false, destructiveHint=false), so the description does not need to restate safety basics. It adds the useful qualifier that only 'stuck' rules are affected and that filtering is by internal IP. However, it does not clarify side effects, whether all such rules are removed at once, or what happens if no stuck rules exist.

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 core action, the resource, the filtering key, and the API path. There is no filler or redundant restatement of the tool name.

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 two-parameter operation with complete schema coverage and annotations, the description is mostly adequate. Still, it lacks context about when the operation is needed, what 'stuck' means in practice, and what result to expect, so it is only minimally 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?

Schema description coverage is 100%, with both ip and confirm already documented. The description itself adds no extra parameter-level detail beyond saying the operation targets rules by internal IP. Baseline 3 is appropriate because the schema carries the parameter meaning.

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 a clear action ('Удалить' / delete) on a specific resource ('застывшие правила статического NAT-проброса по внутреннему IP'). It also includes the API path, which helps identify the operation. However, it does not explicitly differentiate itself from similar siblings like remove_static_nat or drop_nat, so it misses the top score.

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 this is used for stuck/stale static NAT rules but gives no explicit guidance on when to choose this tool over remove_static_nat, drop_nat, or add_static_nat. There is no mention of prerequisites, conditions, or exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already show readOnlyHint=false and openWorldHint=true, so the description's 'ДЕНЬГИ: создаёт реальный инвойс' adds meaningful context about the real financial impact. It warns that this is not a dry run or estimate, which is valuable beyond the structured annotations.

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 two short, purposeful sentences. The first states the action and endpoint, and the second provides a clear financial warning. No filler or redundant detail is present.

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 two-parameter tool with full schema documentation, the description supplies the key missing context: this action creates a real money invoice. It does not explain the post-invoice flow, but that is not necessary given the simple input schema and no output schema requirement.

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 100%, so the schema already documents both amount and confirm. The description only loosely references the amount ('на указанную сумму') and does not add meaning about the confirm flag or amount formatting beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Создать инвойс') and the specific purpose (replenishment of credit balance), and explicitly says it creates a real invoice. It does not explicitly differentiate from sibling billing tools like generate_due_invoice, but the 'addfunds' scope makes the purpose clear.

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 when a credit balance top-up invoice is needed, but gives no guidance about when to prefer this over related tools such as generate_due_invoice, apply_credit, or mass_pay. There is no exclusionary or alternative routing information.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=false and destructiveHint=false, so the agent knows this is a mutating but non-destructive operation. The description adds critical behavioral context: the key value is shown only once in the response and must be saved. This is exactly the kind of beyond-annotations disclosure that matters for a create 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?

Two sentences, front-loaded with the action and scope, and the one-time-display warning is placed at the end where it's memorable. No wasted words.

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 create operation with 100% schema coverage and no output schema, the description covers the essential behavioral warning (key shown once) and the scope distinction. It doesn't mention response format, but the absence of an output schema and the one-time warning partially compensate. The description is complete enough for an agent to invoke correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all 7 parameters. The description adds the semantic distinction that server_id omitted means account-wide key, and that login_notify_method should be 'none' for per-server keys. This adds value beyond the schema, but the schema already carries most of the parameter meaning, so a baseline 3 is appropriate.

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 a specific verb ('Создать') and resource ('новый API-ключ'), and clarifies the two scopes: account-wide or per-server. It also includes the endpoint path (api_keys/add), which disambiguates it from sibling tools like list_server_api_keys, get_api_key, update_api_key, and delete_api_key.

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 when to use it: when creating a new API key, and it distinguishes account-level vs server-level keys via server_id. It doesn't explicitly name alternatives or exclusions, but the context of creation vs listing/updating/deleting is clear from the sibling names and the description's scope statement.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description repeats and emphasizes the destructive nature with 'ДЕСТРУКТИВНО', which is consistent with destructiveHint=true. It adds the step context but does not disclose what specifically gets overwritten or destroyed, nor does it mention the required 'confirm' flag or side effects on existing PXE configuration.

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: one sentence plus a destructive warning. Every element carries purpose or caution, with the key action front-loaded. There is no filler 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?

Despite being a destructive 9-parameter operation with no output schema, the description only supplies a workflow step and a warning. It omits prerequisites, what the operation affects, expected results, and how it relates to companion tools like create_reinstall_task or clear_pxe_config. This is incomplete for safe invocation.

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?

Input schema description coverage is 100%, so the schema already documents all 9 parameters. The description adds no parameter-level meaning beyond the schema, so it stays at the baseline 3 rather than compensating or enriching parameter 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 gives a specific verb ('создать') and resource ('PXE-конфиг') plus the purpose ('для установки ОС'), and labels it as 'Шаг 2 PXE-переустановки'. This clearly distinguishes it from related concepts like clear_pxe_config by stating it creates, not clears, a PXE config.

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?

'Шаг 2 PXE-переустановки' provides clear contextual guidance: this tool is the second step in a PXE reinstall workflow. It does not explicitly exclude alternatives or list prerequisites, but the step placement is a useful usage signal beyond just naming the action.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The annotations already declare destructiveHint=true, so the agent knows it's destructive. The description adds a critical warning: 'ДЕСТРУКТИВНО: часть процесса, затирающего диски сервера' (destructive: part of the process that wipes server disks), which provides context beyond the annotation. However, it doesn't disclose other behavioral aspects like the need for confirmation (implicit in 'confirm' parameter) or any side effects beyond disk wiping. Given the annotation already flags destructiveness, the addition is modest, hence a 3.

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 concise: three sentences, with the key information front-loaded ('Шаг 1 PXE-переустановки...'). The destructive warning is clearly separated, and every sentence adds value. No filler 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 simple two-parameter tool with a clear workflow context, the description is quite complete: it explains what it returns ('reinstall_key'), how it fits into the reinstall process, and warns of destructiveness. It lacks details on prerequisites (e.g., server must be powered off?) or the full reinstall flow, but given the simplicity and schema richness, it's nearly sufficient. A 4 is warranted.

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 100%, so both parameters ('id' and 'confirm') are already documented in the schema. The description does not add any new information about the parameters themselves; it only implies via the destructive note why 'confirm' might be needed, but that's not explicit. Since the schema covers everything, baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the specific verb ('create'), the resource ('master key for reinstall'), and the context ('Step 1 of PXE reinstall'), and distinguishes it from sibling tools like 'reinstall_server' and 'check_task'. The key generated ('reinstall_key') is identified, and the relation to 'check_task' is explicit, making its purpose unambiguous.

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 as part of a reinstall workflow: it is the first step, and the key is used by 'check_task' to track stages. However, it does not explicitly state when not to use it or mention alternatives (e.g., 'reinstall_server'), leaving some room for an agent to confuse it with the higher-level reinstall operation. That said, the workflow context is clear enough for a competent agent.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description reveals a key behavioral trait beyond the annotations: invoking this tool triggers physical work by a data-center duty shift, which has real-world implications. It also instructs to describe the work in maximum detail in comment. Although it doesn't detail post-creation steps, annotations already cover read/write and destructive nature.

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 three concise sentences, each serving a distinct purpose: what the tool does, how to fill the critical comment field, and when to use it. It is front-loaded with purpose and contains no redundant 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?

The description provides enough context for correct invocation: purpose, usage condition, and key parameter detail. It doesn't explicitly describe the full consequence of creating the request (e.g., human dispatch, expected response), but combined with the schema and annotations, an agent can correctly select and use the tool.

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 100%, so all parameters are documented in the schema. The description adds meaningful guidance for the comment parameter, explicitly requiring maximum detail, which goes beyond the schema's 'Подробное описание требуемых работ'. This represents a small but valuable increment.

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 ('Создать' - create), a specific resource ('заявку на удалённые работы'), and the endpoint (rhr/add). It clearly distinguishes this tool from sibling RHR tools by stating it is for physical data-center shift work that cannot be done remotely.

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 explicitly states when to use the tool: 'Использовать, только если модуль удалённого управления сервером недоступен/не работает'. This gives a clear condition and implies the alternative is the remote server management module, leaving no ambiguity.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already mark readOnlyHint=false and destructiveHint=false. The description adds value by disclosing that the operation is asynchronous and that status must be tracked via check_task. It does not cover the confirmation requirement in prose, but that is present in the schema with a clear description.

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 two short sentences with no filler. It front-loads the core purpose and immediately adds the critical async/check_task detail. Every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a three-parameter tool with full schema descriptions and annotations, the description is nearly sufficient. It gives the essential async follow-up behavior and clear purpose. A small gap is the lack of any pointer to sibling snapshot operations, but that is not critical for correct invocation.

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 100%, with every parameter (id, name, confirm) already described in the input schema. The tool description adds no parameter-specific detail beyond the operation itself, so the schema carries the semantic burden and the baseline of 3 applies.

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 a specific verb and resource: 'Создать снапшот виртуальной машины' (create a VM snapshot) and even includes the API endpoint 'vm/create_snapshot'. This clearly distinguishes it from sibling tools like get_snapshots, restore_snapshot, and remove_snapshot.

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 async operation note and 'status via check_task' give some post-invocation guidance. However, it never explicitly says when to use this tool versus restore_snapshot or remove_snapshot, nor does it state any exclusions or prerequisites. Usage is largely implied by the name and purpose rather than made explicit.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already set destructiveHint: true and readOnlyHint: false, so the destructive nature is known. The description adds specific consequence: applications using the key will lose access. This goes beyond the annotation by explaining the impact, which is valuable context. No contradiction with annotations.

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: two short sentences that state the action, the endpoint, and the critical destructive consequence. It front-loads the essential information and contains no filler. Every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple delete operation with two parameters fully documented in the schema, the description covers the key behavioral aspect (destructive impact on applications). It does not describe the return value or post-deletion state, but for a delete call this is minor. Combined with annotations and schema, it is nearly 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 input schema fully describes both parameters: id (integer, 'ID ключа') and confirm (boolean, 'Must be true to run the operation.'). Schema coverage is 100%, so the description does not need to explain them further. The description adds no additional parameter semantics beyond the schema, warranting the baseline of 3.

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 (Удалить/delete) and the resource (API-ключ/API key), and even includes the endpoint path (api_keys/delete). This is specific and differentiates it from siblings like create_api_key, update_api_key, and list_api_keys. The destructive warning further reinforces its purpose.

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 when to use it (when you intend to revoke an API key and accept that dependent applications will lose access) but does not explicitly mention alternatives or conditions for choosing this over update_api_key (e.g., to disable rather than delete). The destructive note provides some guidance but not full exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already convey that this is a non-read-only but non-destructive operation. The description adds no behavioral traits beyond what the tool name states; it does not mention effects on the service, the confirm guard, or any lifecycle restrictions.

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 front-loads the action and resource. The parenthetical API name repeats the tool name, which is mildly redundant but does not significantly hurt clarity.

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 two-parameter tool, the schema and annotations cover parameter semantics and safety profile. However, the description lacks usage context and behavioral detail, leaving some gaps around when withdrawal is appropriate and what actually happens.

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 100%, and both parameters already have clear descriptions. The tool description adds no additional meaning beyond the schema, so the baseline score of 3 is appropriate.

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 a specific action, 'отозвать' (withdraw), and a clear resource, 'заявку на отмену услуги' (cancellation request). This distinguishes it from related siblings like request_cancellation and get_cancellation_requests without needing to open schemas.

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?

There is no explicit when-to-use or when-not-to-use guidance. The verb and resource imply this is the inverse of request_cancellation, and the sibling list provides context, but the agent must infer the usage rather than being told.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare destructiveHint=true and readOnlyHint=false, and the description reinforces this with 'ДЕСТРУКТИВНО'. It does identify the specific object being deleted, but it adds no additional behavioral context beyond what the annotations and the word 'delete' already convey. There is no contradiction with the annotations.

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 short, front-loaded phrase that states the action and resource in the first clause and warns about destructiveness in the second. There is no filler or unnecessary elaboration, making it efficiently scannable for an agent.

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 delete operation with two fully documented required parameters and destructive annotations, the description plus schema is sufficient to invoke the tool correctly. It clearly identifies the target and warns about destructiveness; however, it does not describe any postconditions or side effects, which keeps it from being completely thorough.

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 100%: contact_id is described as 'ID контакта' and confirm is described as 'Must be true to run the operation.' The description itself adds no parameter-level meaning beyond the schema, so the baseline score of 3 applies.

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, 'Удалить' (delete), and a specific resource, 'дополнительный контакт аккаунта' (additional account contact), and even names the underlying method whmcs/delete_contact. This clearly distinguishes it from sibling contact tools like add_contact, update_contact, and get_contacts.

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 when-to-use or when-not-to-use guidance and does not mention alternatives such as update_contact or get_contacts. The usage is only implied by the verb 'delete' and the tool name, with no explicit context or prerequisites.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already provide destructiveHint=true and readOnlyHint=false, but the description adds value by explicitly labeling the operation as ДЕСТРУКТИВНО and requiring the pdns/edit permission, along with the underlying API call name. This enriches the context beyond the structured hints and contains no contradiction.

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, with two short sentences that front-load the core action, then immediately state the destructive nature and permission requirement. Every word earns its place, and the formatting with capitalization adds emphasis without clutter.

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 destructive delete tool, the description covers the scope, destructive flag, and permission requirement, which are the key operational constraints. It does not mention the confirm parameter or return values, but the confirm parameter is documented in the schema, and there is no output schema, so these are not critical gaps. The information provided is sufficient for an agent to understand the operation's impact and prerequisites.

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 100%, so all three parameters are already well-documented in the input schema. The description itself does not add further parameter details, leaving the baseline at 3.

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 a specific verb (delete) and resource (domain by ID), and specifies the full scope: the DNS zone, the domain itself, and all its subdomains. This distinguishes it from sibling tools like delete_dns_subdomain and delete_dns_zone, making its purpose unambiguous.

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 by stating the exact scope (domain + zone + subdomains), so an agent can infer it should be used for full domain deletion rather than partial operations. However, it does not explicitly mention alternatives or exclusions, such as 'do not use for deleting only a subdomain', leaving some inference to the agent.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The destructiveHint annotation already covers destructiveness; the description adds value by explicitly requiring the pdns/edit permission. It does not disclose additional behaviors such as irreversibility side effects or confirmation handling, but the schema covers the confirm flag.

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 front-loaded sentence that conveys the action, scope, destructiveness, and permission requirement with no filler. Every element earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple destructive delete operation, the description plus fully documented schema covers purpose, scope, required permission, and destructive nature. It does not describe return values, but there is no output schema and the operation is straightforward.

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 100%, with every parameter already explained in the input schema. The description adds no parameter-specific meaning beyond the schema, so the baseline score of 3 applies.

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 a specific action (delete), a precise resource (DNS record), and the scope (from a zone), and even references the internal endpoint pdns/delete_dns. This clearly distinguishes the tool from sibling tools like delete_dns_zone, delete_dns_domain, and delete_dns_subdomain.

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 scope 'from zone' implies this is for individual DNS records, and the destructive warning plus required permission gives some usage context. However, it does not explicitly name alternative tools or state when not to use this tool versus deleting a zone or domain.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description adds an auth prerequisite not present in the annotations ('Требует права pdns/edit') and explicitly flags destructiveness with 'ДЕСТРУКТИВНО', reinforcing destructiveHint=true in natural language that an agent will weight heavily. It is fully consistent with annotations (readOnlyHint=false, destructiveHint=true), so no contradiction exists. It does not, however, describe irreversibility or potential cascade effects on related DNS records.

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?

Three short clauses totaling about ten words front-load the action, then the destructiveness warning, then the permission requirement. Every clause earns its place and there is no filler 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 3-parameter destructive delete with full schema documentation and matching annotations, the essential calling conditions are covered: purpose, destructiveness, permission prerequisite, and the required confirm flag (via schema). Minor gaps remain — no error behavior, no response shape (no output schema exists), and no disclosure of side effects despite openWorldHint=true — but nothing an agent needs to invoke it safely is missing.

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 100%, with all three parameters (id, confirm, server_id) already documented in the input schema, so the baseline of 3 applies. The description adds no parameter-level detail — it only restates the object being deleted. The confirm-flag requirement is left entirely to the 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 opens with a specific verb and resource — 'Удалить сабдомен из таблицы сабдоменов' (delete subdomain from the subdomains table) — and even references the internal endpoint (pdns/delete_subdomain). This clearly distinguishes it from sibling tools like delete_dns_domain, delete_dns_record, and delete_dns_zone, which act on different resource types.

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 phrase 'из таблицы сабдоменов' implies this is the subdomain-level deletion tool, which gives contextual differentiation from domain/record/zone siblings, but no alternative is named and no explicit when/when-not conditions are given. The permission note 'Требует права pdns/edit' states a precondition but does not guide tool selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare destructiveHint=true and readOnlyHint=false, so the description's 'ДЕСТРУКТИВНО' warning is consistent. The description adds valuable context beyond annotations: it specifies that the operation deletes all records and metadata, and that it requires pdns/edit rights. This is meaningful behavioral disclosure for a destructive tool.

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 two short sentences with no filler. The core action and destructive scope are front-loaded, followed by the permission requirement. Every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive two-parameter tool with a confirm flag and full schema coverage, the description is nearly complete. It covers what is deleted, the destructive nature, and the required permission. It does not describe the response format, but there is no output schema and the operation is a simple delete, so this is a minor 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 100%, so the schema already documents both parameters ('Имя зоны' and 'Must be true to run the operation'). The description adds no additional parameter-level detail beyond what the schema provides, so the baseline 3 is appropriate.

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 a specific verb ('Удалить' = delete), a specific resource ('DNS-зону по имени'), and the full scope of what is deleted ('вместе со всеми записями и метаданными'). It also names the internal operation (pdns/delete_zone), which distinguishes it from sibling tools like delete_dns_domain, delete_dns_record, and delete_dns_subdomain.

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 clearly indicates this is a destructive operation and requires the pdns/edit permission, which helps an agent decide whether it is authorized to call it. It does not explicitly name alternatives or state when not to use it, but the destructive warning and permission requirement provide clear context for when it is appropriate.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare destructiveHint=true and readOnlyHint=false, so the description adds value by naming the endpoint, explicitly restating destructiveness, and disclosing the authorization restriction for non-staff users. This goes beyond the structured annotations without contradicting them.

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 three short, purposeful sentences: the action with endpoint, the destructive warning, and the access caveat. It is front-loaded and contains no filler or redundant restating.

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 low-complexity tool with two required parameters, no output schema, and strong annotations, the description is nearly sufficient. It covers the operation, ID-based targeting, confirmation requirement via schema, and access restriction; a minor gap is not pointing the agent to a sibling like list_iso_images for obtaining a valid ISO ID, though that is inferable.

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 100%, with both id and confirm already documented. The description adds no new parameter-level meaning beyond the 'by ID' phrasing, so the baseline of 3 is appropriate.

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 the exact action (Удалить/delete), the target resource (ISO-образ), and the required identifier (by ID), plus the endpoint iso/delete. This clearly distinguishes it from sibling tools like list_iso_images, mount_iso, unmount_iso, and add_iso_image.

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 useful access context by warning that the operation is staff-only and that clients will likely receive a permission error, but it does not explicitly compare against alternatives or state when-not-to-use conditions. Usage is implied rather than fully guided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare destructiveHint=true and readOnlyHint=false; the description reinforces this with 'ДЕСТРУКТИВНО' and names the object that will be canceled, which is useful. It does not add other behavioral context such as irreversibility, authorization requirements, or side effects, so it remains at a middle score.

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 very short and front-loads the action, with the destructive warning placed immediately after. Minor redundancy ('Отменить/закрыть' and the parenthetical 'rhr/discard') prevents a perfect conciseness score.

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 two-parameter destructive tool with full schema coverage and relevant annotations, the description is mostly sufficient: it states the operation, the target, and the destructive nature. It could be more complete by clarifying the expected state after cancellation or explicitly requiring confirm=true in prose, though the schema already covers the confirm flag.

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 100%, with both id and confirm documented in the input schema. The description adds no additional meaning about parameter values, formats, or relationships beyond the schema, so the baseline score of 3 applies.

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 a specific action (cancel/close) and a clear resource (заявка на удалённые работы, rhr/discard), so an agent can tell this is the cancellation counterpart to create/list/add-comment rhr tools. It does not explicitly name a sibling to differentiate, 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 verb 'Отменить/закрыть' implies this tool is for canceling an existing remote-work request, but the description gives no explicit when-to-use guidance, prerequisites, or alternatives. Sibling tools like create_rhr_request and list_rhr_requests are not referenced, so an agent must infer the appropriate context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already mark the tool as read-only, so the bar for additional disclosure is lower. The description adds a concrete behavioral detail beyond the schema: the response typically contains a PDF in Base64 and should be saved/decoded. The 'usually' caveat also warns about possible format variability.

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?

A single sentence that front-loads the action, states the endpoint, and then gives the essential post-processing instruction. Every part earns its place with no filler.

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 one-parameter, read-only download tool with no output schema, the description is complete: it states what will be returned (Base64 PDF) and what to do with it. Parameter requirements are fully covered by the schema, and no extra operational context is needed.

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 100% and the single invoice_id parameter is already described as the invoice number. The description adds no parameter-specific meaning, so it matches the baseline for fully documented schemas.

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 opens with a concrete action and resource: 'Download invoice to PDF' and gives the exact endpoint whmcs/download_invoice. It also names the output format (PDF), which distinguishes it from sibling invoice lookups such as get_invoice/get_invoices.

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?

Usage is implied by the purpose: use this when you need the invoice as a downloadable PDF. There is no explicit 'when not to use' or comparison with get_invoice/get_invoices, so routing to alternatives is left to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare destructiveHint=true, and the description redundantly repeats 'ДЕСТРУКТИВНО' (DESTRUCTIVE). It adds the context 'служебная операция' (service operation), which suggests an internal administrative function. However, it does not disclose side effects, confirmation requirements, or irreversibility beyond what annotations provide, so it adds limited value.

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 very brief—two clauses—and front-loads the primary action. It is concise with no filler. However, it could have included a hint about the required confirm parameter or a caution about permanence, but for its length it is efficient.

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 simple 3-parameter schema, full schema coverage, and annotations (readOnlyHint=false, destructiveHint=true), the description is adequate but not complete. It does not mention the confirmation requirement (confirm=true) or any return behavior, though these are partially covered by the schema. For a destructive operation, an explicit statement that confirmation is mandatory would improve completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%: all three parameters (id, ip, confirm) have descriptions. The description itself does not mention or elaborate on any parameters, so it adds no additional meaning beyond the schema. Baseline 3 is appropriate.

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?

Description states a clear verb and resource: 'Удалить запись о NAT из базы данных' (delete NAT record from database), which is specific and unambiguous. However, it does not explicitly differentiate from sibling tools like remove_static_nat or clear_static_nat, which also deal with NAT, so it lacks explicit sibling differentiation.

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 versus alternatives. It only labels it as a 'служебная операция' (service operation), implying internal use, but does not specify conditions, prerequisites, or scenarios where this tool is preferred over similar NAT-related operations.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already signal a mutating, non-destructive operation; the description adds the auth requirement (pdns/edit) and confirms the update semantics. It does not disclose side effects or exactly what changes are applied, but the permission note provides some context beyond annotations.

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 two short sentences, front-loaded with the primary action and followed by a necessary permission note. No wasted words.

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 three-parameter mutation with complete schema coverage and annotations, the description plus schema is mostly sufficient. It lacks any mention of what fields the update changes or the effect of confirm, and there is no output schema, but the risk is low.

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 100%: id, confirm, and server_id each have schema descriptions. The description itself adds no parameter-level detail, so the baseline score of 3 applies.

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 the action ('Обновить сабдомен' = update subdomain) with a clear verb and resource. The endpoint reference and sibling names (add/delete/list_dns_subdomains) make the operation distinguishable from related DNS 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 provides no explicit guidance on when to use this tool versus add_dns_subdomain or delete_dns_subdomain. It only states a permission requirement; any usage context must be inferred from the tool name and siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate readOnlyHint=false and destructiveHint=false, so the write nature is expected. The description adds no behavioral context beyond the bare action—no mention of side effects, irreversibility, authorization requirements, or the openWorldHint implication that external billing systems are affected.

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, front-loaded sentence with no filler. It is appropriately concise, though its brevity verges on under-specification rather than being a model of efficiency.

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 mutation tool with no output schema and an ambiguous term ('next'), the description is incomplete. It does not explain what 'next invoice' means operationally, what the result will be, or what the agent should expect or verify after calling it.

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 100%, with clear descriptions for id and confirm. The tool description adds no extra meaning to these parameters, so the baseline of 3 is appropriate; it neither compensates nor improves on the 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 states a specific verb ('create') and resource ('invoice for the server'), which distinguishes it from read-only sibling tools like get_invoice or get_server_invoices. However, the term 'next' is ambiguous and the description does not clarify whether it means the next due invoice, the next period, or the next in sequence, keeping it from 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 description offers no guidance on when to use this tool versus alternatives like create_addfunds_invoice or get_invoice. There is no mention of prerequisites, exclusions, or context that would help an agent decide between billing-related tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, and the description adds useful non-obvious context beyond that: it reports account type/role, available calls, and attached server IDs, and frames the tool as a connection check. No contradiction with the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences, with the core resource and returned content front-loaded and no redundant filler. The connection-check note earns its place as practical guidance.

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, read-only introspection tool with annotations already covering safety, this description is complete: it states the endpoint, what data can be expected, and a common use case. No output schema exists, but the listed fields sufficiently set expectations.

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 has no properties, so the baseline is 4. There is no parameter information to add, and the description correctly focuses on the returned account/token information.

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 names a specific operation (get current API token and account info) and a resource (auth/info), and it lists concrete contents: available calls, account type/role, attached server IDs. This is distinguishable from sibling key-management tools like get_api_key/list_api_keys because it is explicitly about the current token's account context.

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 a clear use case: 'useful for checking the connection'. However, it does not explicitly mention alternatives or exclusions, so it scores below a fully explicit routing description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description adds little beyond the readOnlyHint annotation; it only restates that the operation returns information. It does not disclose what fields are returned, whether the key secret is exposed, or any other behavioral nuance.

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 with no filler. It front-loads the core purpose and appends the endpoint reference, making it easy to parse.

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 get-by-id tool with one fully documented parameter and readOnly annotations, the description is largely sufficient. The main gap is not describing the returned key information, but the absence of an output schema lowers the burden on the description.

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 100% and the id parameter is already documented as the key ID from list_api_keys. The description does not add parameter-level meaning, so the baseline 3 applies.

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 that the tool returns information about one specific API key, which distinguishes it from list-oriented siblings like list_api_keys and list_server_api_keys. It lacks an explicit verb but 'information about' clearly conveys a read/retrieve 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?

No guidance is given on when to use this tool versus alternatives such as list_api_keys or get_api_key_history. The word 'specific' weakly implies retrieving a single key, but there is no explicit context or exclusion.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds that the result is period-scoped history, but it does not disclose details like pagination, record limits, or what constitutes 'usage'. This is acceptable 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 compact sentence with no redundant words. It is appropriately sized for a simple read-only tool, though it could be slightly more informative about output or defaults.

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 read-only history tool, the required id and optional period fields are documented in the schema, and annotations cover safety. However, the description does not mention what happens when period_from or period_to are omitted, nor what the response contains, and there is no output schema to fill that 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?

The input schema already provides 100% coverage with descriptions for all three parameters: id, period_to, and period_from. The description adds no additional semantic value beyond what the schema provides, so the baseline of 3 is appropriate.

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 a specific operation: retrieving API key usage history over a period, and even includes the endpoint 'api_keys/history'. It clearly identifies the resource and action, though it does not explicitly differentiate from sibling tools like get_api_key or list_api_keys.

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 about when to use this tool versus alternatives such as list_api_keys, get_api_key, or list_server_api_keys. The description only explains what the tool does, leaving usage context to be inferred.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=trueestern and openWorldHint=true, so the safety profile is covered. The description adds value by listing the kind of data returned (contacts, currency, status), but it does not disclose any additional behavioral traits such as data freshness, authentication requirements, or how open-world changes might affect results.

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?

A single concise sentence that leads with the resource and action, then immediately lists the returned fields. No filler 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 parameterless read-only getter, the description is complete: it identifies the data source, the returned fields, and the scope. There is no output schema, but the description's enumeration of returned content sufficiently informs the agent of 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, so the schema covers everything. The description does not need to explain parameters, and the baseline of 4 applies. No additional parameter information is required.

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 a specific verb-resource pair ('get client data from billing') and enumerates the returned content (contacts, currency, account status), referencing the underlying whmcs/get_client endpoint. This clearly distinguishes it from siblings like get_account_info, which focuses on account-level information rather than billing client data.

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: call it when you need billing client details such as contacts, currency, or account status. However, it does not explicitly compare against alternatives like get_account_info or update_billing_client, nor does it state when not to use it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds the 'active' filter as a behavioral scope, which is useful, but it does not disclose whether results are paginated, sorted, or limited to a particular status beyond 'active'.

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?

A single, front-loaded sentence communicates the operation, resource, and scope without filler. The parenthetical endpoint reference is minor but does not hurt conciseness.

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 read-only list operation with one optional documented parameter and no output schema, the description is largely sufficient. The only gap is a slightly ambiguous definition of 'active' and no mention of how the optional id changes the result set, but annotations and schema cover most operational context.

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 100%: the single optional id parameter is already documented as 'ID сервера (фильтр)'. The description does not add extra meaning about how id interacts with the 'active' filter, but the baseline of 3 applies because the schema fully documents the parameter.

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 names a specific resource ('активных заявок на отмену услуг') and a clear operation ('Список'), so an agent knows this retrieves active cancellation requests. It does not explicitly contrast with siblings like request_cancellation or delete_cancellation_request, but the word 'активных' adds scope and makes the purpose immediately distinguishable.

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 about when to use this tool versus related tools such as request_cancellation or delete_cancellation_request. It does not state that this is for viewing existing cancellation requests before acting on them, nor does it mention any conditions or alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The readOnlyHint and openWorldHint annotations already cover the read-only and externally-changing nature of the data. The description adds the 'account contacts' context and the exact endpoint name, but does not describe response format, ordering, or any other behavioral details. There is no contradiction with the annotations.

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 short sentence that front-loads the purpose and adds only the relevant endpoint identifier. There is no filler or redundant explanation.

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 no-parameter, read-only list operation, the description gives enough information for an agent to invoke it correctly: call it and get the account's additional contacts. No input setup, prerequisites, or complex return handling are needed, and annotations cover the safety profile.

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 schema coverage is trivially 100% and the description has nothing to add. Per the baseline for zero-parameter tools, this is adequate.

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 clear action ('list') and a specific resource ('additional contacts of the account'), and the parenthetical endpoint 'whmcs/get_contacts' pins down the exact API. Among siblings like add_contact, update_contact, and delete_contact, it unambiguously identifies this as the read-only list tool.

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 verb 'list' implies the tool is for retrieving contact data, which gives basic usage context. However, it does not explicitly say when to prefer this over sibling contact tools or state that mutations should use add_contact/update_contact/delete_contact.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and openWorldHint=true, covering the safety profile. The description adds the useful context that the history covers credit accruals and debits and references the backend operation (whmcs/getcredits), but it does not disclose filtering, ordering, pagination, or account-scoping 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 single concise sentence that front-loads the core resource and includes the backend identifier. It is efficient, though it omits some context that would make the definition more self-sufficient.

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 one-parameter read-only getter with no output schema, the description gives a minimal but workable picture of what the tool returns. It is not fully complete because it leaves the relationship between the server id and the personal account implicit and offers no contrast with sibling billing tools.

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 fully documents the only parameter id as 'ID сервера' with type integer, so the baseline is 3. The description adds no parameter-level meaning; it also leaves a small ambiguity by describing the resource as a 'personal account' while the parameter points to a server ID.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description ('Движение средств по лицевому счёту: начисления и списания кредитов') clearly identifies the resource as credit-related account movements and specifies the included data (accruals and debits). It does not use an explicit verb like 'retrieves', and it does not explicitly contrast itself with related billing tools such as get_transactions or get_invoices, so it falls 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?

There is no guidance on when to choose this tool over the many related billing tools in the sibling list (e.g., get_transactions, get_invoices, get_account_info). The description implies the tool returns credit history, but it provides no exclusions, prerequisites, or alternative-selection criteria.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and openWorldHint=true, so the agent knows this is a safe read operation. The description adds that the data comes from an authoritative server (pdns/view_zone), which is useful context. It does not disclose response format, pagination, or whether the zone must exist, but the annotations cover the safety profile.

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 sentence that front-loads the resource ('Содержимое DNS-зоны') and lists record types. It is concise and informative, though it could be slightly more structured with a usage hint.

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 read-only tool with one well-documented parameter and no output schema, the description is mostly adequate. It lacks explicit guidance on when to use it versus sibling DNS tools and does not mention error cases (e.g., nonexistent zone), but the annotations and schema cover the essential safety and parameter information.

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 100%: the only parameter 'zone' is described as 'Имя зоны, например example.com'. The description adds no additional parameter semantics beyond the schema, so the baseline 3 applies.

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 a specific verb ('get') and resource ('DNS zone contents'), listing record types (A, AAAA, CNAME, MX, TXT) and the authoritative source (pdns/view_zone). It is clear what the tool does, though it does not explicitly distinguish itself from sibling tools like list_dns_zones or get_ptr_record.

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: call it to retrieve all records in a DNS zone. It does not explicitly state when to use this tool versus alternatives such as list_dns_zones (which likely lists zones) or get_ptr_record (which fetches a single PTR record). The context is clear but exclusions/alternatives are not stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds no behavioral detail beyond its purpose—no mention of response content, authentication needs, pagination, or edge cases. It neither contradicts nor meaningfully extends the annotation data.

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?

A single front-loaded sentence states the resource and operation without wasted words. The parenthetical endpoint name is compact and useful for traceability. The description is appropriately sized for such a simple 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 read-only single-parameter tool with high schema coverage and no output schema, the description provides enough to understand the core purpose. It could be more complete by naming alternatives or indicating the shape of the returned invoice data, but these are minor gaps given the tool's simplicity.

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 100%: the only parameter invoice_id is documented as 'Номер инвойса'. The tool description does not add further parameter context, but with full schema coverage the baseline of 3 is appropriate.

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 resource as 'конкретного инвойса' (a specific invoice) and the operation as retrieving its data, which distinguishes it from the sibling get_invoices. However, it lacks a strong imperative verb and the parenthetical 'whmcs/get_invoice' is useful but slightly cryptic.

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 about when to use this tool versus get_invoices or download_invoice. The phrase 'для оплаты' hints at a payment context, but it does not explicitly state when this tool is preferred or how it differs from related invoice tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The readOnlyHint annotation already covers the safety profile, and the description adds the account scope and the 'full list' behavior. However, it does not disclose return shape, pagination, or sorting. With annotations present, this is adequate 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?

A single, front-loaded sentence with no filler. The parenthetical whmcs/get_invoices endpoint adds useful context without bloating the description.

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 read-only list operation, the description is essentially complete. It does not describe the output schema, but the 'list of invoices' phrasing gives a reasonable expectation; no output schema exists anyway.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has zero parameters, so there is nothing for the description to add. Per the baseline for zero-parameter tools, this is sufficient.

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 a specific verb and resource: 'Полный список инвойсов аккаунта' (full list of account invoices). This clearly distinguishes it from sibling tools like get_invoice (singular) and get_server_invoices (server-scoped).

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 about when to use this tool versus alternatives such as get_invoice, get_server_invoices, or download_invoice. The description only states what it does, leaving selection entirely to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and openWorldHint=true, so the tool is known to be non-destructive. The description adds no additional behavioral context—no mention of side effects, permissions, rate limits, or response specifics. It simply restates the purpose, providing no value beyond the structured annotations.

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 short sentence, which is concise and well-structured. However, it is so terse that it leans toward under-specification rather than efficient communication. The sentence provides only bare purpose and even includes a redundant endpoint reference, so it lacks impactful content that would merit a higher score.

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?

With no output schema, the description should clarify what information is actually returned or how the IP is used, but it does not. There is no mention of return fields, error behavior, or scope. The brevity leaves an agent guessing what 'information about the network interface' entails, which is insufficient for a complete definition.

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 fully describes the sole 'ip' parameter with a description ('IP-адрес'), giving 100% coverage, so the baseline is 3. The description does not add any extra meaning about IP format, validation, or interpretation, so it neither improves nor degrades the semantic clarity.

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 the tool provides information about a network interface given an IP address, which is a clear resource and action (getting info). However, it does not explicitly differentiate from sibling tools like get_network_status or get_ptr_record, so it falls 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?

There is no guidance on when to use this tool vs. alternatives, no scenario examples, and no mention of excluded cases. The description is purely a statement of purpose without usage context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, so the agent knows it is safe. The description adds value by enumerating the returned attributes (port, switch, VLAN, speed, MAC, connection status), which goes beyond the annotation and helps the agent interpret results. No contradictions.

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 main purpose and immediately lists the key data points. Every word is informative with no filler.

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?

With no output schema, the description supplies essential information about the content of the response (the listed network attributes). It does not explicitly state whether the result is an array or single object, but the plural 'интерфейсов' implies multiple. For a simple read-only getter, this is largely sufficient.

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 covers the single parameter 'id' with its description ('ID сервера'), so the description does not need to add more. The description itself provides no additional parameter meaning, but with 100% schema coverage, the baseline of 3 is appropriate.

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 a specific verb and resource: it returns the state of server network interfaces, listing concrete fields (port, switch, VLAN, speed, MAC, connection status). This clearly distinguishes it from sibling get_* tools like get_power_status or get_server_sensors, which target different aspects.

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 clear context—it is for retrieving network interface status—but does not explicitly state exclusions or mention alternative tools. Since the name and description unambiguously convey the use case, it meets the 'clear context, no exclusions' level.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations declare readOnlyHint=true and openWorldHint=true, which are consistent with the description's read-only nature. However, the description adds no additional behavioral details such as return format or potential side effects, relying on the annotations.

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 Russian, translating to 'Payment methods of a specific invoice (whmcs/getpaymentgw).' It is front-loaded with the purpose and contains no redundant words.

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 read-only tool with one well-documented parameter and no output schema, the description is largely sufficient. It clearly indicates the input (invoice_id) and the purpose (payment methods). While it does not describe the return structure, this is a minor gap given the tool's simplicity.

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 only parameter invoice_id is fully documented in the schema with a description ('Invoice number'), achieving 100% schema coverage. The tool description does not add extra parameter context, but the schema already provides sufficient meaning.

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 a clear purpose: retrieving payment methods for a specific invoice. The verb 'get' is implied by the name, and the resource 'payment methods' plus scope 'specific invoice' distinguishes it from sibling tools like get_invoice or download_invoice.

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 such as get_invoice or get_transactions. The description only mentions the underlying API call (whmcs/getpaymentgw) without providing context on selection criteria.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=trueo, so the read-only nature is covered. The description adds the data source context ('net/show_cacti') and the time-period variants, but does not disclose what the returned graphs look like (e.g., image URLs, binary data, or a list). No contradiction with annotations.

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?

A single concise Russian phrase conveys the tool's purpose and period options with no filler words. It is appropriately sized for the tool's simplicity.

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 read-only tool with fully documented parameters and a readOnlyHint, the description is mostly adequate. However, with no output schema, the description does not clarify the return format of the graphs, which is a meaningful gap for an agent deciding how to consume the response.

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 100%, so all three parameters are already documented. The description merely restates the graph parameter's day/month/year mapping without adding new semantic detail beyond the schema. Baseline 3 is appropriate.

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 resource (port) and data type (load graphs over a period), and lists the day/month/year variants. It lacks an explicit verb, relying on the tool name for the action, but it is specific enough to distinguish from unrelated siblings like port_on/off or get_network_status.

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, and no exclusions or sibling references are provided. The usage context is only implied: use it when port load graphs are needed. This is minimal viable information but lacks explicit routing.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The annotations already declare readOnlyHint=true and openWorldHint=true, covering side-effect freedom and non-deterministic output. The description adds 'current' and '(on/off)', reinforcing the live nature of the value. It does not discuss authentication or response format, but with annotations present, this is acceptable.

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, front-loaded sentence that conveys the tool's purpose and expected values with no filler. It is appropriately sized for the tool's simplicity and earns its place entirely.

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 read-only status tool with one documented parameter and annotations covering side effects, the description is nearly complete. It does not state the exact response structure, but the '(on/off)' phrase gives the key value domain. Minor gaps around error cases are tolerable given the low complexity.

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 100%: the 'id' parameter is documented as 'Server ID'. The description adds no additional parameter meaning or context. The schema fully carries the semantic load, so the baseline score of 3 applies.

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 a specific verb ('get') and resource ('power status') and clarifies the possible return values ('on/off'). It is easily distinguished from siblings like get_network_status or power_on/power_off by the resource it queries. The purpose is unambiguous.

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 like get_server. However, the name and description make the intended use obvious: checking the current power state. The usage is implied but not elaborated with exclusions or alternative suggestions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The annotations already declare readOnlyHint and openWorldHint, so the read-only safety profile is covered. The description adds the useful behavioral caveat that authorization may be required depending on rights, which is not present in the annotations.

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 only two short sentences, with the core behavior front-loaded and no filler, redundancy, or restatement of the tool name.

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, optional-parameter read operation with a clear schema and read-only annotations, the description is adequate: it specifies that either a single preset or all presets can be returned and warns about authorization. It could mention the response shape, but the tool's low complexity makes this a minor 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?

The schema already documents the sole parameter id with a description covering the optional-ID behavior ('без него — список всех'). Since schema description coverage is 100%, the description adds no meaningful parameter semantics beyond what the schema provides.

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 a specific resource (presets) and action (retrieve information), and clarifies the optional scope: a specific preset or all presets. It does not explicitly contrast with sibling tools like list_presets or search_presets, leaving differentiation implicit.

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 conveys the basic use case and notes that authorization may be required depending on permissions. However, it gives no explicit guidance about when to prefer get_preset over the closely related list_presets or search_presets tools, so usage context is implied rather than stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and openWorldHint=true, covering the safety profile. The description adds the fact that no token is required ('Токен не требуется'), which is useful behavioral context beyond annotations. However, it doesn't describe the response format or any other behavioral traits. With annotations covering the read-only nature, a 3 is appropriate – some added value but not rich 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?

Two short sentences with no wasted words. The purpose is front-loaded ('Цены на доступные пресеты...'), followed by the token requirement. It's appropriately concise for a simple tool, though it could arguably include a bit more context about usage.

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 read-only tool with one optional parameter and no output schema, the description covers the purpose and the token requirement adequately. Given the tool's low complexity, it's fairly complete. The lack of return-format description is a minor gap for such a simple query tool, but not critical.

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 100% – the single `currencies` parameter is fully documented in the schema with format examples (EUR,USD) and a default (EUR). The description adds nothing beyond the schema's parameter documentation, merely referencing 'specified currencies'. Baseline 3 is correct when the schema carries the full parameter meaning.

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 a specific verb and resource: it returns prices (Цены) for available presets in specified currencies. This clearly distinguishes it from siblings like list_presets (which lists presets) and get_preset (which gets a single preset). The endpoint hint '(presets/info)' is somewhat cryptic for non-Russian speakers but doesn't obscure the purpose. It's clear but doesn't explicitly name its sibling differentiation.

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 explicit guidance on when to use this tool versus alternatives such as list_presets, search_presets, or get_preset. There are no stated conditions, exclusions, or alternative routing. An agent must infer the usage context purely from the purpose statement, which is a significant gap given the many sibling preset-related tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and openWorldHint=true, covering the safety profile. The description adds the specific resource (PTR record) but does not disclose additional behaviors such as error handling, authentication needs, or response format. Given the annotation coverage, this is adequate 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?

A single concise sentence that conveys the purpose and includes the API path. There is zero fluff, and the essential information is 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?

For a simple read-only tool with two well-described parameters, the description is sufficient. It does not specify the return structure, but given no output schema and the straightforward nature of the operation, this is a minor gap. The tool's complexity is low, so the description is adequately 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 input schema has 100% description coverage, with each parameter (id, ip) fully documented. The description adds no extra meaning beyond what the schema provides, so the baseline of 3 applies.

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 a specific verb (get) and resource (PTR record for an IP address), clearly identifying what the tool returns. The inclusion of the internal API path 'ip/get_ptr' adds specificity and distinguishes it from sibling update_ptr_record by its read-only nature.

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 (to fetch a PTR record) but does not explicitly state when to use this tool over alternatives like update_ptr_record. There is no guidance on exclusions or prerequisites, though the get/update distinction is inferable from the name.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and openWorldHint=true, covering the safety profile. The description adds that the tool returns full information including configuration, network, status, and location, which sets expectations for the content. However, it does not disclose any other behaviors like response format, pagination (unlikely for a single object), or potential performance characteristics. Given the annotations, this is adequate 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?

A single, front-loaded sentence that states the purpose and key scope in a compact manner. No redundant words, and the information is organized logically (ID, then what is returned). Efficient for an agent to parse.

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 get-by-ID operation with one parameter and no output schema, the description is fairly complete. It lists the major categories of returned data, which helps the agent understand what to expect. It could be more explicit about the exact structure or any limitations, but given the tool's simplicity and annotation coverage, it is adequate.

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 one parameter (id) with a clear description ('ID сервера в InvAPI'), and schema coverage is 100%. The description repeats 'by its ID' but adds no extra semantic detail beyond the schema. Per the baseline for high schema coverage, this is a 3.

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 a specific verb ('get') and resource ('server'), and clarifies scope by ID. It lists the categories of information returned (configuration, network, status, location), which distinguishes it from more specific siblings like get_server_sensors or get_server_billing_data. However, it does not explicitly contrast with get_servers (the plural listing tool), leaving some ambiguity about when to use this vs. the list.

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 vs. alternatives. It is implied that you use it when you have a specific server ID and want full details, but the description does not mention exclusions or refer to sibling tools such as get_servers for listing. The agent must infer usage from the parameter and naming.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds the server-rental scope and WHMCS backend reference, but it does not describe response format, pagination, or any other behavioral traits; still, nothing contradicts the annotations.

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 short clause with no filler, and the core scope appears immediately. It is appropriately terse, though the brevity borders on under-specification because it omits usage and output context.

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 one-parameter, read-only lookup, the core purpose is minimally clear. However, with no output schema and many adjacent billing tools in the sibling list, the description leaves the agent reliant on name-based inference rather than explicit guidance about what data is returned or when this tool is the right choice.

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 100%, and the single required id parameter is already documented as 'ID сервера'. The description adds no additional meaning about the parameter beyond what the input schema already provides, so the baseline of 3 applies.

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 identifies a specific resource ('payment information for server rental') and includes the internal endpoint whmcs/get_billing_data, so the tool's purpose is clear. However, it is phrased as a noun phrase rather than a verb action and does not distinguish itself from nearby billing siblings such as get_server_invoices or get_billing_client.

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?

There is no guidance on when to use this tool versus alternatives, nor any mention of when not to use it. The sibling list contains several billing-related tools, but the description gives the agent no routing information to select between them.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint and openWorldHint, covering the safety profile. The description adds minimal behavioral context via the plural 'invoices' and the internal WHMCS endpoint reference, but it does not describe output shape, pagination, ordering, or possible empty results. This is acceptable for a simple read-only lookup but adds little beyond annotations.

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, front-loaded sentence with no redundant words. The parenthetical backend reference is useful and compact, making the definition appropriately sized for the tool's simplicity.

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 one-parameter read-only lookup, the description plus schema is sufficient for an agent to call it correctly: it knows the required server id and that the result is invoices related to that server. A minor gap is the lack of explicit output structure or differentiation from get_server_billing_data, but this is not blocking.

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 100% description coverage for the only parameter, id, described as 'ID сервера'. The tool description itself adds no parameter-level detail, so the baseline score of 3 applies.

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 resource (invoices) and the scope (a specific server), which aligns with the tool name. It does not use an explicit verb like 'list' or 'retrieve,' but the meaning is unambiguous and distinguishable from generic invoice tools by the server scoping.

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?

Usage is implied: call this tool when you need invoices tied to a particular server. However, it does not explicitly state when to prefer this over siblings like get_invoices, get_invoice, or get_server_billing_data, nor does it mention any exclusions or fallback conditions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description reveals an important side effect: before the first call it automatically updates inventory via eq/update_servers. This directly contradicts the readOnlyHint=true annotation, which signals no state modification. Per the contradiction rule, this dimension must be scored 1.

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 two crisp sentences with no filler. It packs in purpose, filter capability, a side effect, return summary, and sibling routing. It earns its length.

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 listing tool with schema-described optional filters, the description covers the essentials: what it returns, the auto-update behavior, and how to get full data. It does not describe pagination or filter combination semantics, but those are not critical for a simple list call.

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 100%, so the structured definitions of ip, mac, group, status, and location already carry the parameter semantics. The description only says 'with filters' and adds no meaning beyond the schema, so the baseline 3 applies.

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 job: list Hostkey account servers with filters. It also distinguishes itself from get_server by noting it returns IDs and brief data, while get_server provides the full card. An agent can immediately tell which tool to use for an overview versus a detailed server view.

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 gives a direct routing cue: use get_server for a full server card, implying get_servers is for filtered overview listing. It doesn't explicitly compare against other list/search siblings, but the most relevant alternative is named and differentiated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, and the description is consistent with that. The description adds useful behavioral and contextual information by scoping the tool to bare-metal servers and listing the sensor families covered, which the annotations do not convey. It stops short of describing error cases or units, but for a read-only sensor endpoint the added scope is meaningful.

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 with a parenthetical list of sensor types and one important constraint. Every element earns its place, and there is no redundant restatement of the tool name or schema.

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 one-parameter read-only tool, the description sufficiently covers purpose, sensor categories, and hardware scope for selection and invocation. An output schema is absent, so result structure and units would have been welcome, but they are not essential for calling 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 only parameter, 'id', is already fully documented in the schema as 'ID сервера', and schema description coverage is 100%. The tool description adds no additional meaning about the parameter, so the baseline of 3 applies.

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 identifies the resource (hardware sensors) and the contents (temperatures, voltages, fans), and clearly limits the operation to bare-metal servers. It lacks an explicit action verb, but 'readings' combined with the tool name makes the retrieval purpose clear. The bare-metal qualifier also helps distinguish it from VM-related siblings.

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 phrase 'Только для bare-metal' explicitly restricts usage to bare-metal hardware, giving the agent a clear selection criterion. It does not name a specific alternative for virtual servers, so the guidance is clear but not exhaustive.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and openWorldHint=true, covering safety and open-world semantics. The description adds that tags are arbitrary key-value pairs, which is useful context, but does not disclose any further behavioral details such as output format or potential edge cases.

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 two concise sentences, front-loaded with the core purpose ('All server tags') and immediately clarifies the nature of the data. No unnecessary words.

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 read-only tool with one well-documented parameter and no output schema, the description adequately covers the essential purpose and data type. It does not mention return format, but that is implied by 'all tags'. The tool is sufficiently complete for an agent to understand and invoke 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 only parameter 'id' is fully described in the schema with 'ID сервера'. The description does not add any additional meaning or constraints beyond the schema. With 100% schema coverage, a baseline of 3 is appropriate.

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?

Description clearly states the tool retrieves all server tags and specifies they are key-value pairs, which is a specific verb+resource. It does not explicitly distinguish from sibling tools like search_servers_by_tag, but the intent is clear from the name and description.

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 versus alternatives. The description does not mention that it is for listing tags of a specific server, nor does it contrast with search_servers_by_tag or other related tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The readOnlyHint=true annotation already communicates that this operation does not modify state, and the description is consistent with that. The description adds return-shape context (name, snapshot_id, date) and scopes the operation to a VM, which is useful. It does not disclose ordering, pagination, or behavior when no snapshots exist, but annotations carry the safety profile.

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 sentence, front-loaded with the action and resource, then compactly lists the output fields. There is no filler or repeated schema content, and the endpoint hint adds useful provenance without bloating the text.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With one fully documented parameter, read-only annotations, and no output schema, the description gives enough for correct invocation: what it lists, for which VM, and what fields to expect. It could mention ordering or empty-list behavior, but these are minor gaps for such a simple read-only tool.

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 100%, and the property description already documents id as 'ID виртуальной машины'. The tool description repeats the VM scoping but adds no new parameter format, constraints, or default information. Baseline 3 applies because the schema fully documents the only parameter.

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 and resource: 'Список снапшотов виртуальной машины' (list of VM snapshots), and enumerates the returned fields: name, snapshot_id, date. This clearly distinguishes the read-only listing operation from mutation siblings like create_snapshot, remove_snapshot, and restore_snapshot. The parenthetical '(vm/get_snapshot)' does not obscure the meaning.

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 makes the use case clear: call this when you need the snapshot list for a specific VM identified by id. It does not explicitly name alternatives or exclusion conditions, so agents must infer the contrast with snapshot mutation tools from the verb. This is clear context without formal when-not guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description is consistent with the readOnlyHint=true and openWorldHint=true annotations, confirming this is a safe read operation. It adds the endpoint name 'stocks/show' but does not disclose any further behavioral traits such as response shape, pagination, or potential absence of data. Since annotations already cover the safety profile, this is adequate 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 with no redundant words. The endpoint reference in parentheses adds useful context without bloating the text.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read-only get-by-id tool with one well-documented parameter and safe annotations, the description is mostly complete. The only minor gap is that 'детальная информация' does not enumerate which details are returned, and there is no output schema to fill that gap; nevertheless, the intended use is clear.

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 100%, and the only parameter 'id' is already documented as 'ID stock-сервера из list_stock_servers', so the schema carries the semantic burden. The description itself does not add parameter-level detail, but it does not need to given full schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a clear action and resource: retrieving detailed information about a specific stock-server, with the endpoint 'stocks/show' as a cross-reference. It distinguishes itself from list_stock_servers by specifying 'конкретном' (specific), though it does not explicitly contrast with get_server.

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?

Usage is implied rather than explicit: the phrase 'конкретном stock-сервере' suggests using this tool when you already have a particular stock-server ID, and the schema reference to list_stock_servers hints at a list-then-get flow. However, there is no direct 'use this instead of X' guidance or explicit alternative comparison.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is known. The description adds minimal behavioral context: it is scoped to client-account transactions but says nothing about default behavior, result shape, pagination, or how the optional filters interact. It does not contradict annotations but adds little beyond them.

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, focused sentence that immediately states the resource and scope. There is no filler, redundancy, or structural waste. It is concise 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?

For a read-only list with two optional filters and no output schema, the description is adequate but has gaps: it does not explain return format, pagination, or whether invoice_id and transaction_id are combined as AND/OR. Given the low complexity and annotations covering safety, a 3 is fair.

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 100% (both invoice_id and transaction_id have descriptions). The tool description adds no extra meaning about how parameters relate or behave, so it does not compensate beyond the schema. Baseline 3 is appropriate per the rubric.

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 the resource ('transactions by client account') and implies the action 'list' via the noun 'Список' (list). It is clearly distinct from sibling tools like get_invoices and get_credit_history, though it does not explicitly name an alternative. This is a clear purpose with only minor lack of an explicit verb.

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 this tool is for listing transactions for a client account, but provides no explicit guidance on when to prefer it over alternatives, nor any exclusions or conditions. It relies on the tool name and context to convey usage. There is no mention of when not to use it or of related tools such as get_invoices.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The readOnlyHint and openWorldHint annotations already cover the safety and possible incompleteness of the result set, but the description adds no behavioral detail beyond restating the client-uploaded scope. It does not mention ordering, pagination, representation, or any caveats, so the description contributes little beyond the annotations.

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 focused phrase that front-loads the resource type and scope with no redundant words or filler. Despite being terse, it is appropriate for a zero-parameter read-only list.

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 read-only operation, the description is minimally sufficient, and no invocation details are missing. However, it does not distinguish get_uploaded_isos from the very similar sibling list_iso_images, nor does it describe the output shape, so an agent still has to infer selection and return expectations.

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?