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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so safety is covered. The description adds genuinely non-obvious behavioral context: the breakdown of what is measured (disk, bandwidth, databases, email accounts, domains) and the sentinel convention that "a null maximum means unlimited", which an agent could easily misread as zero or missing data.

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

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

Two short sentences, zero filler. The scope statement comes first and the null-maximum caveat follows immediately, which is the right ordering for an agent skimming before a call.

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

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

With no output schema, the description carries responsibility for return semantics; it does list the measured resources and explains null maximums, which is enough to interpret results. It does not describe the response shape (e.g., used-vs-maximum pairing) or whether limits come from the package, leaving a modest gap.

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

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

Schema description coverage is 100% and the single parameter is fully documented in the schema, including the lowercase pattern and a pointer to whm_list_domains for discovering the username. The description adds nothing about the parameter, which is acceptable at this coverage level but is the baseline rather than a contribution.

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?

"Get one account's usage against its limits" names a specific verb and resource and scopes it to a single account, which implicitly separates it from server-wide siblings like whm_disk_usage and whm_bandwidth_usage. It stops short of naming those alternatives explicitly, so the differentiation must be inferred from the word "one account's".

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

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

Usage is only implied: the scoping to a single account suggests this is the per-account counterpart to the aggregate disk/bandwidth tools, but there is no explicit "use this when... use X instead" guidance and no statement of prerequisites such as needing an existing account.

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, so the safety profile is covered. The description adds useful behavioral context that results are 'latest' (recency) and scoped to a single account, but says nothing about how many problems are returned or whether empty results are possible.

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

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

A single sentence that front-loads the action and resource, then immediately justifies the tool's value. No filler or redundant restatement of the title.

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

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

For a simple one-parameter read tool with full annotation coverage and no output schema, the description covers purpose, scope, and diagnostic motivation adequately. Only the shape of the returned problem list is left implicit, which is a minor gap.

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

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

Schema coverage is 100% and the schema's own parameter description already explains the lowercase username format and routes the agent to whm_list_domains. The description's phrase 'for one account' only reinforces the per-account scoping, so the baseline 3 applies.

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

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

States a specific verb and resource ('List the latest AutoSSL domain validation (DCV) problems') scoped to one account, and explains the diagnostic meaning of the results. It is clearly distinguishable from sibling whm_ssl_certificates by its focus on problems rather than certificates, though it does not name that sibling explicitly.

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 for when this tool applies: when a certificate isn't renewing and the cause is likely DCV failure. It does not state exclusions or point to an alternative tool for other SSL questions, so it falls short of a full when/when-not treatment.

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, destructiveHint=false and openWorldHint, so safety is covered. The description adds behavior beyond that: results are sorted highest-first and default to the current month, both of which affect how the agent reads output. It does not discuss pagination behavior or data staleness, which would be needed for a 5.

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 scope and sort order come first, followed by the default and the practical limit tip. Every clause carries information the agent can act on.

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

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

For a zero-required-parameter, read-only listing tool with fully documented schema and no output schema, the description covers scope, default period, ordering, and a usage tactic. The only gap is that the return shape is not described at all, which is acceptable given no output schema exists but leaves the agent guessing at field names.

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

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

Schema description coverage is 100%, so every parameter is already documented in the schema, making 3 the baseline. The description reinforces the month default and explains the practical meaning of a small limit, but adds no new syntax or constraints beyond what the schema states.

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

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

The description gives a specific verb and resource ('List bandwidth usage per account'), plus the granularity ('for one month') and ordering ('highest first'), which clearly separates it from whm_disk_usage and whm_account_resource_usage. It stops short of naming a sibling to route away from, so it is clear but not maximally differentiating.

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?

'Defaults to the current month' sets the no-argument behavior, and 'Use a small limit to find the biggest consumers' is a concrete usage recipe that tells the agent how to get value quickly. There is no explicit when-not-to-use guidance or pointer to an alternative tool, which keeps it below 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?

Beyond the read-only and non-destructive annotations, it discloses the non-obvious behavior that unlimited-quota accounts have a null percent_used and are excluded when min_percent is applied. This helps agents interpret and filter results correctly.

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

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

Three concise sentences move from purpose to practical invocation patterns and then to an important edge case. Every sentence adds useful information, with no repetition of defaults or schema constraints.

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 six optional, fully documented parameters, the description supplies the purpose, principal use cases, and the main result-filtering caveat needed for correct invocation. The annotations and schema cover the remaining safety, pagination, sorting, and cache-freshness details.

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

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

