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

The critical warning about the contact being created with a random email that must be changed in Invapi is non-obvious and valuable. Annotations already convey that the operation is not read-only and not destructive, and the description adds concrete post-creation behavior beyond those flags.

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 tight sentences with no filler. The warning is front-loaded after the action and earns its place, and the endpoint parenthetical is brief and useful.

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

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

For a simple one-parameter tool with a fully documented schemaaint, the description covers the essential behavioral caveat. The only minor gap is that 'Invapi' is not explained, but the overall context is sufficient for an agent to call the tool correctly.

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

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

Schema coverage is 100% and the only parameter, 'confirm', is self-describing in the schema. The description adds no parameter-level semantics, but none are really needed here since the boolean confirm parameter is fully documented.

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 ('Добавить'/'add'), a clear object ('дополнительный контакт в аккаунт'), and even includes the endpoint 'whmcs/add_contact'. This clearly distinguishes it from sibling tools like update_contact and delete_contact without needing to open their 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?

The usage context is implied by the verb and resource: it is for adding, not updating or deleting, a contact. However, the description does not explicitly mention alternatives such as update_contact/delete_contact, nor does it say when this tool should be preferred over 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 indicate readOnlyHint=false (write operation) and destructiveHint=false, so the write nature is covered. The description adds the permission requirement and explicitly mentions the two side effects (creating a zone and adding a domain), which gives some additional behavioral signal. It does not elaborate on atomicity, reversibility, or failures, but for a create operation the disclosed behavior is adequate.

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 and clear, with the primary action front-loaded in the first sentence and the permission requirement in the second. There is no redundant text or filler. Every component serves a purpose.

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 a simple two-parameter tool with no output schema and annotations covering the safety profile, the description is sufficient for an agent to understand the operation. It covers the core action, the side effect, and the required rights. It could have explicitly mentioned the confirm parameter, but that is already fully documented in the schema. The only minor gap is the lack of differentiation from add_dns_zone, which is not critical for completing the 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 schema already documents both parameters (name and confirm). The description does not add extra meaning about parameter formats or the role of 'confirm', beyond what is present in the schema. Since the schema carries the full burden, 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 action ('Создать DNS-зону и добавить домен в таблицу доменов') with a clear resource (DNS zone, domain) and even references the backend function (pdns/add_domain). It is understandable and distinguishes the operation from siblings like add_dns_zone or add_dns_record, though it does not explicitly name alternatives. The resource and verb are specific enough to avoid confusion.

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 a necessary permission prerequisite ('Требует права pdns/edit'), which gives some usage context. However, it does not provide guidance on when to use this tool instead of related tools such as add_dns_zone or add_dns_subdomain, nor does it give exclusion conditions. The usage context is only implied by the described 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?

Annotations already mark this as a write operation (readOnlyHint=false), and the description adds useful non-obvious context: the required permission and the conditional SRV/SOA field handling. It does not contradict the annotations, and it does not overstate destructive behavior, consistent with 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?

The description is three short purposeful sentences: operation, permission, and conditional field guidance. It is front-loaded with the core purpose and contains no filler or redundant restatements 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 15-parameter tool, the combination of the description and the 100% schema coverage covers required parameters, permission prerequisites, and the most important conditional fields. The lack of an output schema means return behavior is not described, but the mutation-focused annotations reduce that burden.

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 baseline is 3, but the description goes beyond the schema by grouping SRV parameters and flagging mname/rname as practically required for SOA validation. Not every parameter is elaborated, but the schema already provides solid per-parameter explanations.

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 ('Добавить или изменить DNS-запись в зоне') and identifies the target resource as a DNS record within a zone, clearly distinguishing it from siblings like delete_dns_record, add_dns_domain, or add_dns_subdomain. It also names the internal endpoint pdns/add_dns, making the operation 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 gives practical usage context: it requires pdns/edit rights, explains that SRV records need proto/priority/weight/port/target, and notes that mname/rname may be required for SOA checks. It does not explicitly mention when not to use this tool or point to alternatives, so it stops short of the highest score.

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 indicate a non-read-only, non-destructive operation, and the description does not contradict them. It adds the authorization requirement and the internal endpoint, but it does not disclose side effects, confirmation behavior in prose, or what happens on duplicate names. The added behavioral context is modest but real.

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 sentences with no filler: the action and endpoint come first, and the permission requirement follows. Every word 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 four-required-parameter mutation with 100% schema coverage and annotations, the description plus schema provide everything needed to call the tool correctly. The permission precondition, which is not available in structured fields, is explicitly included. The absence of an output schema is acceptable here because the request-side behavior is fully specified.

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 fully documents all four required parameters. The description adds no parameter-level meaning beyond the schema, and no compensation is needed since the schema carries the 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 operation: adding a subdomain to the subdomain table, and even names the internal endpoint (pdns/add_subdomain). This is distinct from sibling tools such as add_dns_domain, add_dns_record, and edit_dns_subdomain, so an agent can tell what resource is being added.

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 explicit guidance on when to use this tool instead of alternatives like edit_dns_subdomain or delete_dns_subdomain. The permission requirement 'pdns/edit' is useful context, but it does not help an agent choose between sibling DNS tools or describe preconditions beyond authorization.

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?

