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

Beyond the annotations, the description adds two genuinely useful behavioral facts: TTL is not settable via API, and `name` is normalized to an FQDN when sent to Zone. This is the kind of context annotations (readOnly=false, idempotent=false, openWorld=true) cannot carry.

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?

It is front-loaded with the core action, but the middle sentence is a long run-on list of type-specific fields that mostly duplicates the schema descriptions one-for-one. That list could be compressed or dropped without loss.

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 15 parameters and an output schema present, the definition covers the essentials but omits which fields are mandatory for which record types (e.g. priority for MX/SRV) and any error behavior. For a tool with 11 record types this leaves meaningful gaps for an agent composing a 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 coverage is 100%, so every parameter already has a description, including the 'MX, SRV: priority' and 'CAA: flag' notes that the description largely restates. The only added meaning is the '@' apex shorthand and the FQDN normalization behavior, which the schema hints at but doesn't fully explain.

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

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

The description opens with a specific verb and resource ('Create a DNS record'), which is unambiguous and easily separable from the sibling list/update/delete_dns_record tools by name alone. It doesn't explicitly contrast itself with those siblings, 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?

There is no guidance on when to create versus update an existing record, no prerequisites (e.g. that the zone must already exist), and no mention of what happens if a conflicting record exists. The agent must infer all routing decisions from the tool name.

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

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

Annotations already declare readOnly=false, destructive=false, idempotent=false and openWorld=true, so the safe-creation profile is covered. The description adds nothing beyond that (no conflict/duplicate behavior, no permission or quota notes), but it does not contradict the annotations either.

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

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

One tight sentence with the resource and the alias relationship front-loaded and the '(alias)' gloss adding useful terminology. No filler whatsoever.

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 an output schema present and annotations covering safety semantics, the description only needs to fix the tool's identity and it does. The remaining gap is that it never mentions the required vserver scoping, which matters for a multi-webhosting account, but the schema covers that parameter in detail.

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% with descriptions on address, vserver and fwd_addresses; the description only restates address-to-destination mapping and the 'one or more' cardinality that minItems already encodes. The `comment` parameter and the vserver scoping requirement receive no elaboration in the description.

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

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

The description uses a concrete verb ('Create') with a specific resource ('e-mail forwarder (alias)') and states the forwarding relationship between `address` and the destinations. It implicitly distinguishes itself from the list/update/delete forwarder siblings, though it never names 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?

There is no when-to-use guidance, no mention of prerequisites (e.g. needing an existing webhosting/vserver, see list_webhostings), and no statement about what happens if the alias already exists or how it relates to update_mail_forwarder/create_mail_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 destructiveHint=true, idempotentHint=true and openWorldHint=true, so the safety profile is covered. The description adds meaningful behavior beyond that: a confirmation prompt when the client supports it, and the exact outcome semantics when the user declines ('declined'/'cancelled', nothing deleted). It stops short of covering failure modes such as a missing or already-deleted record.

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 confirmation behavior. The parenthetical '(or cancelled)' is slightly noisy but does convey a real variant status, so no sentence is wasted.

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 a complete output schema and 100% parameter coverage, the description only needs to explain the destructive confirmation flow, which it does, including the declined/cancelled outcome. Minor gap: no mention of what happens on invalid ids or whether dependent records are affected.

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

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

Schema description coverage is 100%, so all three parameters (zone, type, id with a full enum list) are already fully documented in the schema. The description reiterates that id comes from list_dns_records, which is already stated in the id's schema description, and adds no further meaning for zone or type. Baseline 3 applies when the schema carries the load.

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 record') and names the lookup tool that supplies the id, so it is distinguishable from create_dns_record and update_dns_record. It does not explicitly contrast itself with those siblings, but the operation is unambiguous.

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

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