Although schema description coverage is 100%, the description adds task-oriented meaning by explaining how min_percent, the default sort, and limit support common investigations. The unlimited-quota edge case also adds filtering semantics not present in the parameter 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?

“List disk and inode usage per account” gives a specific verb, metrics, and account-level scope. This clearly distinguishes it from whm_bandwidth_usage and the broader whm_account_resource_usage without requiring schema inspection.

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 two concrete usage patterns: set min_percent to find accounts near quota, or use the default sort with a small limit to find the largest consumers. It does not explicitly explain when to choose a sibling tool instead, but the intended tasks are clear.

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

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

Annotations already declare readOnly, idempotent, non-destructive and open-world, so the safety profile is covered. The description adds behavior not present in the structured data: results are ordered newest first, and the default result set is narrowed to failures and deferrals over a 24-hour window, which materially shapes how an agent interprets an empty response.

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, zero filler, with the core action and the diagnostic intent front-loaded and the default scope trailing as supporting detail. Every sentence earns its place.

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

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

For a five-parameter, all-optional, read-only search with a fully documented schema and no output schema, the description covers purpose, ordering, and default filtering adequately. It could say slightly more about what a returned record contains or that results are capped by limit, but nothing needed to call the tool correctly is missing.

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

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

Schema description coverage is 100%, with every parameter documented including defaults, ranges, and enum values for statuses. The description only restates the two defaults and adds no filtering syntax, matching rules, or guidance on combining sender/recipient/statuses beyond what the schema says, so the baseline of 3 applies.

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

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

The description gives a specific verb and resource ("Search the server's mail delivery records") plus the intent behind it ("work out why a message did not arrive"). No sibling in the list touches mail delivery logs, so the tool is unambiguously distinguishable from the account, DNS, disk, and error-log tools.

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

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

It names a concrete use case — diagnosing non-delivery — which effectively tells the agent when to reach for this tool, and it explains the default scope (failed and deferred, last 24 hours) that applies when no parameters are supplied. It stops short of stating when not to use it or pointing at an alternative for successful-delivery auditing.

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, destructiveHint=false, and openWorldHint, so the safety profile is covered. The description adds value beyond that by disclosing the payload contents ('limits and suspension details'), but it says nothing about behavior for a nonexistent or malformed user, nor about how suspension state affects returned limits.

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, front-loaded with the verb and resource, with the return contents appended as a qualifier. Nothing is wasteful or padded.

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

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

For a one-parameter, read-only lookup with no output schema, the description gives enough to call it correctly and tells the agent broadly what comes back. A brief note on behavior for unknown usernames would make it complete, but the gaps are minor at 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 coverage is 100% and the schema itself documents the single 'user' parameter, its lowercase pattern, and a sibling pointer for finding the account that owns a domain. The description adds no parameter-level meaning, so the baseline of 3 applies.

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

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

The description states a specific verb and resource ('Get the full summary of one cPanel account') and scopes it to a single account, which implicitly contrasts with the plural whm_list_accounts. It does not explicitly name or differentiate itself from siblings such as whm_account_resource_usage, which could also be used to inspect a single 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?

There is no explicit when-to-use or when-not-to-use guidance, and no stated alternative. The phrase 'one cPanel account' hints that browsing all accounts belongs to whm_list_accounts, but the agent must infer that; the schema's pointer to whm_list_domains carries any real routing help.

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, destructiveHint=false and openWorldHint, so the safety profile is fully covered. The description adds the useful fact that the response carries a serial and per-record line_index values that are prerequisites for the edit tool, but says nothing about record volume, pagination, or whether the zone must already exist.

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

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

Two sentences, zero filler, with the primary purpose front-loaded and the downstream action placed second. Every clause carries operative 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?

With one required parameter, full schema coverage and no output schema, the description supplies enough: what is returned and how the result feeds the edit tool. A brief note on missing-zone behavior or record volume would close the remaining 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 coverage is 100% and the single 'zone' parameter is documented with format and an example, so the schema does the heavy lifting. The description adds no additional meaning about the zone parameter (e.g., whether an ID, domain, or subdomain is accepted), so the baseline 3 applies.

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

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