With readOnlyHint=false and destructiveHint=false, the write semantics are already implied by the annotations; the description adds useful context by stating the authorization requirement (pdns/edit) and the backend endpoint. It does not discuss idempotency or duplicate-zone behavior, but the permission and endpoint details add value 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 two short sentences with no filler. The action and resource are front-loaded, and the permission requirement is stated separately and clearly.

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 schema is rich and fully covers the parameters, making the tool callable. However, the description omits usage differentiation from sibling DNS tools, output/return behavior, and any caveats about existing zones, leaving the agent to infer selection and side effects from 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%, so the schema fully documents parameters, including the confirm=true requirement, defaults, and the nested SOA object. 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 clearly states the action and resource: creating a DNS zone on an authoritative PowerDNS server, and even names the endpoint pdns/add_zone. It does not explicitly distinguish itself from sibling DNS tools like add_dns_domain or add_dns_subdomain, but 'zone' plus 'PowerDNS' provides reasonable 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 when-to-use guidance and names no alternatives. It only mentions the required permission pdns/edit, which is a prerequisite rather than a usage condition. An agent cannot tell when to choose this tool over add_dns_domain or add_dns_subdomain.

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 some behavioral context beyond the annotations: the user is temporary and intended for web access, which is not captured by readOnlyHint or destructiveHint. However, it does not disclose how the user's temporary nature is realized, whether any existing IPMI users are affected, or what the operation returns.

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 with the core purpose front-loaded. The trailing parenthetical '(eq/add_ipmi_user)' is non-informative noise, and there is no structured guidance beyond the one-liner.

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 operation with a confirm flag and no output schema, the description is thin: it does not explain what the response will contain, how credentials are delivered, whether an existing IPMI user is replaced, or any side effects. An agent could invoke it but would be uncertain about the outcome.

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 both 'id' (server ID) and 'confirm' (must be true to execute). The tool description adds no further parameter-level meaning, 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 action ('Создать' = create), resource ('IPMI-пользователя'), and scope ('временного... для веб-доступа' = temporary... for web access), making the tool's core purpose clear. It does not explicitly mention sibling alternatives like remove_ipmi_user, but 'create' and 'temporary' effectively distinguish it from removal 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?

No guidance is given about when to use this tool versus alternatives, what prerequisites exist, or what conditions warrant creating a temporary IPMI user. The agent must infer usage entirely from the action itself.

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, destructiveHint=false, and openWorldHint=true, so the description is not required to restate those. The description adds useful context: the operation requires the special 'add' permission and can either add a new image or update an existing one by name. However, it does not disclose what happens on update (e.g., whether the existing image is replaced or rejected), or any side effects beyond the permission requirement.

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 sentences with no filler. It front-loads the core action (add or update ISO image) and then states the permission requirement. It is concise and structured effectively, though it could have added a brief note about the confirm parameter or update behavior without becoming verbose.

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 three parameters, the description covers the core action and permission requirement but leaves gaps: it does not explain what the 'confirm' parameter does beyond the schema's 'Нужно true, чтобы выполнить операцию', does not clarify when 'url' is needed, and does not describe the response or error behavior. The openWorldHint annotation suggests the API may have side effects, but the description does not elaborate. This is adequate but not 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%, so the schema already documents all three parameters (url, name, confirm). The description adds the meaning of the 'confirm' parameter implicitly by noting the operation requires the 'add' permission, but it does not explain the relationship between 'url' and 'name' (e.g., whether url is required for new images or updates). Baseline 3 is appropriate since 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 states a specific verb and resource: 'Добавить новый ISO-образ или обновить существующий по имени' (add a new ISO image or update an existing one by name), and includes the endpoint 'iso/add'. This clearly distinguishes it from sibling tools like upload_iso, mount_iso, unmount_iso, and delete_iso_image, though it does not explicitly name those alternatives.

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 context by mentioning the required special permission 'add' and the operation's dual add/update behavior, but it does not explicitly state when to use this tool versus alternatives like upload_iso or delete_iso_image. The permission note gives some guidance, but no explicit when/when-not conditions are provided.

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 that the operation is not read-only and has open-world effects, but the description adds important behavioral context: the message is visible to the client and is recorded in the request history/chat. This clarifies the side effect of the operation beyond what the boolean annotations alone convey.

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 action and target without any filler or redundant phrasing. Every word earns its place, and the key behavioral qualifier 'видимое клиенту' appears early.

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 mutation, the presence of annotations, and full schema descriptions, the description is largely complete. It could note what the API returns or that the operation requires a valid existing request ID, but the schema already ties the id to list_rhr_requests and requires confirm=true.

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 all three parameters with 100% coverage, so the baseline is 3. The description adds no additional parameter-level meaning beyond the schema, though it does reinforce that 'message' is the content being added.

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 a specific resource ('видимое клиенту сообщение в историю заявки (rhr/chat)'). This clearly distinguishes the tool from sibling tools like list_rhr_requests, create_rhr_request, and discard_rhr_request, which all operate on the same domain but with different actions.

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 purpose implicitly conveys when to use the tool: when a client-visible message needs to be appended to an RHR request thread. However, it does not explicitly state when not to use it, mention prerequisites, or name alternative sibling tools that might be confused with 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?

