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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the safety profile is known. The description adds that it executes a verified command v-add-cron-job and mentions 'arbitrary shell command', which hints at flexibility and potential risk, but does not elaborate on side effects, permission requirements, or failure modes. It adds some context 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?

The description is two short sentences with no wasted words. The primary purpose is front-loaded, and the second sentence adds a relevant implementation detail. It is efficiently 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?

Given the tool's complexity (10 parameters, 8 required, low schema coverage, and an output schema), the description is far too sparse. It does not explain the schedule fields, the confirm requirement, the restart option, or the meaning of jobId. The agent is left without essential guidance on how to construct a valid call, making the description incomplete for a tool of this 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 only 10% (only the confirm parameter has a description), so the description must compensate for the lack of parameter documentation. However, the description only hints at the command parameter via 'arbitrary shell command' and gives no information about schedule fields (minute, hour, day, month, weekday), user, restart, or jobId. This leaves most parameters poorly explained.

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

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

The description states a clear verb 'Create' with resource 'cron job' and specifies it executes an arbitrary shell command. This distinguishes it from siblings like list_cron_jobs and delete_cron_job, making the tool's purpose unambiguous.

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

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

The description implies the tool is used for creating cron jobs but provides no explicit guidance on when to use it versus alternatives (e.g., listing or deleting cron jobs). There is no mention of prerequisites or exclusions, leaving the agent to infer usage from the name and purpose.

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 cover the general safety profile with readOnlyHint=false, destructiveHint=false, and idempotentHint=false. The description adds that it executes the verified command v-add-database, but does not disclose side-effect details such as failure behavior when the database or user already exists. 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 two short sentences with the main action front-loaded. The second sentence adds a useful implementation detail without repeating schema or annotation content, and there is 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?

The output schema covers return values and annotations cover safety, so those do not need elaboration. However, given the oneOf schema for MySQL vs PostgreSQL, the description does not mention the type distinction or provide any usage context beyond creation. It is adequate but minimal.

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

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

Input schema coverage is 100%, with defaults and constraints already documented for parameters like type, charset, host, and password. The description's 'database and database user' phrasing maps loosely to database and databaseUser but adds no semantic value beyond the schema. Baseline 3 is appropriate.

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

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

Description states a specific action ('Create') and resource ('a database and database user'), making the tool's purpose unambiguous. It also maps the operation to the Hestia command v-add-database. It is clear enough to distinguish from list/get database tools, though it does not explicitly contrast with sibling add_* 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 provided on when to use this tool versus alternatives such as list_databases, get_database, or delete_database. The description implies creation but does not state prerequisites, exclusions, or a selection context.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false, idempotentHint=false, openWorldHint=true. The description adds that it executes a verified command (v-add-dns-domain), which implies a known, tested operation. It doesn't disclose side effects like whether existing records are affected, whether the zone is immediately active, or if restart behavior applies. With annotations covering the safety profile, the description adds modest context but not rich behavioral detail.

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

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

Two sentences, no fluff. The core action is front-loaded. It could add a bit more parameter context without becoming bloated, but as-is it is efficient.

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

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

The tool has 5 parameters, 0% schema description coverage, and an output schema exists. The description is too thin to fully guide an agent: it doesn't explain what 'HestiaCP defaults' means, what the ip parameter is for, how nameservers are used, or what the output schema contains. For a create operation with multiple parameters, more 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 0%, so the description must compensate. It does not explain any parameters: user, domain, ip, restart, nameservers are all undocumented in the description. The schema provides types and constraints, but the description adds no meaning about what these parameters represent or how they relate to DNS zone creation. This is a significant gap.

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

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

The description states a specific verb ('Create') and resource ('DNS zone'), and mentions it uses HestiaCP defaults. It distinguishes from siblings like add_dns_record (which adds a record, not a zone) and list_dns_domains (which lists). However, it doesn't explicitly name a sibling or contrast with alternatives, so it's clear but not fully differentiated.

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: use this to create a DNS zone with HestiaCP defaults. It doesn't state when not to use it or mention alternatives like add_dns_record for adding records within an existing zone. The context is clear enough for a straightforward create operation, but no explicit 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 indicate this is a non-read-only, non-destructive mutation. The description adds little beyond that: it mentions a 'verified command' but does not disclose side effects like DNS propagation, service restarts, duplicate record behavior, or whether existing records are checked. With no idempotency and openWorldHint set, more behavioral context would be valuable.

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

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

The description is short and front-loads the core purpose. The second sentence about the command adds an implementation detail but is not bloated. It earns its place as a compact summary, though it sacrifices semantic richness.

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 nine parameters, five required, and zero schema descriptions, this description is far too thin. It does not explain required parameters, record-type-specific value formats, TTL/priority semantics, or the prerequisite that the user and zone must exist. The output schema covers return values, but input guidance is almost entirely absent.

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

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

Schema description coverage is 0%, so the description must compensate for the nine parameters, but it does not explain record, type, value, ttl, priority, restart, or user/domain prerequisites. An agent gets no guidance on what values are expected for different record types or how optional parameters affect behavior.

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

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

The description clearly states the action ('Add a record') and the target resource ('an existing DNS zone'). The qualifier 'existing' distinguishes it from add_dns_domain, which creates a zone, and from delete_dns_record, so an agent can select the right sibling without opening 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 phrase 'existing DNS zone' implies the tool is only for adding records to zones that already exist, which is a useful condition. However, it does not explicitly name alternatives like add_dns_domain for creating zones or delete_dns_record for removing records, so the when-not guidance is mostly implicit.

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 non-read-only, non-destructive, non-idempotent mutation. The description adds that it executes the verified command 'v-add-mail-account', which is a useful implementation detail, but it does not disclose side effects such as quota enforcement or success/failure behavior. This is moderate added value 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 compact, with the main purpose front-loaded in the first sentence. The second sentence adds a relevant implementation note without bloat. It is appropriately concise, though it could benefit from a bit more detail 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?