It gives a clear prerequisite: the id must come from list_dns_records, which tells an agent to look the record up first. It does not name explicit when-not-to-use conditions, but for a destructive delete the usage context is adequately conveyed.

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, idempotentHint=true and openWorldHint=true, so the safety profile is largely covered. The description still adds real value beyond them by explaining the client-side confirmation prompt and the 'declined'/'cancelled' outcome, which an agent cannot infer from structured fields. It stops short of saying what happens when the forwarder does not exist or what error shape to expect, so a 3 rather than a 4.

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 action front-loaded and no padding. The parenthetical '(or cancelled)' introduces slight ambiguity about which status string to expect, which is the only small friction.

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 an output schema present and full schema coverage, the description only needs to carry behavior, and it does explain the confirm/decline path and resulting status. The missing piece is failure behavior for a non-existent or unowned forwarder, which is minor for a two-parameter delete.

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

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

Schema description coverage is 100% and both parameters (vserver, address) are documented in the schema, including a pointer to list_webhostings. 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 ('Delete an e-mail forwarder'), which cleanly separates it from the create_mail_forwarder, update_mail_forwarder and list_mail_forwarders siblings by operation type. It never names those siblings explicitly, so differentiation comes from the verb rather than an explicit routing statement.

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

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

Usage is implied by the destructive verb, and the confirmation flow gives useful context for the interaction. However, it does not say how to locate the forwarder to delete (e.g. via list_mail_forwarders), nor when to prefer update_mail_forwarder over deletion.

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 safety (readOnlyHint=true, openWorldHint=false), so the remaining value is provenance, and the description supplies it by naming the official OpenAPI spec as the source, which tells the agent the answer is authoritative rather than inferred. It does not say what happens when a path is not found in the spec.

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 capability front-loaded and the path-format caveat second. The inline examples do real work rather than padding.

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?

An output schema exists, so return values need not be enumerated; the description still names the three things returned (parameters, request body, response fields), which is enough for an agent to decide to call it. It could be slightly stronger by relating itself explicitly to the sibling tools.

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

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

Schema coverage is only 50% and the undocumented parameter is `path`; the description compensates by explaining that it accepts either a template ('/vserver/{service_name}/crontab') or a concrete path, with examples. `method` is already documented in the schema, so no further detail is needed there.

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 concrete verb and resource: it shows parameters, request-body fields and response fields for an endpoint, sourced from the official OpenAPI spec. That distinguishes it from siblings like find_endpoints (discovery) and zone_api_request (execution), since this one is pure spec introspection.

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

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

Usage is implied rather than stated: an agent can infer you call this before zone_api_request to learn an endpoint's shape, but the description never says when to use it instead of find_endpoints or zone_api_request. No preconditions or failure cases (e.g. unknown path) 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=true and openWorldHint=false, so safety is covered; the description adds the real value of disclosing matching semantics (conjunctive 'every word') and the empty-query listing behavior. It stops short of noting result limits or pagination, which is the only remaining behavioral gap, and an output schema exists so return shape need not be explained.

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 tight sentences, with the core action and matching scope front-loaded before the optional-parameter note and the workflow pointer. The parenthetical examples are useful rather than filler, though they add a little length that could be trimmed.

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

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

For a single-optional-parameter read tool with annotations and an output schema, the description covers everything an agent needs: what is searched, how matching works, what happens with no query, and which tools to call next. No material gap remains.

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 full burden and does: it defines the matching fields, the AND-across-words rule, the option to omit the parameter for an unfiltered listing, and gives three illustrative values ('redis', 'mail autoreply', 'cloud resize'). This adds meaning well beyond the bare `type: string` in 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 ('Search the ZoneID API v2 reference for endpoints') and narrows the search scope to path, tag and summary. It is clearly distinguished from the sibling tools describe_endpoint and zone_api_request, which are named as separate steps rather than competitors.

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 explicit when-to-use (free-text lookup by keyword), an edge case with its behavior ('Omit query to list all endpoints'), and a workflow that routes the agent onward to describe_endpoint for details and zone_api_request to call. Nothing about invocation choice is left to inference.

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

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