Discloses the key behavioral trait annotations do not capture: the operation is asynchronous and status must be checked via check_task. This is consistent with readOnlyHint=false and gives the agent a concrete post-invocation action. No failure modes or extra side effects are mentioned, but the async note carries the main transparency burden.

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 front-loaded sentences: the first gives purpose, the second the async status flow. The only waste is the parenthesized '(nat/add_static_nat)' which repeats the tool's own name; otherwise 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 2-parameter tool with a fully documented schema, it covers what, why, and the post-invocation status flow. But with no output schema, the response shape is unstated (e.g., whether it returns a task ID to feed to check_task), and prerequisites such as IPMI being available on the server are left implicit.

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 is documented as the server ID and confirm as a required true flag — so the baseline of 3 applies. The description adds only contextual color (the IPMI target) rather than new parameter-level 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?

States a specific verb (create) and resource (static DNAT to the IPMI server), plus the concrete outcome: a public IP for IPMI access. The add-vs-remove contrast with siblings like remove_static_nat, clear_static_nat, and drop_nat is easy for an agent to read. The parenthesized API path is mildly tautological but does not muddy 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 intended scenario (exposing IPMI through a public IP) is implied by the purpose statement, but the description never says when to use this tool over its NAT-management siblings or gives any exclusions. An agent must infer that 'add' versus 'remove/clear/drop' is the routing cue.

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, so a write operation is expected. The description adds valuable context beyond that: 'ДЕНЬГИ: списывает средства со счёта' (MONEY: debits funds from the account), which warns the agent that real financial impact occurs. This does not contradict the annotations; it enriches 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?

Two short sentences, front-loaded with the purpose and followed by a financial warning. The structure is efficient, though the second sentence adds some redundancy with 'с кредитного баланса' repeated as 'со счёта', making it slightly less crisp than an ideal one-sentence definition.

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 tool with no output schema, the description covers the essential context: what the tool does, the full/partial scope, and the financial side effect. It does not state prerequisites like needing sufficient credit balance, but this is arguably obvious from 'credit balance' and the schema's 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%, so all three parameters (amount, confirm, invoice_id) are already documented in the schema. The description adds no additional meaning about the parameters themselves, which is acceptable given the schema's completeness; 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 precise action and resource: 'Оплатить инвойс полностью или частично с кредитного баланса' (pay an invoice fully or partially from the credit balance). This clearly distinguishes it from sibling tools like mass_pay, generate_due_invoice, or get_credit_history, and the parenthetical '(whmcs/apply_credit)' reinforces the underlying operation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives clear context: the tool is for paying an invoice from credit, either in full or partially. It does not explicitly mention alternatives or exclusions (e.g., 'use mass_pay for multiple invoices'), so it stops short of a 5, but the 'fully or partially' scope provides enough situational 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?

Annotations already establish the safety profile (readOnlyHint: false, destructiveHint: false), and the description adds useful scope detail by specifying the block happens at the Hostkey network level rather than at the OS level. However, it does not disclose the consequences for traffic to the IP, reversibility via unblock_ip, or the temporary nature of blocking with four_hours, leaving the agent to infer the operational impact.

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 tight sentences with no redundancy: the first states the action and scope, and the second gives the target use case. It is front-loaded and 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 potentially impactful network-blocking operation, the description is adequate but thin: it names the scope and use case, while the schema and annotations cover parameters and safety. Missing are the consequences of a block, how to reverse it (unblock_ip), and that four_hours makes it temporary — though these are partly discoverable via the sibling list and 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 all five parameters already documented (id, ip, description, confirm, four_hours). The tool description itself adds no parameter-level meaning beyond what the schema provides, so it sits at the baseline 3 for high-coverage 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 states a specific verb ('Заблокировать' — block), the resource (IP address on a server), and the scope ('на уровне сети Hostkey' — at the Hostkey network level), and it names the underlying API method (net/block_ip). This clearly distinguishes it from siblings like unblock_ip (the reverse operation) and port_on/port_off (port-level control).

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 use case ('Полезно для abuse-запросов' — useful for abuse requests), which signals to an agent when this tool is the right choice. It offers no explicit exclusions or alternative routing to siblings like unblock_ip or port_off, but the stated scenario provides solid contextual 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?

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?