States a specific verb and resource ('Get a zone's records and current serial'), which tells an agent exactly what comes back. It does not explicitly contrast with the sibling whm_list_dns_zones, leaving the get-one-vs-list-many distinction to be inferred from the names.

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 forward guidance: read here first, then hand the serial and line_index values to whm_edit_dns_zone to modify. It gives no exclusion against whm_list_dns_zones or whm_get_account, but the read-then-edit workflow is stated concretely.

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 readOnly/idempotent/non-destructive, so the description's job is to add context, which it does: it explains what each source actually reads (a file in the document root versus Apache logs) and discloses the known failure mode where php returns empty. It stops short of describing the shape of the returned lines.

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?

Four short sentences, front-loaded with the core action, then source semantics, then the fallback tip. No sentence is filler and the ordering matches how an agent would reason about the call.

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

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

For a three-parameter read tool with no output schema, the description covers selection logic and failure modes well. The only real gap is that it never characterizes the return value (raw log lines versus structured entries), which the agent would otherwise have to discover.

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 67% and the description compensates for the most important gap by explaining what each enum value of source reads. The lines parameter is already documented in the schema and domain is self-evident, so this is close to full 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?

States a specific verb and resource ('Get recent error log lines') scoped to 'a domain', and no sibling tool in the list reads logs, so the agent can place it immediately. The title and description reinforce each other rather than restating.

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?

Gives concrete selection guidance for the source parameter and an explicit fallback heuristic: 'If php returns nothing... try apache_error.' That is real when-to-use advice, though it never says when not to reach for this tool versus other diagnostics like whm_server_status.

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, non-destructive and openWorld, so the safety profile is covered. The description adds genuine context beyond that: the returned fields and the username sort order. It omits important operational behavior — the default limit of 100 (silent truncation) and the regex semantics of search — which materially affect result interpretation.

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

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

Two sentences, front-loaded with the verb and resource, then the payload fields and ordering. Nothing is redundant and no filler phrases are present.

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

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

For a 6-parameter, filterable, paginated list tool with no output schema, the description covers what is returned but not the pagination contract, the default 100-item cap, or the regex-vs-exact search distinction. The annotations carry the safety profile, but result-shaping behavior is only partially disclosed.

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

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

Schema description coverage is 100%, so every parameter is already documented in the schema; baseline 3 applies. The description adds no extra meaning about the search, exact, suspended, or pagination parameters, but it also has no gap to compensate for.

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 cPanel accounts') and enumerates the salient returned fields (main domain, plan, owner, disk usage, suspension status). It does not explicitly distinguish itself from siblings like whm_get_account (single account) or whm_list_domains (domain-centric listing), but the scope is unambiguous enough to select on.

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 when-to-use guidance and no mention of alternatives, even though several siblings overlap (whm_list_domains, whm_get_account, whm_account_resource_usage). The description never hints that the tool supports filtering by search/exact/search_type/suspended, so an agent could easily miss the tool's main selection power.

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, destructiveHint=false, and openWorldHint=true, so the safety profile is fully covered. The description adds only the returned fields (size, assigned users), which is useful given there is no output schema, but says nothing about pagination behavior, permission requirements, or empty-account results.

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

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

One sentence, front-loaded with the action and resource, with the value-add (size and users) trailing. Nothing redundant and nothing padded.

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 paginated read with a fully documented three-parameter schema and complete annotations, the description covers purpose and return content adequately. A note on what an empty result means or on account-existence errors would close the remaining gap, but no output schema is expected here.

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

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

Schema description coverage is 100%, with 'user' even cross-referencing whm_list_domains and 'offset' explaining next_offset usage. The description adds no parameter meaning beyond the schema, so the baseline 3 applies.

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

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

The description names a specific verb and resource ('List an account's MySQL databases') and adds the scope of returned data ('with their size and assigned users'). It is clearly distinct from siblings like whm_disk_usage or whm_get_account, though it never explicitly contrasts with the adjacent whm_list_database_users.

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

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

It implies per-account scope via 'an account's' but gives no explicit when-to-use guidance, no prerequisites, and no named alternative. An agent must infer from the sibling list that whm_list_database_users is the complement, not a substitute.

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, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds that results include per-user database access mappings, which is useful context, but says nothing about pagination behavior, empty results, or account-level failures.

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 compact sentence that front-loads the resource and includes the notable detail about database access in the same breath. Nothing is wasted, though there is no structural elaboration beyond that single 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 listing tool with full schema coverage and a clear annotation set, the description covers what is being returned and for which account. Pagination is handled entirely by schema-documented limit/offset, so nothing critical is missing.

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

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

Schema coverage is 100%, with the 'user' parameter even documenting the lowercase format and pointing at whm_list_domains for domain-to-account lookup. The description adds no parameter-level meaning beyond the schema, so the baseline of 3 applies.

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

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

The description gives a specific verb ('List') and resource ('an account's MySQL users'), plus the added scope of returning which databases each user can access. This distinguishes it clearly from sibling whm_list_databases, which lists databases rather than users.

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

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

The description implies usage by scoping to a single account's MySQL users, but it never explicitly states when to use this tool versus whm_list_databases or other listing tools. No prerequisites or exclusions are 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 declare readOnlyHint, idempotentHint, non-destructive and openWorld, so the safety profile is covered. The description adds only the server-scoping fact; it says nothing about pagination behavior, result ordering, or what a zone record contains.

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

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

A single front-loaded sentence with no filler, which is efficient. It is arguably too terse rather than bloated, so no points are lost for verbosity.

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-optional-parameter list tool with rich annotations this is close to sufficient, but with no output schema the description could say what a zone entry looks like or that results are paginated. The absence of any pointer to whm_get_dns_zone leaves a gap an agent must resolve itself.

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

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

Schema coverage is 100% and both limit and offset are documented in the schema, including the next_offset hint. The description adds no meaning beyond that, which is the expected baseline when the schema does the work.

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 the DNS zones') plus a scope ('on this server'), so the agent knows exactly what is returned. It does not, however, distinguish itself from the sibling whm_get_dns_zone, which an agent must infer is the single-zone detail call.

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

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

There is no explicit when-to-use or when-not-to-use guidance, nor any mention of the sibling whm_get_dns_zone as the alternative for inspecting one zone. Usage is only implied by the verb '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?

The annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so the safety profile carries little weight. The description adds real value by disclosing the shape of each result row, but says nothing about pagination behavior or result-size limits even though the schema exposes limit/offset.

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, and the return-field inventory is front-loaded so an agent learns what it gets before how to filter. The second sentence is slightly redundant with the schema's own domain description.

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

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

For an all-optional, read-only list tool with full schema coverage and annotations, the description covers purpose, output fields, and one filtering strategy. The only meaningful omission is pagination guidance for large domain lists, which the schema partially handles via offset.

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

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

Schema description coverage is 100%, so every parameter already has its own documented meaning, which sets the baseline at 3. The description adds only a light hint that the domain filter reveals ownership; the user, domain_type, limit and offset filters get no extra interpretation.

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

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

The description gives a specific verb and resource ("List domains and subdomains") and enumerates the fields returned (owning account, type, document root, PHP version), which clearly separates it from siblings like whm_list_accounts or whm_list_dns_zones. It stops short of explicitly naming a sibling it replaces, so it is 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?

One concrete usage scenario is given: "Use the domain filter to find which account owns a domain." There is no guidance on when to prefer this over whm_list_accounts or whm_list_dns_zones, and no exclusions or prerequisites are stated, leaving usage largely implied.

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, so the safety profile is covered. The description adds a modest amount of value by naming the returned attributes (disk usage, quota, suspension status), but says nothing about pagination limits, result ordering, or behavior when the user has no mailboxes.

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

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

A single well-formed sentence with the resource front-loaded and zero filler. It is efficient, though it is thin enough that it could carry one more clause about scoping or pagination without becoming bloated.

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 four fully documented parameters and complete annotations, the definition covers what it returns and what it operates on. With no output schema present, a brief note on pagination or empty-result behavior would have made it fully self-sufficient.

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

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

Schema description coverage is 100% and every parameter carries a meaningful description, including a cross-reference from `user` to whm_list_domains. The tool description adds no parameter-level detail beyond that, but with full schema coverage the baseline of 3 is raised slightly by the description scoping results to a single account's mailboxes.

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

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

The description names a specific verb and resource ("List an account's mailboxes") and even enumerates the fields returned, so it is clearly distinct from siblings like whm_list_email_forwarders or whm_list_domains. It stops short of explicitly contrasting itself with those siblings, which keeps it from a 5.

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

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

Usage is only implied: the agent can infer this is the tool for enumerating mailboxes belonging to a given cPanel user. There is no explicit when-to-use/when-not-to-use guidance and no mention of the adjacent forwarder or delivery-search tools as 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 essentially nothing beyond them: it does not mention pagination behavior, what happens for an empty domain, or permissions required under a reseller/WHM 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?

One short sentence with the resource and scope front-loaded and zero filler. It is efficient, though the terseness means it borders on under-specification rather than ideal economy.

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 operation with no output schema and well-annotated safety hints, the definition is minimally viable. It stops short of describing the shape of returned forwarder records or how the list is ordered/paginated, which would be the useful addition given no output schema exists.

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 75%, so most parameters are already documented, and the description's phrase 'on one domain' only reinforces the domain scoping already implied by the required 'domain' field. No added meaning for 'user', 'limit', or 'offset' 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?

States a specific verb ('List') and resource ('email forwarders') plus the scope ('on one domain'), which is enough to distinguish it from whm_list_email_accounts or whm_list_domains without opening a schema.

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

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

There is no explicit when-to-use or when-not-to-use guidance, and no named alternative. The only implicit signal is 'on one domain', which hints at domain scoping but leaves the agent to infer that a username plus domain is required and how this differs from listing email accounts.

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 readOnly, idempotent, non-destructive behavior, so the safety profile is covered. The description contributes real behavioral detail beyond that: sites with unresolved versions are reported via unresolved_count and are silently excluded from filtering, which is exactly the kind of trap an agent needs flagged.

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

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

Three sentences, front-loaded with purpose, then filters, then the caveat. No filler or restated schema text.

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

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

With five fully documented parameters and no output schema, the description covers the main risk areas: filter semantics and the unresolved-version blind spot. A brief note on response shape or pagination would close the remaining gap, though the schema already references next_offset.

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

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

Schema coverage is 100%, so the baseline is 3. The description earns above baseline by clarifying the direction of older_than ("below this version") and by explaining that filter results omit unresolved hosts, which amplifies how the filter parameters should be interpreted.

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 opening sentence gives a precise verb and resource: list the PHP version of every virtual host. No sibling tool in the set covers PHP versioning, so the tool is distinguishable 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 states the concrete use case for both filter parameters (find sites on an outdated version) and adds a caveat about checking unresolved sites separately. It stops short of naming a downstream action or alternative tool to consult, but the context given is clear.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), so the description only needs to add what they cannot: it discloses the two distinct payloads returned and that the safety settings enumerate enabled write-tool categories. It does not describe the shape or naming of that output, which matters slightly given there is no output 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?

Two sentences with zero filler, front-loaded with the primary payload and followed by the practical triage hint. Every clause carries information an agent would otherwise have to guess.

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

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

With no parameters and no output schema, the description's burden is to say what comes back, and it does so at a useful level of abstraction for both payloads. A little more on the output structure of the safety settings would make it fully self-sufficient, but nothing needed to call it correctly is missing.

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

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

The tool takes zero parameters, so the schema imposes nothing to interpret and the baseline is 4. The description correctly implies no input is required, leaving nothing ambiguous.

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?

"Get the server's load averages and this MCP server's safety settings" names a specific verb and two concrete resources, and it explicitly scopes the second to "this MCP server" so it is not confused with the WHM account/domain data tools in the sibling list.

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

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

"If a write tool seems to be missing, check here first" gives an explicit diagnostic trigger that no sibling covers, which is unusually actionable routing guidance. It does not state a when-not condition or name an alternative for the load-average half, but the context is clear enough that an agent will not misfire.

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 readOnly, idempotent, non-destructive and open-world, so safety is covered. The description adds behavior the annotations cannot: results are ordered by soonest expiry, and a negative days_remaining signals an already-expired certificate. It does not mention pagination behavior or how many hosts are scanned, which keeps it below a 5.

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

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

Three short sentences, front-loaded with the core action and ordering, then the filter, then the edge-case semantics. No filler or restatement of the tool name.

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

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

With no output schema, the description carries responsibility for return semantics, and it does explain ordering and the days_remaining sign convention. It remains silent on result volume and pagination expectations and on how it relates to the AutoSSL diagnostics tool, leaving a small gap for a 4-parameter listing tool.

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

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

Schema description coverage is 100%, so user, limit, offset and expiring_within_days are already documented, which sets the baseline at 3. The description reinforces expiring_within_days as the 'needs attention' filter and clarifies the meaning of the returned days_remaining field, but adds no syntax or format detail 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?

States a specific verb and resource ('List the SSL certificate installed on each virtual host') and adds the sort order, so the agent knows exactly what comes back. It does not differentiate itself from the closest sibling, whm_autossl_problems, which also concerns certificate problems, so it stops short of a 5.

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

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

The only usage guidance is 'Use expiring_within_days to find certificates that need attention', which explains one parameter's purpose rather than when to pick this tool over whm_autossl_problems. Usage is implied by the resource name but 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.