Given the tool has five parameters, four required, and only 20% schema coverage, the description is too sparse. It does not mention prerequisites (e.g., the user and domain must exist), behavior on duplicate accounts, or any special constraints. The output schema exists, so return details are not required, but the description still leaves significant gaps for an agent to call it correctly.

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

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

Schema coverage is only 20%, with only 'password' having a description. The tool description does not elaborate on any parameter meanings. Although parameter names like 'account', 'domain', and 'quota' are suggestive, the description does not explicitly clarify their roles or constraints, failing to compensate for the low 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 verb and resource: 'Create a mailbox.' This distinguishes it from sibling tools like add_mail_domain (domain creation) and add_user (user creation). The purpose is unambiguous and not a tautology.

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 versus alternatives, nor any exclusions or prerequisites. It only states what it does, leaving the agent to infer usage from the tool name and siblings. No mention of when to use add_mail_domain instead or any conditions like domain existence.

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 non-read-only mutation. The description adds the implementation detail that it runs the verified command 'v-add-mail-domain', which is modest extra context, but it does not describe side effects such as service restarts or duplicate-handling 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?

Two short sentences with no filler; the core action is front-loaded and the additional command detail is relevant.

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

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

For a tool with eight parameters and significant optional toggles, this definition is under-specified. It does not explain which parameters matter for typical use, any ordering or dependency between user and domain, or why the optional flags exist. The presence of an output schema covers return values, but the rest of the call context is incomplete.

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

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

Schema description coverage is 0% and the description adds no parameter-level meaning beyond names. With eight parameters, six of them enums, the agent has no explanation of what 'dkim', 'antispam', 'rejectSpam', etc. actually control, so the description fails to compensate for the lack of schema descriptions.

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

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

The description uses the specific verb 'Create' with the resource 'mail domain', making the operation clear. It also names the underlying command, but does not explicitly distinguish it from sibling tools like add_mail_account.

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

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

The description gives no guidance on when to use this tool versus alternatives, no prerequisites or exclusions. It merely states what it does, leaving usage context unaddressed.

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 the operation is neither read-only, idempotent, nor destructive, and openWorldHint is true. The description adds the underlying command name and a 'verified' qualifier, but it does not explain side effects, permission requirements, or failure behavior beyond what annotations imply.

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 and front-loads the core purpose. The second sentence about the verified command is slightly redundant but adds implementation clarity without bloating the 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?

Although an output schema exists and annotations provide some safety context, the description leaves the agent without usage conditions and without parameter-level guidance. For a 6-parameter mutation command with very low schema coverage, this is a meaningful completeness gap.

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

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

Schema description coverage is only 17% and the description mentions none of the parameters (user, password, email, package, firstName, lastName). With such low coverage, the description was expected to compensate, but it adds no semantic guidance for any 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 states a specific action ('Create a HestiaCP user') and identifies the exact backend command ('v-add-user'), making the tool's purpose unmistakable. This clearly differentiates it from sibling tools like list_users or delete_user.

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 alternatives or any prerequisites/exclusions. The description only states what it does, not the conditions under which the agent should invoke 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 annotations already establish that this is a non-read-only, non-idempotent, non-destructive operation, so the description does not need to restate those. It adds only the fact that the tool 'executes verified command v-add-web-domain,' which is useful context but does not disclose side effects, authorization needs, or result 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 short and front-loaded with the core action before the implementation detail. The command reference 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 state-changing tool with six parameters and 0% schema description coverage, the description is too thin for fully correct invocation. It omits parameter semantics, defaults behavior, and any cautions, though an output schema exists to cover return values.

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

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

Schema description coverage is 0%, and the description does not compensate by explaining any of the six parameters. Field names like 'domain' and 'user' are self-explanatory, but 'aliases,' 'proxyExtensions,' 'ip,' and 'restart' remain semantically underdocumented beyond type/default values.

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

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

The description uses a specific verb and resource ('Create a web domain') and names the underlying command, making the tool's role unambiguous. It is clearly distinct from sibling add_* tools like add_dns_domain, add_mail_domain, and add_database because the resource type is explicitly web.

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

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

The description gives no guidance on when to use this tool versus alternatives and no exclusions or prerequisites. It relies entirely on the sibling names to imply that this is the web-domain creation operation.

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 the operation is not read-only whether it is idempotent, and that it is not destructive. The description adds that it executes the verified command 'v-backup-user', which gives some implementation context, but it does not disclose potential side effects, duration, or async 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 two short sentences with no fluff or repetition. The core action is front-loaded, and the implementation detail is brief and relevant.

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 action, the core intent is clear)Skip but the description leaves gaps around when to use it, what the 'notify' parameter actually controls, and what consequence 'starting' a backup has. The output schema likely covers return values, but the explanation of preconditions and side effects is thin.

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

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

Schema description coverage is 0%, so the description should compensate for undocumented parameters. It does not explain the purpose of 'user' or the semantics of the 'notify' option. The schema provides type and constraints, but the description adds no 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?

The description states a specific verb ('Start') and resource ('complete user backup'), making the tool's function immediately clear. It is naturally distinguished from the sibling list_user_backups, since one creates a backup and the other lists them.

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 appropriate use case – initiating a user backup – but provides no explicit when/when-not guidance or mention of alternatives. An agent can infer the purpose, but the description does not actively aid in choosing between this and 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 indicate destructiveHint=true, readOnlyHint=false, and idempotentHint=false, so the description does not need to restate those. It adds only the underlying command name, with no detail about side effects, irreversibility, failure modes, or authorization requirements.

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. The second sentence adds a small implementation detail. No filler, though the brevity contributes to under-specification in other dimensions.

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 tool with three required parameters, the description lacks usage context, parameter provenance, and behavioral consequences. The annotations and output schema carry some weight, but the description alone is not sufficient to guide correct invocation beyond the obvious.

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 only 33% since only confirm is described. The description does not clarify user, jobId, or where jobId comes from. With low schema coverage, the description should compensate, but it adds no 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?

The description clearly states the action and resource: 'Delete a cron job.' The verb is specific and unambiguous, and the underlying command is named. However, it does not explicitly differentiate this from other delete/list sibling tools, so it misses the top score.

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

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