Annotations already declare destructiveHint=true and readOnlyHint=false. The description adds valuable behavioral context: that failing to run this cleanup can cause an unintended reinstall on reboot, which goes beyond the structured 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?

The description is a single compact sentence that front-loads the action and step context, then adds the critical warning. Every word earns its place, and it is easy to scan.

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 cleanup tool, the description explains the mandatory timing and the risk of omission. There is no output schema, but the purpose, usage timing, and consequence are all covered. It could mention idempotency or what happens if the config does not exist, but this is not essential.

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 parameters id, hostname, and confirm are already fully documented in the schema. The description adds no parameter-level semantics, which is acceptable given the schema carries the 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 names a specific verb ('удалить') and resource ('PXE-конфиг'), and identifies it as Step 7 of a PXE reinstall flow. This clearly distinguishes it from the sibling create_pxe_config and other reinstall-related 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 gives clear usage context: it must be run after the reinstall completes, with the consequence of skipping it explicitly stated (sudden reinstall on next reboot). It does not explicitly mention alternatives or when-not-to-use, but the guidance is sufficient.

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 it's a write operation (readOnlyHint false, destructiveHint false) but do not disclose the specific nature of 'stale' rules or any side effects. The description adds the key contextual notion of 'stale' and the operation type (delete), which is useful. However, it doesn't explain what happens to related resources or whether it's idempotent, but given annotations cover the general safety, a 3 is fair.

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

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

The description is short, ends with a period, and includes the API path, which is efficient. It front-loads the action and scope without any redundant text. 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 tool with only two parameters and no output schema, the description covers the key behavioral context (deleting stale rules) and includes the API path. It could mention the return or error behavior, but given the tool's simplicity and annotations, it is adequately complete. The only missing aspect is an explicit alternative mention, but it doesn't hinder understanding.

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 (ip and confirm) are already documented in the schema. The description does not add extra semantics beyond the schema. The confirm parameter is implied as a confirmation flag, but that is already in 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 states the action (delete), the resource (stale static NAT rules), and the criterion (by internal IP). It also includes the API path, which helps distinguish it from sibling tools like remove_static_nat or drop_nat, though it doesn't explicitly name them. 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?

The description implies it is used for cleaning up stale/frozen NAT rules, but does not explicitly state when to use it versus alternatives like remove_static_nat or drop_nat. It could benefit from specifying the condition or trigger for using this tool, but the main intent is reasonably 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?

Annotations already indicate mutation (readOnlyHint=false) and non-destructive intent (destructiveHint=false). The description adds meaningful context beyond annotations by highlighting 'ДЕНЬГИ: создаёт реальный инвойс' (MONEY: creates a real invoice), signaling actual financial liability and external effects, which aligns with openWorldHint=true.

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 main action is front-loaded, and the critical financial warning is placed prominently as a separate highlighted statement.

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 coverage and no output schema, the description covers the core purpose and a critical behavior (real invoice). It does not describe return values or follow-up steps, but nothing essential for selecting and invoking the tool 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 coverage is 100% and both parameters already have descriptions: amount in account currency and confirm required to execute. The description adds only the generic 'specified amount' phrasing, so it does not materially extend the schema's parameter documentation.

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

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

The description states a specific verb and resource: 'Создать инвойс на пополнение кредитного баланса' (create an invoice for credit balance top-up). The parenthetical 'whmcs/create_addfunds' and the 'real invoice' warning make the operation concrete. It does not explicitly compare with siblings, but the addfunds resource is unique among the listed 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 implies when to use the tool (when a credit balance top-up invoice is needed) and warns that it is a real-money operation. It does not provide explicit when-to-use/when-not-to-use guidance or contrast with related billing tools such as generate_due_invoice or apply_credit.

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 establish this as a non-read-only operation, and the description adds a valuable behavioral warning: the key value is shown only once in the response and must be saved. This goes beyond the schema and 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, front-loaded with the core purpose and followed by the single most important operational warning. No redundant 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 create operation with no output schema, the description covers the essential one-time-display behavior, and the schema documents all required and optional fields. A small gap remains: it does not mention when not to use alternatives, but nothing critical is missing 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?