Annotations already supply readOnlyHint=true and openWorldHint=true, so safety is covered; the description adds value by enumerating the exact payload an agent will receive (registration fields plus nameservers). It stops short of disclosing error behavior for unknown domains or any lookup/latency caveats.

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

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

A single front-loaded sentence with no filler; the verb and scope come first and the parenthetical field list earns its space by signalling what the response contains.

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?

Low-complexity, single-parameter read tool with an output schema, so return values need not be described at length; the description is sufficient to select and invoke it. A brief note on the not-found case or sibling routing would make it 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 coverage is 100% and the single 'domain' parameter is documented in-schema with an example ('example.com'). The description adds no additional meaning beyond that, so the baseline 3 for high-coverage schemas 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?

Names a specific verb and resource ('Get one domain's registration details') and enumerates the data returned (expiry, DNSSEC, autorenew, delegation, nameservers). The singular 'one domain' implicitly distinguishes it from the list_domains sibling, though it never names 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?

Usage is only implied: 'one domain' suggests a single-record lookup as opposed to a listing, which points an agent toward this tool over list_domains. There is no explicit when-to-use, when-not-to-use, or prerequisite statement (e.g. required auth or whether the domain must be registered with this 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=true and openWorldHint=true, so the safety profile is covered. The description adds nothing behavioral beyond that — no indication that data is fetched live from the server, no note on failure modes for an unknown vserver, and it spends its only sentence restating return contents.

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?

It is short and contains no filler words, which is good. However, the content is a comma-separated field dump that duplicates the output schema rather than front-loading the tool's purpose, so the brevity buys little.

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?

An output schema exists, so the description did not need to enumerate return fields — yet that is essentially all it does. For a tool with one required argument and open-world reads, it omits the purpose, the typical workflow position, and any caveats, leaving clear 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?

Schema description coverage is 100% and the single parameter is documented with format hints and an example ('example.com') plus a reference to list_webhostings. The description contributes no additional meaning about the vserver argument, so 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 the resource ('Server details for a webhosting') and enumerates what is returned, so an agent can grasp the topic. But it is a bare noun phrase with no verb, and it never distinguishes this from siblings such as list_webhostings or get_domain, which also return hosting-related data.

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

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

There is no when-to-use guidance: no statement of the scenario that calls for server info, no prerequisite that a webhosting must exist or be listed first. The only pointer to list_webhostings lives in the schema, not the 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 readOnlyHint=true and openWorldHint=true, so safety is covered. The description adds the useful detail of what the entries contain (type http/system, reporting, state) but says nothing about result volume, pagination, or ordering for a list endpoint.

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 front-loaded sentence with no filler; the field enumeration earns its place by telling the agent what to expect. 'reporting and state' is slightly vague but does not bloat 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?

An output schema exists, so return values need not be explained, and the single parameter is fully described in the schema. The definition is adequate for a simple read-only listing tool, with only pagination/volume behavior left unaddressed.

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 'vserver' parameter is documented there with an example and a pointer to list_webhostings. The description adds nothing about parameters, so 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?

Uses a specific verb 'List' plus the resource 'cron jobs' and enumerates the fields surfaced (schedule, command/URL, type http/system, reporting, state), which makes the scope concrete. It does not name or contrast with any sibling tool, though none of the listed siblings cover cron, so confusion risk is low.

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?

Listing is inherently implied by the verb, and the required 'vserver' scoping is left entirely to the schema. There is no statement of when to prefer this over another tool, nor any prerequisite or exclusion guidance.

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

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

Beyond the annotations, the description discloses important behavior: omitting `type` triggers one request per record type, 11 total, against a 60/min limit. It also explains FQDN naming, record `id` usage, `modify`/`delete` flags, system-managed records, and that TTL is not exposed.

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 front-loaded with the core action and then supplies only operationally relevant details. Every sentence adds useful information about filtering, rate limits, or record metadata without unnecessary filler.

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

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

For a read-only list tool with an output schema and clear annotations, the description is complete enough to call correctly. It covers filtering behavior, request cost, record identity, system-managed records, and the TTL limitation.

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

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

Schema coverage is 100%, so the schema already documents the three parameters. The description still adds meaningful semantics for `type` by explaining the per-type request behavior and total request cost, and for `name` by reinforcing that names are FQDNs.

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

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

The description opens with a specific verb and resource: 'List DNS records in a zone.' This clearly distinguishes the read operation from sibling tools such as create_dns_record, update_dns_record, and delete_dns_record.

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

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

It explains how the `type` parameter affects fetches and notes the request cost, which is useful usage context. However, it does not explicitly state when to use this tool versus alternatives or any exclusions, so usage is implied rather than fully guided.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds that results are paginated, but does so with a cryptic 'see `pager`' reference that is not a parameter here and matches no sibling tool, leaving the actual pagination mechanics unexplained. It also discloses the fields returned, which is useful behavioral context, but says nothing about result volume or account/auth scoping.

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 capability front-loaded; nothing is wasted. The parenthetical 'see `pager`' is the one weak element — it is a dangling reference that costs a clause without conveying usable 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?

An output schema exists, so return-value explanation is unnecessary, and the annotations cover safety. The remaining gap is pagination behavior: with 7 optional parameters including page and limit, the description only gestures at paging rather than tying it to those parameters.

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 71%, and the two undocumented parameters (order_by, order_dir) are self-describing enums, so the schema carries most of the load. The description adds nothing about any parameter — the filtering semantics of name, renewable, and needs_renewal are only in the schema descriptions. Baseline 3 applies.

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

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

The description states a specific verb and resource ('List the domains') plus the account scope ('on the ZoneID account') and the fields returned (expiry, DNSSEC, autorenew, delegation). That is enough for an agent to distinguish it from get_domain (single domain) and list_dns_records without opening either 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?

Usage is only implied by the verb: call this when you need to enumerate domains. There is no explicit guidance on when to prefer get_domain over this, or on what filtering combinations are supported for finding a single domain. The only directive given, 'see `pager`', points at something outside this definition and the 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 openWorldHint=true, so the safety profile is covered. The description adds the field set returned, but says nothing about pagination behaviour, ordering, or that results are scoped to a single vserver; with annotations carrying the safety burden, this is adequate rather than rich.

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

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

A single front-loaded sentence with no wasted wording. Slightly awkward phrasing ('on a webhosting') and the trailing field list leans on what the output schema already conveys, but it remains 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?

An output schema exists, so return values need not be spelled out, and annotations cover read-only safety. For a simple filtered list tool the description is nearly complete; only ordering/pagination expectations and exact-vs-substring address matching are left implicit.

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

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

Schema description coverage is 100%: page, limit, address and vserver are all documented in the schema, including the default page size and the vserver example. The description adds no parameter meaning beyond that, so 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 (list) and resource (e-mail accounts/mailboxes) scoped to a webhosting, and names the fields surfaced (quota, spam level, forwards, 2FA). It is distinguishable from siblings like list_mail_forwarders by resource, though it never explicitly contrasts with 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?

Usage is implied by the object being listed: read this to enumerate mailboxes on a given vserver. There is no explicit when-to-use/when-not guidance and no pointer to the closest sibling (list_mail_forwarders) for the forwards data it mentions.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds the useful behavioral fact that each forwarder's target address is included in the result, but says nothing about pagination behavior, result limits, or ordering, which matters given the page/limit parameters.

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 tight sentence with the resource and scope front-loaded and no filler. Nothing needs to be trimmed.

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 an output schema, fully documented parameters, and read-only annotations, the description is sufficient to call the tool correctly. The only shortfall is the absence of any hint about pagination or filtering strategy, which an agent would otherwise have to infer from the schema alone.

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%, including the vserver hint and the page/limit ranges, so the schema does the heavy lifting. The description adds no meaning beyond the schema — notably it doesn't say how the 'address' filter matches (local part vs full alias).

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 e-mail forwarders (aliases) on a webhosting') and clarifies the returned content ('where each one forwards to'), which separates it from list_mail_accounts and the create/update/delete_mail_forwarder siblings. It never names those siblings explicitly, so routing is inferred rather than stated.

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 read-only listing intent is implied by 'List', and the mention of 'a webhosting' implies it is scoped per virtual server. There is no explicit when-to-use statement, no pointer to create_mail_forwarder/update_mail_forwarder for mutations, and no note about paginating when results are large.

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

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

Annotations already declare readOnlyHint=true, so safety is covered. The description adds that returned database users include their allowed hosts, which is a useful output-content hint, but it says nothing about behavior on unknown webhostings, empty results, or pagination. With read-only behavior already declared, the extra value is modest.

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 no filler, and the resource scope is front-loaded. It is arguably too terse rather than bloated, but nothing in it is wasted.

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?

An output schema exists, so return values need not be explained, and annotations cover the read-only safety profile. The single parameter is fully documented in the schema. The only shortfall is the absence of any usage routing or prerequisite note, which is minor for a simple one-parameter read tool.

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

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

Schema coverage is 100% and the only parameter's description already explains the webhosting name convention and points to list_webhostings. The phrase 'on a webhosting' in the description merely echoes the schema, adding no syntax or format detail. Baseline 3 applies since the schema does the heavy lifting.

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 MySQL databases and database users (with their allowed hosts)'. It also scopes to 'on a webhosting', which is clear. No sibling tool covers MySQL, so there is nothing to disambiguate against, 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 gives no explicit when-to-use or when-not-to-use guidance and names no alternatives or prerequisites. Usage is only implied by the noun phrase 'on a webhosting'; the agent must infer that it needs a webhosting name first (which is only stated in the schema, pointing at list_webhostings).

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered, but the description adds real behavioral detail: PEM bodies are omitted by default and private keys are never returned. It stops short of mentioning result size behavior or ordering.

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 compact sentences, front-loaded with what is returned and followed immediately by the sensitive-data caveat. Nothing is redundant 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?

With an output schema present and full schema description coverage, the description only needs to convey scope and the PEM/private-key caveat, which it does. Minor gaps like ordering or result-size expectations are acceptable for this complexity level.

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

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

Schema description coverage is 100%, so the schema already explains both 'vserver' and 'include_pem' (including the 'large' caveat). The description reinforces the include_pem behavior but adds no new syntactic or format meaning beyond it.

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 the SSL certificates on a webhosting') and even summarizes the payload ('with their hosts and validity'). No sibling tool overlaps this resource, so differentiation is implicit rather than stated.

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 alternatives are named. The only hints are indirect: the schema's 'vserver' description points the agent at list_webhostings to find a valid value.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered; the description adds real value by listing the returned data (usage/limits, home directory, MySQL host) and the cross-tool key relationship. It does not discuss pagination behavior, though the schema's page/limit parameters imply it.

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 tight sentences: purpose and payload first, then the practically important key mapping. No filler, nothing buried.

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

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

For a two-optional-parameter read-only list tool with an output schema, the description covers purpose, returned fields, and the critical `name` = `vserver` linkage that no structured field conveys. 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?

Schema coverage is 100% and both parameters (page, limit) are fully documented with defaults and ranges in the schema. The description says nothing about paging, so it adds no meaning beyond the structured field definitions; 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 webhosting packages (virtual servers) on the account') and then enumerates the returned fields, so the agent knows exactly what it gets back. It is clearly distinguishable from siblings like list_domains or list_mysql because it names the webhosting/vserver entity.

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 second sentence gives strong implicit routing: run this to discover the `name` value that the mail, MySQL, cron and SSL tools take as `vserver`. It does not state explicit exclusions or when to prefer a sibling, but the downstream-consumption context is concrete.

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?

Goes well beyond the annotations by disclosing the interactive confirmation flow, that declining leaves state unchanged, and the exact result status values ('declined'/'cancelled'). It also discloses partial-update semantics, which complements but is not implied by destructiveHint=true or idempotentHint=true.

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

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

Three tight sentences, front-loaded with the action, then the update semantics, then the confirmation caveat. No filler and no restatement of the record-type field matrix that the schema already covers.

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 16-parameter mutation tool with a full output schema and rich annotations, this covers the essentials: how to identify the record, how partial updates behave, and what happens on decline. It does not mention that type-specific fields (CAA/SRV/TLSA/SSHFP) only apply to matching record types, leaving that to the schema.

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

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

Schema description coverage is 100%, so per-field meaning is already documented; the description adds genuine semantic value with the merge/patch rule ('only the fields you pass are changed'). The id-sourcing note duplicates the schema's own description of `id`, which keeps this from a 5.

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 ('Change an existing DNS record') and implicitly separates itself from create_dns_record/delete_dns_record via 'existing'. It also names the sibling that supplies the required identifier, so an agent knows exactly what tool feeds this one.

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 pre-call guidance: obtain the `id` from list_dns_records, and note that only supplied fields are modified, which tells the agent to send a minimal patch rather than a full record. It stops short of explicit when-not-to-use guidance (e.g., use delete_dns_record to remove, create_dns_record for new records).

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, idempotentHint=true and readOnlyHint=false; the description adds genuinely useful detail beyond that by warning that fwd_addresses replaces the entire list rather than appending, and that an interactive confirmation may occur. It stops short of saying whether omitted fields are preserved and how to clear a comment.

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 replacement semantics and the destructive list-overwrite warning before the confirmation caveat. 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?

An output schema exists so return values need no explanation, and the destructive overwrite is flagged. However, for a destructive mutation with an optional-field design, the description omits how partial updates behave and how to clear or leave a field unchanged, which an agent needs before calling it.

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

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

Schema coverage is 75% and the schema already describes fwd_addresses as the 'New full list of destination addresses', so the description's replacement note is largely redundant with it. The description adds nothing about the comment parameter (whether an empty value clears it) or about address/vserver identifying the target forwarder.

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: replacing the destination list and/or comment of an existing e-mail forwarder. The 'update/replace existing' framing separates it from create_mail_forwarder and delete_mail_forwarder in the sibling list, though no sibling is named 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?

Implies usage (modify an existing forwarder rather than create one) and notes that a confirmation prompt may appear, but gives no explicit when-to-use vs. create_mail_forwarder guidance, no preconditions (must the forwarder already exist?), and no statement about what happens if a field is omitted.

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 destructive/openWorld annotations, the description discloses the confirmation prompt, what that prompt displays (method, path, body), that responses are always arrays, and that some endpoints incur real charges such as domain renewals and cloud orders. These are exactly the side-effect details an agent cannot infer from the structured fields.

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?

Front-loaded with the core routing statement and the prerequisite describe_endpoint step, with no filler sentences. The parenthetical enumeration of covered resource types is long but earns its place by helping an agent recognize whether its target is in scope.

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 open-world, destructive, 8-parameter generic client, the description covers routing, prerequisite discovery, path construction, response shape and monetary risk. Because an output schema exists, it correctly omits return-value documentation and spends its length on the hazards instead.

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%, and the description adds the base URL that `path` is relative to plus a concrete path example, and clarifies that `body` is an object except for the renew endpoint where it is an array. Pagination and query parameters are left entirely to the schema, which already documents them, so the baseline 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 (call any ZoneID API v2 endpoint) and immediately scopes it against the dedicated tools it is not meant to replace, listing concrete example domains such as cron, SSH keys and Redis. An agent can tell from the text alone that this is the generic escape hatch rather than one of the typed siblings.

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

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

It explicitly states the selection rule ('for everything the dedicated tools don't cover') and prescribes the workflow ordering by requiring describe_endpoint before body construction. It also distinguishes methods behaviourally: GET/OPTIONS run directly, POST/PUT/DELETE trigger confirmation, so the agent knows the cost of choosing each method.

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