No guidance is provided about when to use this tool versus alternatives, when not to use it, or prerequisites such as looking up job IDs via list_cron_jobs. The intended use is only implied by the word 'delete.'

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the description adds little beyond that. 'Executes verified command v-delete-database' hints at implementation but does not disclose irreversibility, cascading effects, or what happens to associated data. The description carries minimal behavioral context beyond what annotations already provide.

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 operation. However, the second sentence, 'Executes verified command v-delete-database,' adds limited agent-relevant value and uses the ambiguous word 'verified' rather than explaining behavior.

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 tool with three required parameters, the description is too thin. It does not explain the destructive consequences, mention confirm, clarify ownership, or provide any workflow context such as checking with list_databases/get_database first. The annotations and output schema help, but the agent still lacks operational context for safe invocation.

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

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

Schema description coverage is only 33%, with user and database lacking descriptions. The tool description does not compensate by explaining what 'user' or 'database' refer to or how they should be formatted. Only the confirm parameter is semantically described in the schema, leaving the other two parameters under-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 and resource: 'Delete a database.' This clearly distinguishes it from sibling list/get tools and from delete operations on other resource types. Mentioning the underlying command v-delete-database reinforces the operation without obscuring it.

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, nor are there exclusions or prerequisites. There is no mention of listing/checking the database first, verifying ownership, or when deletion may be inappropriate. The intended use is only implied by the verb 'Delete'.

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 destructiveHint=true, and the description adds meaningful behavioral nuance by warning that all records in the zone are deleted, not just the zone object itself. It also names the underlying verified command v-delete-dns-domain, adding execution context 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 concise and front-loaded with the core purpose. The second sentence about the verified command is useful but somewhat redundant with the tool name, so it is not maximally economical.

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 tool, the description plus annotations and schema convey the core operation, required confirmation, and destructive scope. However, it lacks guidance on when to choose this instead of delete_dns_record and does not clarify domain format or user ownership, so it is minimally 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 only 33%, and the description partially compensates by clarifying that 'domain' refers to a DNS zone whose records are removed. However, it does not explain the 'user' parameter or the expected domain format, leaving a meaningful gap for two of three parameters.

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

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

The description states a specific verb and resource: 'Delete a DNS zone and all records.' This clearly differentiates it from the sibling delete_dns_record, which operates on a single record rather than the entire 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?

There is no explicit guidance on when to use this tool versus alternatives such as delete_dns_record. The description only implies zone-level deletion; it never states conditions, exclusions, or which sibling to use for record-only deletions.

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

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

Annotations already convey destructiveHint=true and readOnly=false, so the destructive nature is known. The description adds only the implementation detail that it executes 'verified command v-delete-dns-record,' without explaining side effects, irreversibility, or any confirmation requirements beyond the schema.

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

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

The description is short and front-loaded with the core purpose. The second sentence adds a minor implementation detail but does not bloat the description. It is appropriately concise, though the second sentence contributes little selection value.

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

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

For a simple delete operation, the description combined with annotations and schema is minimally adequate. However, it lacks explicit guidance about the meaning of 'id' and the 'restart' parameter, and it does not warn about the destructive consequence beyond the annotation and confirm field. It is sufficient but not comprehensive.

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 only 20%, and the description provides no parameter guidance. The role of 'id' as the record identifier, the meaning of 'restart', and why 'confirm' must be true are not addressed in the description. Only the schema documents 'confirm,' leaving 'restart' and other parameters under-explained.

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 object: 'Delete a DNS record.' This distinguishes it from sibling tools like delete_dns_domain or add_dns_record. Mentioning the underlying command reinforces the specific operation without ambiguity.

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

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

The description implies this tool is for deleting an individual DNS record, but it does not explicitly state when to use it versus alternatives such as delete_dns_domain for deleting a whole domain. No exclusions or alternative tool routing 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 declare destructiveHint=true and readOnlyHint=false, so the destructive nature is covered. The description adds that it deletes 'a mailbox and its messages' and that it executes a 'verified command', which gives some context about scope. However, it does not disclose whether deletion is permanent, whether it affects related data, or any confirmation requirements beyond the schema's confirm field.

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. The second sentence about the verified command adds a small amount of context without bloat. It earns its place, though it could be slightly more informative 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 destructive tool with 4 required parameters and no output schema details, the description is thin. It does not explain the role of each parameter, the permanence of deletion, or any safety checks beyond the confirm flag. The annotations cover the destructive hint, but the description leaves too much for the agent to infer about how to invoke it correctly.

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

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

Schema description coverage is only 25%, with only the 'confirm' parameter described. The description does not explain the meaning of 'user', 'domain', or 'account' beyond their names. For a destructive operation, the agent needs to know that 'account' is the mailbox local part and 'domain' is the mail domain, but this is left to inference.

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

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

The description states a clear verb and resource: 'Delete a mailbox and its messages.' It also mentions the underlying command 'v-delete-mail-account', which adds specificity. It does not explicitly distinguish from sibling delete tools, but the resource (mailbox) 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 guidance is provided about when to use this tool versus alternatives, nor any prerequisites or conditions. The description only states what it does, not when it should be invoked. The sibling list includes delete_mail_domain and delete_user, but no exclusions or 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?

The annotations already indicate destructiveHint=true, and the description reinforces this by stating 'and all mailboxes', which explains the scope of destruction. It adds the detail that this is a verified command, hinting at safety validation, but it does not go beyond the annotations to describe any other behavioral traits, such as lack of idempotency or open-world assumptions. Since the description does not contradict annotations, a 3 is appropriate.

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 critical destructive consequence (deleting all mailboxes). It is to the point and easy to parse, though adding a brief note on when to use it could have increased value without much bulk.

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 conveys the key effect (delete domain and mailboxes) and mentions the underlying command, which is sufficient for a straightforward deletion tool. Given the presence of an output schema, return values are presumably documented elsewhere. However, it lacks guidance on required user context or the irreversibility of the operation, though annotations cover the destructive hint. Overall, it is adequate but not thorough.

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

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