The input schema provides 100% parameter coverage, including server_id semantics and the login_notify_method constraint. The description adds little beyond the account-or-server distinction, matching 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 clearly states the action ('Создать новый API-ключ') and the resource with scope ('для аккаунта или конкретного сервера'), making it immediately distinguishable from sibling tools like list_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 gives clear context: create a new API key for an account, or for a server when server_id is relevant. It does not explicitly name alternatives or exclusions, but the creation intent is unambiguous and the sibling CRUD tools are obvious by contrast.

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 and readOnlyHint=false, and the description merely repeats 'ДЕСТРУКТИВНО' without adding details about what gets overwritten, whether the server will boot into the installer on next PXE boot, or whether the change is reversible. No meaningful behavioral context is added 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 compact and front-loaded with the core action and workflow step. The parenthetical 'eq/create_pxe' adds minor noise, but the overall structure is efficient and free of 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 destructive, high-stakes operation with 9 parameters and no output schema, the description is too thin. It does not mention preconditions such as needing a reinstall_key from create_reinstall_task, what happens at next boot, how the config can be cleared, or what successful execution returns.

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 parameter descriptions already carry most of the semantic load. The description does not add any parameter-level meaning, interactions, or constraints beyond what the schema provides, which matches the baseline for complete 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: create a PXE config for OS installation, and places it as step 2 of the PXE reinstall flow. This makes the tool's function easily distinguishable from related operations like clearing a PXE config, though it does not explicitly name alternatives.

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 'Step 2 PXE-переустановки' provides an implied workflow context: use this after starting a reinstall flow. However, it does not state when to prefer this over related tools like create_reinstall_task or clear_pxe_config, nor does it list exclusions or preconditions.

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, but the description adds specificity by noting it wipes server disks, and it discloses the return value (reinstall_key). It reinforces and elaborates on the destructive nature without contradicting 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?

Three sentences with no fluff, front-loaded with the step-1 role, and includes the destructive warning prominently. Every sentence carries essential 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 explains the tool's output (reinstall_key) and its role in the reinstall flow, making it complete for a 2-parameter tool. Minor gap: it does not mention prerequisites or when not to use, but given the simplicity, 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?

Schema description coverage is 100%, so parameters id and confirm are fully documented in the schema. The description adds no extra parameter details, which matches the baseline of 3 for 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 tool creates a master key for OS reinstall (eq/reinstall), explicitly naming it as Step 1 of PXE reinstall. It distinguishes itself from siblings by mentioning the return key used by check_task, making its role 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 frames the tool as Step 1 of a process and references check_task for tracking, implying the intended sequence. It does not explicitly name alternatives or exclusions, but the step-1 designation provides clear 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 communicate that this is a non-read-only, non-destructive operation. The description adds no side-effect disclosure such as ticket creation consequences, execution by datacenter staff, or post-submission behavior, but it does not contradict the annotations either.

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: purpose, critical comment guidance, and usage condition. It is front-loaded and contains 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 creation request with four schema-documented parameters, the description supplies the needed purpose, when-to-use condition, and content expectations. It does not describe what happens after the request is created, but that is not essential for invoking it correctly.

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

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

The input schema already describes all parameters with 100% coverage. The description only reinforces that the comment should be detailed, which adds no meaning beyond what schema.description already 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 opens with a specific verb and resource: 'Создать заявку на удалённые работы' and clarifies the exact scope as datacenter duty-shift work that cannot be performed remotely. It is distinguishable from sibling request-management tools like list_rhr_requests, add_rhr_comment, and discard_rhr_request because it explicitly frames this as creating a new request via rhr/add.

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 final sentence gives an explicit condition: 'Использовать, только если модуль удалённого управления сервером недоступен/не работает.' This tells the agent exactly when this tool should be selected over direct remote management 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?

Annotations already indicate readOnlyHint=false and destructiveHint=false, covering the mutation and non-destructive profile. The description adds a key behavioral trait beyond annotations: the operation is asynchronous and requires polling check_task for status. This is valuable context that is not present in the schema or 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, front-loaded sentences: first the core action, then the asynchronous behavior. There is no filler or redundant information, making it highly concise and well-structured.

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

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

The description covers the core purpose and the asynchronous nature, but it does not explain what the response contains (e.g., a task_id needed to call check_task), nor any operational prerequisites beyond the schema's confirm parameter. Since there is no output schema, this gap is significant for an agent to correctly chain the async pattern.

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 (id, name, confirm) is described in the schema. The tool description itself adds no additional meaning for the parameters, such as format constraints or relationships between them, so it stays at the baseline for 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 specific verb and resource: "Создать снапшот виртуальной машины" (create a snapshot of a virtual machine). It also names the exact endpoint (vm/create_snapshot), and the sibling tools (get_snapshots, remove_snapshot, restore_snapshot) are clearly different operations, making it easy for an agent to distinguish.

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 tells the agent the operation is asynchronous and status should be tracked via check_task, which is useful when-to-use guidance for follow-up. However, it does not explicitly contrast with alternatives like restore_snapshot or get_snapshots, nor state conditions for when to use this tool over them. The usage context is implied, 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 explicitly warns that applications using the key will lose access, which is valuable behavioral context beyond the annotations. The annotations already declare destructiveHint=true and readOnlyHint=false, so the description reinforces and adds the real-world consequence. It does not contradict 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 two short sentences with no wasted words. The destructive warning is front-loaded and the tool's purpose is immediately clear. It earns its place by adding critical safety 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 destructive delete operation with a required confirm flag, the description covers the essential context: what is deleted and the consequence. The output schema is absent, but for a delete operation the return value is typically minimal. The description could mention that the operation is irreversible, but the destructive warning already implies this.

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 (id and confirm). The description adds no additional parameter-level detail beyond the schema, but the confirm parameter's purpose is clear from 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 states the action ('Удалить API-ключ') and the resource (API key), and explicitly identifies the operation as destructive. It distinguishes this from sibling tools like get_api_key, list_api_keys, create_api_key, and update_api_key by naming the delete operation and its consequence.

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 this tool: when an API key must be permanently removed. It does not explicitly name alternatives or exclusions, but the destructive warning and the tool name make the usage context clear. A brief mention of when not to use it (e.g., for temporary deactivation) would improve 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 indicate this is a mutating operation (readOnlyHint=false) and not destructive (destructiveHint=false). The description adds the semantic context that this is a withdrawal/reversal action, which is useful. It does not disclose side effects, idempotency, or what happens if the request is already processed, but the annotations cover the basic 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 concise sentence that includes the verb, resource, and API method name. It is front-loaded with the action word and contains no filler. It could arguably omit the API method name, but that is minor.

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 tool with full schema coverage and annotations, the description is mostly adequate. However, it does not explain the relationship to request_cancellation or get_cancellation_requests, nor does it clarify what 'confirm' semantically means beyond the schema's 'must be true' note. An agent would benefit from knowing this is the inverse of request_cancellation.

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. The description adds no additional parameter-level meaning beyond what the schema provides. 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 ('Отозвать' = withdraw/revoke) and a specific resource ('заявку на отмену услуги' = service cancellation request), and it names the underlying API method. This clearly distinguishes it from sibling tools like request_cancellation and get_cancellation_requests, though it does not explicitly name those 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 description implies the tool is for withdrawing a previously submitted cancellation request, which gives some context. However, it does not explicitly state when to use this tool versus alternatives, nor does it mention any prerequisites (e.g., the request must exist and be in a cancellable state).

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=false and destructiveHint=true, so the description's 'ДЕСТРУКТИВНО' mostly repeats structured metadata rather than adding new behavioral context. It does not contradict annotations, and the destructive nature is at least clearly surfaced, but little is added beyond that.

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-loaded with the core action and endpoint. The 'ДЕСТРУКТИВНО' warning is somewhat redundant given the annotation, so it loses one point, but overall it remains appropriately sized.

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 tool with two fully described parameters, strong annotations and no output schema, the description is mostly sufficient. It lacks usage guidance, but the annotations cover the destructive behavior adequately.

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 contact_id and confirm. The tool description adds no parameter-specific meaning, 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 ('Удалить' / delete), a precise resource ('дополнительный контакт аккаунта'), and the endpoint reference. This clearly distinguishes it from sibling 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?

There is no guidance on when to use this tool versus alternatives, no prerequisites, and no mention of cases where deletion is not allowed. The destructive warning is not usage 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 explicitly flags the operation as 'ДЕСТРУКТИВНО' (destructive) and details exactly what is destroyed: DNS zone, the domain, and all subdomains. It also adds the authorization requirement 'pdns/edit' and the backend endpoint, going beyond the destructiveHint annotation. 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 a single, front-loaded sentence that covers action and scope, followed by two short fragments for the destructive warning and permission. 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 three-parameter delete operation with destructive annotations and full schema descriptions, the description provides the necessary behavioral context: what gets deleted, required rights, and the destructive nature. The lack of an output schema is acceptable for a delete tool, and the confirm parameter is documented in the schema. The only minor gap is that it doesn't explicitly mention DNS records, but 'DNS zone' implies them.

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?

All three parameters are already fully described in the input schema (100% coverage), including confirm semantics, domain_id provenance, and server_id. The description only adds a generic 'by ID' phrase and does not provide additional parameter meaning, so it stays at the baseline for 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 states a specific action 'delete domain by ID' and enumerates the full destructive scope: DNS zone, the domain itself, and all subdomains. This clearly distinguishes it from siblings like delete_dns_subdomain or delete_dns_zone. The backend operation (pdns/delete_domain) adds a concrete reference.

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 by specifying what it deletes (the entire domain plus zone and subdomains) and states the required permission 'pdns/edit'. It does not explicitly name alternatives (e.g., delete_dns_subdomain for single subdomains) or state when not to use it, so it is clear context but lacks explicit 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 include destructiveHint=true and readOnlyHint=false, so 'ДЕСТРУКТИВНО' is redundant but consistent. The description adds useful context beyond annotations by requiring pdns/edit permissions and naming the internal endpoint pdns/delete_dns.

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, then adds a destructive warning and the permission requirement. There is no filler or unnecessary repetition beyond the intentional warning.

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, combined with fully described required parameters and destructive annotations, is sufficient to invoke the tool safely. It does not describe postconditions or return values, but no output schema exists and none are strongly implied.

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 fully documented in the schema. The description provides no additional parameter-level meaning, which is acceptable 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?