With only 33% schema description coverage, the confirm parameter is described as a confirmation flag, which is useful. However, the description adds no meaning for the 'user' and 'domain' parameters beyond their names, which are self-explanatory. The schema provides basic constraints (patterns, lengths), but the description does not clarify which user or domain space they refer to. Given the low schema coverage, the description should compensate more but falls short.

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

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

The description clearly states the action ('Delete') and the resource ('a mail domain and all mailboxes'). It also mentions the specific command executed (v-delete-mail-domain), which adds technical clarity. However, it does not explicitly distinguish this tool from the related delete_mail_account, since both involve mail-related deletion, though the focus on domain is clear.

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

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

The description does not provide explicit guidance on when to use this tool versus alternatives, such as delete_mail_account or other delete tools. The purpose is obvious (delete mail domain), but there is no mention of prerequisites, side effects, or when not to use it, relying on the agent to infer from the name and 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?

Annotations already declare destructiveHint=true and readOnlyHint=false, so the destructive nature is covered. The description adds valuable context: 'all owned data' is deleted and it executes a verified command 'v-delete-user', which signals a specific underlying operation. It doesn't mention irreversibility explicitly, but 'delete' plus 'all owned data' plus the destructive annotation makes that clear enough.

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

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

Two short sentences with no filler. The core action and the key consequence ('all owned data') are front-loaded, and the command reference is a useful addition. Every word earns its place.

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

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

For a destructive tool with annotations covering the safety profile, the description is mostly adequate. However, it doesn't explain the 'restart' parameter or what happens after deletion (e.g., whether the user's data is permanently removed or recoverable). The output schema exists, so return values are covered, but the missing parameter semantics for 'restart' leave a gap.

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

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

Schema description coverage is only 33%, so the description should compensate for the undocumented parameters. The description mentions 'user' and 'all owned data' but doesn't explain the 'confirm' or 'restart' parameters. The schema itself documents 'confirm' as explicit confirmation for a destructive operation, but 'restart' has no description. The description adds minimal value beyond the schema for parameter semantics.

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

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

The description states a specific verb and resource ('Delete a user and all owned data') and adds the command it executes ('v-delete-user'). It is clear what the tool does, though it doesn't explicitly distinguish it from other delete_* siblings beyond the resource being a user.

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

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

The description implies this is the tool for deleting a user and all owned data, but it doesn't provide explicit when-to-use guidance or mention alternatives. The sibling list includes many delete_* tools, but the description doesn't say when to choose delete_user over them, which is fairly obvious from the resource name but not explicitly 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 destructiveHint=true, so the description only needs to add context beyond that. It usefully discloses that files are deleted along with the domain and mentions the exact command executed. 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 two short sentences with the core action front-loaded. The second sentence about the verified command is somewhat tangential but not enough to significantly reduce clarity.

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

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

The destructive nature and target are clear, and the output schema covers return values. However, the description omits guidance about the 'restart' parameter, side effects, and when to prefer sibling tools, leaving meaningful gaps for a destructive operation.

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 only 25%, so the description carries a heavier burden for explaining parameters. It provides no insight into the 'restart' parameter and does not clarify how 'user' or 'domain' relate to the deletion beyond what their names imply.

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

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

The description uses a specific verb ('Delete') with a clear resource ('a web domain') and adds scope ('and its files'), making the tool's purpose unmistakable. It is easily distinguished from sibling delete_* tools by the 'web domain' resource.

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 versus alternatives, such as suspend_user or delete_dns_domain. The description does not state prerequisites, confirmations, or consequences beyond the initial deletion, leaving the agent to infer appropriate 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 declare readOnlyHint, idempotentHint, and non-destructive behavior, so the safety profile is covered. The description adds the exact underlying command 'v-list-database', which is useful operational context, but it does not disclose output shape, pagination, or error 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 very short and front-loaded with the core purpose. The phrase 'verified command' adds slight noise, but overall the description is efficient and easy to parse.

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

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

This is a simple read-only getter with an output schema and annotations covering safety and idempotence. The description is functionally sufficient for selection, though richer parameter guidance would make it fully self-contained.

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

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

Schema description coverage is 0%, and the description provides no explanation of the user, database, or format parameters. The parameter names are fairly self-explanatory, but the description does not compensate for the lack of schema-level parameter documentation.

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

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

The description clearly identifies the operation: 'Get one database' with a specific resource and singular scope. This distinguishes it from list_databases and other database-related tools, even without explicitly naming them.

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 singular 'one database' implies this tool is for retrieving a single database rather than listing all databases, but it never names alternatives or states when not to use it. Usage guidance remains implicit rather than explicit.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds a minor implementation detail about executing a verified command, but it does not disclose auth requirements, return behavior, or potential side effects beyond what annotations provide.

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 with the tool's purpose. The second sentence about the verified command is somewhat supplementary but not wasteful. It is compact and readable, though the implementation detail could arguably be omitted.

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

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

The tool is simple and has a rich output schema plus comprehensive annotations, but the description lacks explicit routing guidance and parameter context. For an agent unfamiliar with the command, the description alone is sufficient only at a basic level; it does not cover when to prefer list_dns_domains or what format choices imply.

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

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

Schema description coverage is 0%, so the description should compensate for parameter meaning. It only mentions 'DNS zone' and does not explain the user, domain, or format parameters beyond what their names and schema defaults suggest. This leaves the agent to infer how parameters map to the underlying command.

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: 'Get one DNS zone.' This clearly distinguishes the tool from list_dns_domains (all zones) and mutation tools like add_dns_domain or delete_dns_domain. The phrase 'one DNS zone' is precise and actionable.

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 use for retrieving a single DNS zone, and the name aligns with sibling get_* tools, but it does not explicitly state when to use this tool versus list_dns_domains or other alternatives. Usage context is inferred from wording 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, idempotentHint, and destructiveHint=false; the description adds the underlying command v-list-mail-domain, which helps an agent understand this is a wrapper around a verified listing command. It does not describe errors or behavior on missing domains, but the annotation coverage keeps this 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?

Two short sentences with the main purpose front-loaded. There is no filler or redundant wording, and the command detail is compact and relevant.

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 singular getter, the description plus schema and annotations are mostly sufficient: user and domain are required by the schema, format has an enum with a default, and annotations cover the safety profile. The main gap is that the description does not explicitly tie the parameters to the operation, but the field names and output schema largely cover 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?

The input schema has 0% description coverage, and the description does not explain the roles of user, domain, or format. The parameter names and the format enum are somewhat self-explanatory, but the description adds no parameter-level meaning and therefore fails to compensate for the low 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 concrete action ('Get') applied to a specific resource ('one mail domain'), and the singular wording distinguishes it from sibling list_mail_domains. The implementation detail v-list-mail-domain reinforces that this is 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?

The singular 'one' implies this is for retrieving a specific domain rather than listing all, but the description does not explicitly point to list_mail_domains or state when not to use it. No prerequisites or alternative selection criteria are given, so usage guidance is only implicit.

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, openWorldHint=true, idempotentHint=true, and destructiveHint=false, covering safety and side-effect properties. The description adds beyond that by specifying the output is 'allowlisted, non-sensitive' (filtering behavior) and mentions the underlying command 'v-list-sys-config', offering implementation detail that helps set expectations. 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, well-structured sentence that front-loads the primary action and result. It omits any filler or redundancy, and every clause adds value: the resource, the safety qualifiers, and the reference to the verified command. This is appropriately concise for a simple no-parameter 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?

The description is sufficient for a zero-parameter tool with an output schema present, but it lacks differentiation from the closely related sibling get_system_info. The agent may be uncertain which tool to call without additional context on what constitutes 'configuration' versus 'info'. The description also does not mention any potential latency or permission constraints, though the output schema presumably covers return shape.

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 schema description coverage is 100% (vacuously, as there are no properties to describe). The description adds no parameter-related information, but the baseline for zero-parameter tools is 4 because there is nothing to clarify. The description effectively communicates the nature of the result rather than parameters.

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

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

The description states a clear verb ('Get') and resource ('HestiaCP system configuration summary'), with scope qualifiers ('allowlisted, non-sensitive'). However, it does not explicitly differentiate from the sibling tool get_system_info, though the resource wording is distinct enough to infer a different output. The purpose is clear without being a tautology.

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 usage guidance is provided. The description does not indicate when to choose this tool over alternatives like get_system_info, nor when it is not appropriate. The only contextual hint is 'allowlisted, non-sensitive', which implies a filtered view, but there is no explicit comparison or 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, idempotentHint, openWorldHint, and destructiveHint=false, covering the safety profile. The description adds that it 'Executes verified command v-list-sys-info', providing a small implementation detail, but does not disclose any additional behavioral traits such as output size, latency, or permissions.

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 with no redundant words. The main purpose is front-loaded, and the implementation detail is kept brief, making it easy to parse quickly.

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 a rich annotation set, the description is mostly adequate. However, it lacks any usage context or differentiation from sibling tools, and 'system information' remains vague without enumerating what data is returned.

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

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

Schema description coverage is 0% and the description does not mention the 'format' parameter at all. The schema itself defines the enum (json, plain) and default (json), so the parameter is understandable, but the description fails to add any meaning beyond that structured 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 clearly states the tool's purpose: 'Get HestiaCP system information' and identifies the underlying command 'v-list-sys-info'. It distinguishes itself from similar siblings like get_system_config and list_system_services by focusing on general system information, though it doesn't explicitly name any 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?

No guidance is given about when to use this tool versus alternatives. The description does not mention conditions, exclusions, or related tools such as get_system_config or list_system_services, leaving the agent to infer appropriate usage from the name alone.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds the useful fact that it executes the verified v-list-user command, but it provides no further behavioral context such as authentication needs or error behavior. No contradiction exists.

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 carry the full description with no filler. The main action is front-loaded, and the command detail is a useful second sentence.

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 single-user lookup, the description, annotations, and output schema together cover what an agent needs to invoke the tool. The main missing piece is explicit guidance on when to use it versus list_users, but the operation itself is clear and well-supported.

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

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

Schema description coverage is 0%, and the description does not explain either parameter. The required `user` parameter is inferable from the sentence 'Get one HestiaCP user,' but `format` is left entirely to the schema's enum/default, which is minimally self-explanatory. This does not adequately compensate for the lack of parameter descriptions.

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: 'Get one HestiaCP user.' It also names the underlying command, v-list-user, and the word 'one' distinguishes it from the sibling list_users. This makes the tool's purpose unambiguous.

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

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

The description implies a single-user lookup rather than listing all users, but it does not explicitly name alternatives or state when to prefer this over list_users. There is no when-not guidance, leaving selection partially 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, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds 'Executes verified command v-list-web-domain,' which provides a minor implementation detail but does not disclose additional behavior such as error handling, response format, or side effects. It adds only marginal 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 concise and front-loaded with the purpose statement. However, the second sentence about the verified command is redundant and adds little value. Overall it is efficient but could be more informative without sacrificing brevity.

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 is minimal and does not provide context on what the tool returns, how to use it, or any limitations. Given the tool's simplicity, it might suffice, but it lacks any guidance on parameter usage or output format, making it incomplete for an agent to confidently invoke it.

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

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

The input schema has 0% description coverage, and the description does not explain the meaning, format, or purpose of any parameter (user, domain, format). It fails to compensate for the lack of schema descriptions, leaving agents without guidance on how to properly fill in the fields.

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 purpose: 'Get one web domain.' It uses a specific verb and resource, and the word 'one' implicitly distinguishes it from list_web_domains. However, it does not explicitly name the sibling or state the difference, so it is clear but not fully differentiated.

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

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

The description provides no guidance on when to use this tool versus alternatives. It does not mention that listing all domains would require list_web_domains, nor any conditions or prerequisites. An agent receives no help in choosing between this and 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 establish this as a mutation (readOnlyHint=false), non-idempotent, and open-world. The description adds the notion of 'renew' vs 'issue' but does not disclose prerequisites like domain verification, DNS checks, or potential side effects on existing certificates. With annotations covering the safety profile, the description provides marginal added value, so a 3 is appropriate.

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

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