Description opens with a clear action and resource: 'Удалить DNS-запись из зоны' (delete DNS record from zone). It names a specific verb and the container, distinguishing it from sibling tools like delete_dns_domain, delete_dns_subdomain, and delete_dns_zone.

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 purpose implies when to use the tool, but there is no explicit guidance on when not to use it or how it compares to related tools such as add_dns_record or other delete_* DNS tools. The permission requirement 'Требует права pdns/edit' is a precondition, not a usage-routing guideline.

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 destructive nature is covered. The description adds value by explicitly warning 'ДЕСТРУКТИВНО' (DESTRUCTIVE) and stating the required permission 'Требует права pdns/edit'. It also names the underlying endpoint, which helps an agent understand what system is affected. 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 short and front-loaded: the action is stated first, followed by the destructive warning and permission requirement. Every sentence earns its place. It could be slightly more structured, but it is efficient and readable.

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 operation, the description covers the key context: what is deleted, that it is destructive, and the required permission. However, it does not mention the confirm parameter's role in preventing accidental deletion, nor what happens after deletion (e.g., propagation, irreversibility). With no output schema, a bit more context about the response or side effects 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%, so the schema already documents all three parameters (id, confirm, server_id). The description adds no additional parameter-level meaning beyond what the schema provides. The 'confirm' parameter's purpose is already clear from the schema ('Нужно true, чтобы выполнить операцию'), and the description doesn't elaborate on it. 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 states the action: deleting a subdomain from the subdomains table, and even names the underlying API endpoint (pdns/delete_subdomain). It distinguishes itself from sibling tools like add_dns_subdomain and edit_dns_subdomain by the verb 'Удалить' (delete). It doesn't explicitly contrast with delete_dns_domain or delete_dns_record, but the resource is clear enough.

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 need to delete a DNS subdomain. It does not explicitly state when not to use it or name alternatives (e.g., delete_dns_domain for domains, delete_dns_record for records). The required permission 'pdns/edit' is a useful prerequisite hint, but no explicit routing guidance is given.

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 destructiveHint=true, so 'ДЕСТРУКТИВНО' partly repeats that signal. The description adds value by specifying that all records and metadata are removed and that the 'pdns/edit' permission is required, which go 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?

Two short sentences with no filler: the action and destructive consequence are front-loaded, followed by the permission requirement. The compact technical reference '(pdns/delete_zone)' adds useful backend clarity 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 simple two-parameter delete operation with destructiveHint and full schema coverage, the description covers what is deleted, the required permission, and the destructive nature. No output schema exists, but that is acceptable for this delete operation; nothing essential 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 clear descriptions for zone ('Имя зоны') and confirm ('Нужно true, чтобы выполнить операцию'). The description's 'по имени' aligns with zone but adds no semantic detail 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?

The description begins with a specific verb and resource: 'Удалить DNS-зону' (delete DNS zone), and further specifies the scope: 'вместе со всеми записями и метаданными' (with all records and metadata). This clearly distinguishes it from the sibling record/domain/subdomain deletion 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 provides useful context that this is a destructive zone-level deletion and that it requires 'права pdns/edit'. However, it does not explicitly state when to prefer this over related deletions such as delete_dns_record or delete_dns_domain, so usage context is implied rather than 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?

It reinforces the destructiveHint with 'ДЕСТРУКТИВНО' and adds non-obvious behavior: the tool is staff-only and likely returns a permission error for clients. It also discloses the underlying endpoint 'iso/delete'. No contradiction with the readOnlyHint=false or destructiveHint=true 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 three short clauses: the action, the endpoint, the destructiveness warning, and the access caveat. It is front-loaded with the action and contains 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 low-complexity tool with two required parameters, a fully documented schema, and annotations covering destructiveness, the description covers the key decision factors: what it deletes, how destructive it is, and who may call it. It does not describe return values, but there is no output schema, and the permission caveat addresses the most likely failure mode.

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 baseline is 3. The description adds no parameter-level meaning beyond the schema: it does not elaborate on the id format or the confirm flag beyond what the properties already state.

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 'Удалить ISO-образ по ID', a specific verb ('delete'), resource ('ISO image'), and selection criterion ('ID'). This clearly distinguishes it from sibling tools like add_iso_image, upload_iso, mount_iso, and unmount_iso because the operation is explicitly deletion.

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 concrete usage constraint: the operation is available only to Hostkey employees, and clients will likely receive a permission error. It does not name an alternative tool, but no sibling performs ISO deletion, so the context is sufficient for an agent to decide when to call 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?