Two sentences, front-loaded with purpose. The second sentence about the verified command adds a minor implementation detail that is not essential for selection but does not waste words. It is concise and structured logically, though the command reference is slightly tangential.

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

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

For a tool with 4 parameters (2 required) and an output schema, the description omits all parameter semantics, prerequisites, and behavioral nuances beyond the basic action. Even though the output schema exists, the description still fails to provide enough guidance for an agent to correctly invoke the tool, especially regarding the optional parameters and renewal behavior.

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

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

Schema description coverage is 0%, and the description does not mention any of the four parameters (user, domain, aliases, includeMail). The phrase 'for a web domain' weakly implies the domain parameter, but it offers no explanation for aliases or includeMail, and no constraints on the user parameter. The description completely fails to compensate for the missing schema documentation.

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

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

The description clearly states the action ('Issue or renew a Let's Encrypt certificate') and the target resource ('a web domain'). It distinguishes itself from siblings because no other tool in the list deals with certificates. The mention of the underlying command adds specificity without ambiguity.

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

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

The description gives clear context: use this to obtain or refresh a Let's Encrypt cert for a domain. It does not explicitly exclude any scenarios or name alternatives, but since no sibling tool serves the same purpose, the usage intent is unambiguous. No prerequisites or when-not-to-use guidance is given, so it falls short of a 5.

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 destructiveHint=false, so the safety profile is clear. The description adds the fact that it executes a 'verified command' (v-list-cron-jobs), which is useful but not essential. It does not describe output format or pagination, but with annotations covering the core behavior, this 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 two sentences, concise and front-loaded with the main purpose. It wastes no words and is appropriately sized for a simple list operation. However, it could be more informative without becoming verbose, e.g., by adding a note on parameters.

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

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

Given the presence of an output schema, the description doesn't need to explain return values. However, the 0% parameter coverage means the description should explain what 'user' and 'format' do; it does not. The tool is simple, but the missing parameter semantics make it incomplete for an agent to call correctly without additional guessing.

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

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

Schema description coverage is 0%, so the description must compensate for parameter explanation. However, the description does not mention 'user' or 'format' at all. The agent only has the schema's patterns and enum to infer meaning. This is a severe gap, as the description provides no semantic context for either 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 states a specific verb ('List') and resource ('a user's cron jobs'), which clearly differentiates it from siblings like add_cron_job or delete_cron_job. It also mentions the underlying command, reinforcing the exact scope. This is unambiguous and distinguishes it from other list tools (list_web_domains, list_mail_domains, etc.).

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

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

The description does not explicitly state when to use this tool versus alternatives (e.g., add_cron_job, delete_cron_job). However, the name and verb imply its purpose for retrieval. There is no explicit exclusions or alternative routing, so it relies on the agent to infer usage context from the sibling set.

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, openWorldHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds only 'Executes verified command v-list-databases,' which is an implementation detail and does not disclose behavioral traits like response shape, error handling, or side effects. It fails to add meaningful context 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 short (two sentences) and front-loads the main purpose. However, the second sentence ('Executes verified command v-list-databases') adds little value for the agent and could be omitted. It's not verbose, but the excess sentence prevents a higher score for 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 simple list tool, the description is incomplete. It does not explain the 'format' parameter, mention any pagination or limits, or clarify whether the output is a list of database names or detailed objects (though an output schema exists). The agent is left without guidance on how to use the tool effectively or when to prefer it over related tools like get_database.

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

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

Schema description coverage is 0%, so the description must compensate. It only implies the 'user' parameter via 'a user's databases' but says nothing about 'format' or its enum values (json/plain). The agent gets no explanation of output format choices or parameter usage beyond what the schema's raw structure provides, leaving significant gaps.

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

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

The description clearly states a specific verb and resource: 'List a user's databases.' This distinguishes it from other tools like get_database (which retrieves a single database) and list_web_domains (a different resource type). However, it does not explicitly contrast with sibling list tools, so it's not a 5.

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

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

The description gives no guidance on when to use this tool versus alternatives. It doesn't mention that get_database should be used for a single database, or that format options affect output. There are no exclusions or context clues to help an agent choose this over sibling 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, idempotentHint=true, and destructiveHint=false, covering safety. The description adds that it executes a verified command, but does not describe return format or pagination. With annotations carrying 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?

One sentence with no fluff, front-loading the action. It is appropriately concise for a simple list operation, though it could include parameter hints without much 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?

The tool is simple, annotations are strong, and an output schema exists. However, the description doesn't explain the 'user' parameter or 'format' option, leaving some gaps. Adequate for a minimal definition but could do better.

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

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

The schema has 0% description coverage, and the description does not mention parameters at all. It fails to explain the required 'user' parameter or the 'format' enum, leaving the agent without any guidance beyond the schema's structural constraints.

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 and resource ('List a user's DNS zones'), which clearly distinguishes it from sibling tools like list_web_domains and list_mail_domains. The mention of the underlying command ('v-list-dns-domains') adds specificity.

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?

Provides clear context by specifying the scope (a user's DNS zones). However, it does not explicitly mention alternatives or exclusions, such as when to use list_dns_records or get_dns_domain instead.

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 the operation read-only, idempotent, and non-destructive, so the description does not need to restate those. It adds only the implementation note about 'verified command v-list-dns-records', which provides no additional side-effect, permission, or pagination 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 the core statement first. The second sentence is extra implementation detail but does not harm; a 5 would require every sentence to add necessary 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 read-only listing tool with rich annotations and an output schema, the description is minimally sufficient. However, it lacks parameter semantics and routing guidance to sibling tools, so it is not fully 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 0%, and the description says nothing about 'user', 'domain', or 'format'. An agent gets no help understanding that 'user' is the account owning the zone or that 'domain' is the zone name.

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

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

Description states a clear action ('List') and resource ('records in a DNS zone'), distinguishing it at a glance from sibling tools like list_dns_domains and get_dns_domain. It does not explicitly name a sibling or exclusion, so it falls short of a top score.

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

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

No guidance on when to use this instead of list_dns_domains or get_dns_domain, and no prerequisites or exclusions are mentioned. The only implied context is the general statement that it lists records in a DNS zone.

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, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered. The description adds one useful behavioral detail: it 'Executes verified command v-list-mail-accounts,' which tells the agent this is a direct command wrapper. However, it doesn't disclose return format details or pagination behavior, though the output schema likely covers return structure.

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 zero waste. The core purpose is front-loaded in the first sentence, and the second sentence adds a useful implementation detail. Every word earns its place.

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

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

For a read-only list tool with rich annotations (readOnly, idempotent, non-destructive) and an output schema, the description is nearly complete. The only gap is that it doesn't explain the 'user' parameter's role (which user's mail accounts to list) or mention the format parameter, but the schema and output schema cover most of what an agent needs.

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

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

Schema description coverage is 0%, so the description carries the burden for parameter meaning. The description mentions 'in a mail domain' which implies the domain parameter's role, but it doesn't explain the 'user' parameter or the 'format' parameter beyond what the schema already provides (enum json/plain with default json). The description adds minimal semantic value over 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: 'List accounts in a mail domain.' This clearly distinguishes it from sibling tools like list_mail_domains (which lists domains, not accounts) and add_mail_account (which creates accounts). However, it doesn't explicitly name a sibling alternative, so it doesn't fully earn a 5.

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

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

The description implies usage context by specifying 'in a mail domain' and requiring user/domain parameters, which tells the agent this is for listing accounts within a specific domain. However, it provides no explicit guidance on when to choose this over alternatives like list_mail_domains or get_mail_domain, and no exclusions or prerequisites are 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, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered. The description adds the detail that it 'Executes verified command v-list-mail-domains,' which provides a small amount of implementation context. However, it does not disclose return format details, pagination, or any other behavioral traits beyond what annotations already 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?

The description is two short sentences with no wasted words. The core purpose is front-loaded in the first sentence, and the second sentence adds a small implementation detail. It is appropriately sized for a simple list operation.

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 list tool with rich annotations (readOnly, idempotent, non-destructive) and an output schema, the description is mostly complete. It identifies the user scope and the operation. It could be improved by noting the 'format' parameter or explicitly distinguishing from sibling list tools, but nothing critical is missing for an agent to invoke it correctly.

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

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

Schema description coverage is 0%, so the description carries the burden for parameter meaning. The description mentions 'a user's mail domains,' which maps to the required 'user' parameter, but it does not explain the 'format' parameter or its default behavior. The schema itself documents 'format' with an enum and default, so the description adds minimal value 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: 'List a user's mail domains.' It clearly identifies the operation and the target resource. However, it does not explicitly differentiate from sibling tools like list_web_domains or list_dns_domains, though the resource name 'mail domains' makes the distinction fairly obvious.

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: it lists mail domains for a user, and the required 'user' parameter indicates the scope. It does not explicitly state when to use this tool versus alternatives like list_mail_accounts or get_mail_domain, nor does it mention any exclusions or prerequisites. The context is clear enough for basic selection but lacks explicit routing 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 declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered. The description adds the detail that it executes a verified command 'v-list-sys-ips', which gives some implementation transparency. However, it doesn't disclose behavior like whether it returns all IPs or only active ones, or any formatting nuances beyond the format parameter. The description adds modest value beyond annotations but doesn't fully describe behavioral traits.

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

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

The description is two short sentences, front-loading the core purpose and then adding the implementation detail. Every word earns its place, and there's no fluff. It could arguably be slightly more informative about output or usage, but for a simple list tool, it's appropriately concise.

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

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

Given the tool's simplicity (1 optional parameter, no nested objects, output schema present), the description is nearly complete. The output schema exists, so return values are documented elsewhere. The only missing context is explicit guidance on when to use this vs. alternatives, but the unique resource name and read-only nature make it easy for an agent to select correctly. The description plus annotations cover the essential context for a safe, correct 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 0%, so the description carries the burden for parameter semantics. The description mentions 'List configured server IP addresses' but doesn't explain the 'format' parameter's effect on output. The schema itself provides an enum with 'json' and 'plain' and a default of 'json', which is self-explanatory for an agent. Since the parameter is simple and well-defined by the enum, the description's lack of parameter detail is a minor gap, but it doesn't add 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 ('List') and resource ('configured server IP addresses'), which clearly distinguishes it from sibling tools like list_users or list_web_domains. It also mentions the underlying command 'v-list-sys-ips', adding specificity. However, it doesn't explicitly differentiate from any sibling that might also list system-level resources, though the resource name is sufficiently unique.

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

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

The description implies usage for retrieving server IP addresses, and the readOnlyHint annotation reinforces that it's a safe read operation. However, it provides no explicit guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites. The context is clear enough for a simple list operation, but there's no explicit routing or condition-based 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 declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds a small behavioral detail by stating it 'executes verified command v-list-sys-services,' but it does not disclose output structure, pagination, or potential limitations beyond what annotations and output schema provide.

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 brief and front-loaded: the first sentence states the core purpose, and the second adds a useful implementation detail about the verified command. No words are wasted, though it lacks a more structured presentation.

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

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

The tool is simple, has one optional self-documenting parameter, and includes an output schema, so return values do not need to be explained in the description. The main gap is the lack of explicit usage guidance or alternative routing, but overall the description is sufficient for correct selection and invocation.

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

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

Schema description coverage is 0%, and the description does not mention the 'format' parameter at all. The schema itself documents the enum values 'json' and 'plain' with a default, so the agent can still infer parameter meaning, but the description fails to compensate for the lack of schema descriptions.

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 system services and status.' It is unambiguous and distinguishes this tool from siblings that operate on users, domains, databases, or cron jobs. The mention of the underlying verified command further confirms the exact 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 intended use is implied by the purpose: call this tool when you need system services and their status. However, there is no explicit guidance about when not to use it or which alternative tool to prefer, so the agent must infer the usage context from the tool name and sibling 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds the underlying command name 'v-list-user-backups', which gives a hint about execution. However, it does not disclose return format, pagination, or any side effects. With annotations handling the main safety traits, the description adds minimal extra transparency.

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 a second sentence noting the underlying command. It is concise, with no redundant words, and immediately conveys the primary 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?

For a simple read-only list tool with an output schema (not shown), the description is minimally sufficient. However, it lacks usage context (when to use, alternatives) and parameter explanations. Given the simplicity of the operation, it is adequate but leaves gaps that an agent might need to infer.

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

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

The schema has 0% description coverage, so the description must compensate. It does not explain the 'user' parameter (though the phrase 'a user's backups' implies it) and provides zero information about the 'format' parameter (enum json/plain). The parameter names are self-explanatory but the description adds almost no semantic value beyond the schema.

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

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

The description clearly states the action: 'List a user's backups.' It is specific to a resource (user backups) and distinguishes from other list tools like list_users or list_web_domains by naming the exact resource. It does not explicitly differentiate from siblings but 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 provides no guidance on when to use this tool vs alternatives, such as backup_user (for creating backups) or get_user (for general user info). It lacks any context about prerequisites, scenarios, or exclusions. There is no mention of when this tool is appropriate or not.

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, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds that it 'executes verified command v-list-users,' which hints at the underlying action but does not disclose output behavior, permissions, or side effects beyond what annotations already convey. With annotations present, the description provides marginal additional behavioral context.

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

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

The description is two short sentences with no filler. The core purpose is front-loaded, and the second sentence about the verified command is brief. It is concise, though the second sentence could be considered slightly redundant; still, it earns high marks for its minimal structure.

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

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

Given the tool's simplicity, an output schema exists, and annotations cover safety, the description is largely adequate. However, it omits any mention of the format parameter, pagination, or whether it returns only a subset of users. It also provides no routing to get_user for single-user lookup, leaving some contextual gaps.

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

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

The schema has 0% description coverage for the single optional 'format' parameter with enum ['json', 'plain'] and default 'json'. The description does not mention this parameter at all, so it fails to compensate for the low coverage. While the parameter is simple and self-documenting in the schema, the description adds no meaning beyond what the annotated schema 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 states a specific verb and resource: 'List HestiaCP users.' It also mentions 'Executes verified command v-list-users,' which adds implementation specificity. However, it does not explicitly distinguish itself from the sibling get_user or other list_* tools, so it is clear but lacks 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?

No guidance is provided on when to use this tool versus alternatives like get_user or list_web_domains. The description only says 'List HestiaCP users,' which implies it is for retrieving all users, but there is no explicit when-to-use context or exclusion of 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 declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the detail that it 'Executes verified command v-list-web-domains,' which hints at a specific backend command but does not explain behavior like output format, pagination, or ordering. With annotations covering safety, a 3 is appropriate.

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 core purpose is front-loaded, and the backend command detail is a useful addition. It is appropriately sized for a simple list operation.

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

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

The tool has an output schema, so return values are documented elsewhere. The description covers the main purpose and the required user scope. However, it does not mention the 'format' parameter or any filtering/ordering behavior, and it does not differentiate from sibling list tools. For a simple list tool with annotations and output schema, 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 0%, so the description must compensate. The description mentions 'a user's web domains,' which maps to the required 'user' parameter, but it does not explain the 'format' parameter or its enum values. The schema itself documents the parameters, but the description adds minimal semantic value 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: 'List a user's web domains.' It clearly identifies the operation and the target resource. It does not explicitly differentiate from siblings like get_web_domain or list_dns_domains, but the resource type is clear 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 usage context: it lists web domains for a user, and the required 'user' parameter indicates the scope. However, it does not explicitly state when to use this tool versus alternatives like get_web_domain (for a single domain) or list_dns_domains (for DNS domains). The context is clear but exclusions 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 establish destructive and idempotent behavior, so the description is not fully responsible for safety disclosure. It adds some useful context by stating that the user's services are also suspended and that a verified underlying command is executed, but it does not explain side effects or reversibility 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 short and front-loaded with the primary action. The second sentence about executing v-suspend-user adds minimal value but is not verbose enough to significantly hurt clarity.

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

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

For a destructive operation with three parameters, the description is incomplete. It omits parameter-level semantics, especially the restart option, and does not tell the agent how to confirm or what effects the suspension has beyond 'their services.'

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 only 33%, and the description does not compensate by explaining the parameters. In particular, the meaning of 'restart' is left entirely to inference, and the description only loosely maps to the 'user' 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 states a clear verb and resource: suspends a user and their services. It does not explicitly differentiate from siblings like delete_user or unsuspend_user, but the verb 'suspend' conveys a distinct action from deletion or reactivation.

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. The intended use is only implied by the tool name and the confirm flag, rather than stated explicitly.

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 that the operation affects 'their services' and that it 'Executes verified command v-unsuspend-user'. Annotations already communicate non-read-only, non-destructive, and idempotent behavior, so the description contributes some context but does not disclose side effects, such as what the restart parameter does to services.

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

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

Two short sentences with no filler. The core purpose is front-loaded, and the implementation detail about the verified command is brief and additive.

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

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

For a simple two-parameter operation with annotations and an output schema, the description is mostly adequate, but it does not explain restart's role or connect this tool to the suspend_user lifecycle. An agent could call it correctly, yet some behavioral context must be inferred.

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

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

Schema description coverage is 0%, and the description only echoes the word 'user' without explaining parameter semantics. The restart parameter, including its yes/no default and effect on services, is left entirely to the schema, which is a meaningful gap for a mutating tool.

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 ('Unsuspend') on a specific resource ('a user and their services'), which clearly distinguishes it from siblings like suspend_user, list_users, and delete_user. The scope is explicit and not a tautology of the title.

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 'unsuspend' implies this is used to reverse a suspension, and it is implicitly contrasted with the sibling suspend_user. However, there is no explicit guidance about when to use it, prerequisites such as the user being currently suspended, or why to prefer it over related tools.

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