The description explicitly warns 'ДЕСТРУКТИВНО: заявка будет отменена' (DESTRUCTIVE: the request will be cancelled), which adds meaningful behavioral context beyond the annotations. The annotations already declare destructiveHint=true and readOnlyHint=false, so the description reinforces and adds the specific consequence: the request will be cancelled. It does not contradict 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 two short sentences with no waste. The action is front-loaded, and the destructive warning is placed immediately after, which is exactly the information an agent needs before invoking a destructive 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 two-parameter destructive tool with full schema coverage and annotations declaring destructiveHint=true, the description is nearly complete. It states the action, the consequence, and the confirm requirement is already in the schema. The only minor gap is that it does not describe what happens after cancellation (e.g., whether it can be undone or what the response looks like), but no output schema exists and the tool is simple enough that this is a minor omission.

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: id is the request ID and confirm must be true to execute. The description adds no additional parameter semantics 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 verb ('Отменить/закрыть' – cancel/close) and a specific resource ('заявку на удалённые работы' – request for remote works), and it names the operation's domain (rhr/discard). It is clear what the tool does, though it does not explicitly distinguish it from sibling tools like create_rhr_request or add_rhr_comment; the resource and action are specific enough that an agent can infer the distinction.

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 a remote-works request needs to be cancelled or closed. It does not explicitly state when not to use it or name alternatives, but the sibling list includes create_rhr_request and add_rhr_comment, so the context is reasonably clear. There is no explicit exclusion or alternative guidance, so it stops at implied usage.

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 carry readOnlyHint=false and destructiveHint=true, and the description reinforces the destructive nature and adds the 'служебная операция' context. It does not add meaningful detail such as permanence of deletion, required permissions, or effects on related resources, but since the annotation layer covers the core safety profile, the description is not severely lacking.

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 explaining the action plus a bare warning. It is front-loaded with the purpose and destruction flag, and contains no filler or redundant explanations.

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?

A destructive deletion tool needs to clarify how to identify the target record. The schema marks both id and ip as optional and only confirm as required, but the description gives no guidance on whether at least one of id/ip must be provided or what happens if omitted. This is a serious gap for correct use, even though the schema itself is documented.

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%: id, ip, and confirm each have descriptive definitions. The description contributes nothing about the parameters, so with full schema documentation 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 has a specific verb ('Удалить' – delete) and resource ('запись о NAT' – NAT record), so an agent can tell it performs a deletion operation. It does not explicitly distinguish it from the sibling tools 'remove_static_nat' or 'clear_static_nat', though the differing resource names make the distinction inferable.

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 the many sibling tools. The phrase 'служебная операция' (service operation) hints at an internal helper but does not describe conditions, prerequisites, or alternatives, so an agent has no basis for deciding when to pick 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?

Beyond the annotations, which already flag readOnly=false and destructiveHint=false, the description adds an explicit permission precondition and names the underlying endpoint pdns/edit_subdomain. This is useful auth context and does not contradict 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?

A single, front-loaded sentence with no filler. The action comes firsteb, and the permission note is the only extra piece of information, so 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?

Together with the schema and annotations, the description is adequate for a simple mutation: the purpose, permission requirement, and required confirm flag are all discoverable. However, it does not explain what an 'update' actually changes or when to use this tool, leaving minor gaps for an agent.

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 baseline is 3. The description itself adds no parameter-level meaning, but the schema already explains id, confirm, and server_id, including the requirement that confirm must be true.

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: 'Обновить сабдомен' ('update subdomain'), which is distinct from sibling tools like add_dns_subdomain and delete_dns_subdomain. It does not specify what fields or aspects of the subdomain can be updated, so it stops short of full detail.

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 when-to-use guidance or comparison with alternatives. The only added context, 'Требует права pdns/edit', is an authorization requirement, not a usage rule; nothing tells the agent to prefer this over add_dns_subdomain or delete_dns_subdomain.

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 this is not read-only, and the description adds little behavioral context beyond 'create an invoice.' It does not disclose the financial side effects, whether the operation is reversible, what happens after confirm=true, or what response to expect. For a billing-affecting action, this is a meaningful gap.

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

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

The description is a single front-loaded sentence with no filler. The parenthetical 'whmcs/generate_due_invoice' is slightly redundant with the tool name but harmless, and the overall length is appropriate for such a small 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 mutating billing operation with no output schema, the description is too thin: it omits usage conditions, side effects, and expected results. The schema covers parameters, but the tool context is not complete enough for an agent to use it confidently.

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 parameters already documented (id and confirm requiring true). The description adds no extra meaning about parameter formats, constraints, or relationships, 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 clear action ('Создать следующий инвойс') and a specific target resource ('для сервера'), so an agent can tell this is an invoice-creation operation. It does not explicitly distinguish itself from sibling create_addfunds_invoice, and 'следующий инвойс' is somewhat vague, 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?

There is no guidance about when to use this tool instead of alternatives such as create_addfunds_invoice or get_server_invoices. No exclusions, prerequisites, or selection conditions are mentioned, so the agent must infer the intended use case.

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?

The tool has zero parameters wrapped by an empty schema, so there is nothing for the description to clarify about parameter meanings. The baseline of 4 for a no-parameter tool applies.