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

Annotations indicate mutation (readOnlyHint=false) but not destructive (destructiveHint=false). The description adds no behavioral details beyond 'add', such as whether the operation is idempotent, whether it requires specific permissions, or what side effects occur.

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, clear sentence that conveys the core purpose without extraneous words. It could be slightly expanded to include key behavioral notes, but 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?

The description lacks details on return values (no output schema), error conditions, or examples. For a complex tool with nested objects, this is insufficient for an agent to fully understand the outcome.

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

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

Schema description coverage is 100%, so the parameters are well-documented in the schema. The description adds minimal extra meaning (e.g., 'port listener with forwarding rules') but does not enhance understanding beyond the schema.

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

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

The description clearly states 'Add a service (port listener with forwarding rules) to a load balancer,' using a specific verb and resource. It distinguishes from sibling tools like 'hetzner_delete_lb_service' and 'hetzner_create_load_balancer', though it does not explicitly differentiate from 'hetzner_update_lb_service'.

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

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

The description provides no guidance on when to use this tool versus alternatives, no prerequisites (e.g., load balancer must exist), and no context on idempotency or ordering.

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

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

Beyond annotations (readOnlyHint=false, openWorldHint=true), the description adds no behavioral details such as idempotency, side effects of adding an existing target, or mutation behavior. It does not contradict annotations but provides minimal additional transparency.

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

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

A single, well-structured sentence that is front-loaded and precisely conveys the tool's function with no wasted words.

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

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

While the schema fully documents parameters, there is no output schema or description of return values. For a moderately complex tool with nested objects, the description is complete regarding input but lacks context on what happens after adding a target (e.g., success/failure indications).

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 all parameters. The description only lists target types parenthetically, adding no additional semantic meaning beyond what is in the schema. Baseline 3 is appropriate.

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

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

The description clearly states the verb 'Add', the resource 'a target (server, label selector, or IP)', and the context 'to a load balancer'. It effectively distinguishes from sibling tools like 'hetzner_add_lb_service' which adds a service to a load balancer.

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

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

No guidance on when to use this tool versus alternatives or prerequisites (e.g., the load balancer must exist). With many sibling tools, this lack of context could lead to incorrect tool selection.

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

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

Annotations already indicate non-readOnly (modifying) and non-destructive. The description confirms the adding behavior but adds no extra transparency about side effects, error conditions, or the requirement for the network to exist. It is adequate given the annotations.

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

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

The description is a single, front-loaded sentence: 'Add a route to an existing network.' No wasted words; it gets straight to the action.

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

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

Given no output schema, the description does not hint at return values or side effects. It also does not mention that the network must exist or what happens if the route conflicts. It is minimally complete for a simple add operation but could be improved.

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 parameter descriptions like 'Destination network of the route' and 'Gateway for the route'. The tool description does not add additional meaning beyond these, and the schema descriptions themselves are somewhat vague (e.g., lacking format constraints). Baseline score of 3 applies.

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

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

The description clearly states the verb 'Add' and the resource 'route', and specifies the context 'to an existing network'. It distinguishes from sibling tools like 'delete_route' or 'add_subnet', but could be more explicit that the network is identified by the 'id' parameter.

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

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

No guidance is provided on when to use this tool versus alternatives, such as checking network existence or comparing with 'add_subnet' or 'delete_route'. The description does not mention prerequisites or typical use cases.

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 indicate readOnlyHint=false (mutation) and destructiveHint=false. The description adds a key behavioral constraint (server must be powered off), which is valuable beyond annotations. It does not detail error handling or reversibility, but the precondition is significant.

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

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

The description is two sentences, no redundant information. It is front-loaded with the purpose immediately, making it efficient and easy to parse.

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

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

Given the simple action (add server to placement group) with two required parameters and no output schema, the description covers the purpose and a critical precondition. It lacks a mention of the return value or side effects, but for a straightforward mutation, it is reasonably complete.

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

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

The input schema already provides clear descriptions for both parameters (Server ID, Placement group ID) with 100% coverage. The description does not add further parameter-level semantics beyond the schema, so it meets the baseline of 3.

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

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

The description clearly states the action: 'Add a server to a placement group.' It uses a specific verb and resource, and the sibling list includes distinct tools like 'remove_server_from_placement_group' and 'create_placement_group', so the purpose is well-defined.

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

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

The description explicitly states a prerequisite: 'The server must be powered off before it can be added.' This provides important usage context. However, it does not mention when to use this tool versus alternatives (e.g., 'remove' or 'create' tools), which would be helpful.

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

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

The description provides no behavioral details beyond the action. Annotations indicate non-readonly and non-destructive, but the description does not mention side effects, permissions, or state changes. For a creation tool, more context is expected.

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?

Extremely concise one-sentence description with no unnecessary words. It is appropriately sized for a simple tool.

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

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

The description adequately states the purpose, but given no output schema, it would be helpful to mention what the tool returns. It also assumes the agent knows 'existing network' context. Adequate but not fully complete.

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

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

Schema description coverage is 100%, so parameters are well-documented there. The tool description adds no additional meaning over the schema, but the schema already suffices, giving baseline 3.

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

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

The description clearly states the action (Add) and resource (subnet). However, it does not differentiate from sibling 'add' tools for other resources beyond the resource name.

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

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

No guidance on when to use this tool versus other network operations, such as 'delete_subnet' or 'attach_server_to_network'. No prerequisites or context provided.

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

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

Annotations already indicate this is a non-readonly, non-idempotent, non-destructive mutation. The description adds useful behavioral detail beyond those annotations: it confirms existing records are preserved and that TTL updates are optional. This is meaningful but not exhaustive, so a 4 is appropriate.

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

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

The description is two tight sentences with no filler. The core additive behavior is stated first, and the optional TTL behavior follows succinctly. Every phrase contributes to understanding the operation.

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

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

For a mutation tool with no output schema and a fully covered input schema, the description gives the essential behavioral context: append-only semantics and optional TTL adjustment. It stops short of discussing edge cases or failure modes, but the operation is simple enough that this is not a critical gap.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds little parameter-level meaning beyond what the schema already provides, though it does reinforce that 'records' are additions and that 'ttl' is an optional update. No substantial extra semantic value is contributed.

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

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

The description uses a specific verb ('Add'), names the resource ('existing RRSet'), and explicitly states the non-destructive scope ('without removing existing ones'). This clearly distinguishes it from related record-set tools like hetzner_set_zone_rrset_records or hetzner_update_zone_rrset_records.

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

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

The description provides clear context: use this when adding records to an existing RRSet while preserving current records, and optionally updating the TTL. It does not explicitly name alternatives or state when not to use it, but the additive wording gives enough practical guidance.

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

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

Annotations already indicate mutability (readOnlyHint=false) and non-destructiveness (destructiveHint=false). The description adds no additional context about behavioral traits such as idempotency, side effects, or permissions. It merely states the action without delving into what happens during application.

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

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

The description is a single, concise sentence that immediately conveys the tool's purpose. It is front-loaded with the essential action and resource, and contains no extraneous information.

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

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

For a simple action with two well-documented parameters, the description is adequate but lacks completeness. It does not explain what happens if a resource already has the firewall applied, or the behavior of label selectors. Given the absence of an output schema, more context would be helpful for an AI agent to anticipate results.

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 both parameters already described ('id' and 'apply_to'). The description adds no new semantics beyond what's in the schema, such as value formats or constraints (e.g., label selector syntax). It provides a high-level overview but no extra detail.

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

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

The description clearly states the action ('Apply'), the resource ('firewall'), and the scope ('to one or more servers or label selectors'). It effectively distinguishes from siblings like 'hetzner_create_firewall' and 'hetzner_remove_firewall'.

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

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

The description implies usage when you have an existing firewall to assign, but it does not explicitly state when to use this tool vs alternatives, nor does it mention prerequisites or exclusions. For example, it doesn't clarify that the firewall must already exist or how it differs from 'hetzner_set_firewall_rules'.

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

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

Annotations already indicate it is not read-only, not destructive, not idempotent, and open-world. The description adds no additional behavioral context such as reversibility, side effects, or state requirements, so it does not exceed what annotations provide.

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

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

The description is extremely concise (one short sentence). While it conveys the core purpose, it lacks useful structure such as a second sentence on prerequisites or outcome. It could be more informative without being verbose.

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

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

Given the simple tool (2 required params, no output schema), the description is barely adequate. It misses details like return value, success/failure states, or elaboration on the location constraint. The location note is valuable but incomplete.

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

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

Schema description coverage is 100%, so the schema already documents both parameters. The description adds no extra meaning beyond the parameter names; baseline 3 is appropriate.

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

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

The description clearly states the action ('Assign'), the resource ('floating IP'), and the target ('server') with the important constraint ('in the same location'). This distinguishes it from siblings like 'hetzner_unassign_floating_ip' and other floating IP operations.

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

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

The description implies usage context with the location constraint but does not explicitly guide the agent on when to use this tool versus alternatives (e.g., 'hetzner_change_floating_ip_protection'). No prerequisites or conditions are mentioned.

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

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

The description only says 'Assign a primary IP to a server.' While annotations exist (readOnlyHint=false, etc.), the description adds no behavioral details about side effects, such as replacing an existing primary IP or impact on networking. OpenWorldHint is true but unexplained.

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

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

The description is extremely concise (one sentence) and front-loaded with the core purpose. It could benefit from slight expansion, but it is not verbose or wasteful.

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

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

Given the simplicity of the tool (3 required params, no output schema), the minimal description might be sufficient but lacks any context about constraints, typical use cases, or behavior when the IP is already assigned. It feels incomplete for an AI agent.

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

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

Schema coverage is 100%, and each parameter already has a clear description. The tool description adds no extra meaning beyond the schema, so baseline score of 3 is appropriate.

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

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

The description clearly states the action ('Assign') and resource ('primary IP' to a server). It distinguishes from sibling tools like 'hetzner_assign_floating_ip' (different resource) and 'hetzner_unassign_primary_ip' (opposite action).

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

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

The description gives no guidance on when to use this tool, prerequisites, or when not to use it. It does not mention alternatives or provide context for decision-making.

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

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

The description adds meaningful behavioral context beyond the annotations by stating the reboot requirement, which is not implied by the annotations (readOnlyHint=false, destructiveHint=false). This helps the agent understand the post-action behavior.

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

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

The description is extremely concise: two sentences with no wasted words. The first sentence states the action, and the second adds a critical condition. It is front-loaded and efficient.

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

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

Given the tool's simplicity, the description covers the essential action and the key behavioral requirement (reboot). No output schema exists, but the return value is straightforward. It is complete enough for an agent to understand the tool's behavior.

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

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

The input schema provides descriptions for both parameters (server_id, iso) and coverage is 100%. The description does not add additional parameter-specific details beyond the schema, so the baseline score of 3 is appropriate.

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

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

The title and description clearly state 'Attach an ISO image to a server,' with a specific verb and resource. The sibling tool hetzner_detach_iso provides a clear counterpart, making the purpose distinct and unambiguous.

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

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

The description provides a clear usage context: attaching an ISO and the critical requirement that the server must be rebooted to boot from it. It does not explicitly mention when not to use or list alternatives, but the sibling list shows related tools like hetzner_get_iso and hetzner_list_isos for reference.

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

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

The description merely restates the action without disclosing behavioral traits such as idempotency, whether it overwrites existing network attachments, or any effects on the load balancer's public interface. Annotations indicate it is a write operation but not destructive, yet no additional context is given.

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

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

The description is a single sentence with no unnecessary words, front-loading the key action and resources.

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

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

The description lacks context about side effects (e.g., whether attaching replaces an existing network attachment, if the load balancer must be in a certain state) and does not reference the output or limitations. For a simple mutation tool with no output schema, more behavioral context is needed.

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

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

Schema descriptions already fully define all parameters (id, network, ip, ip_range) with clear meanings. The description adds no additional value beyond the schema, so baseline score of 3 applies.

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

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

The description clearly states the action (attach) and the resources involved (load balancer to a network). It is specific enough to distinguish from siblings like hetzner_detach_lb_from_network and hetzner_attach_server_to_network.

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

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

No guidance is provided on when to use this tool versus alternatives, prerequisites (e.g., load balancer and network must exist), or whether the load balancer must not already be attached to a network.

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 indicate this is a write operation (readOnlyHint=false) but not destructive. The description adds that optional IP assignments are possible, but it does not disclose behavioral traits like whether attaching affects running services, requires the server to be powered off, or if it overwrites existing network config. Annotations already cover safety, so the description adds minimal value.

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

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

The description is a single, well-structured sentence that conveys the core action and optional capabilities without extraneous information. It is front-loaded and to the point.

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

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

The description lacks important context for a mutation tool with no output schema. It does not explain return values, side effects, prerequisites (e.g., server and network must exist), or whether the operation is reversible. Given the complexity of network attachment and the lack of output schema, the description should provide more guidance.

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 descriptions for all 5 parameters. The description reiterates that ip, alias_ips, and ip_range are optional, aligning with the schema. This adds context but does not significantly enhance understanding beyond what the schema already provides. Baseline 3 is appropriate.

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

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

The description clearly states the action (attach a server to a private network) and optionally mentions assigning IPs, which distinguishes it from sibling tools like detach_server_from_network or attach_volume. The verb+resource+target structure is specific and unambiguous.

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

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

No usage guidelines are provided. The description does not mention when to use this tool versus alternatives (e.g., assign_floating_ip for public IPs, or attach_lb_to_network). It also does not specify prerequisites such as server and network existence or whether the server should be powered off.

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

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

Annotations already indicate mutation (readOnlyHint=false) and non-destructiveness (destructiveHint=false). The description adds the location constraint as a behavioral requirement, but does not disclose whether the volume must be unattached first, impact on server, or automount behavior. Moderate additional value.

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

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

The description is extremely concise with two sentences that front-load the action and essential constraint. No wasted words.

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

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

The description lacks explanation of automount behavior, expected result, prerequisites (e.g., volume not attached elsewhere), and error scenarios. For a tool with no output schema and multiple parameters, more context is needed.

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

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

Schema coverage is 100% with clear parameter descriptions. The tool description adds no new meaning beyond the schema, so baseline 3 is appropriate.

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

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

The description clearly states the action ('Attach a volume to a server') and adds a specific constraint ('server and volume must be in the same location'), making the purpose precise and distinguishable from related tools like hetzner_detach_volume.

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

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

The description provides a prerequisite (same location) but gives no guidance on when to use this tool versus alternatives such as hetzner_create_volume or hetzner_detach_volume. No when-not-to-use or alternative tool references.

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

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

Annotations already indicate the operation is destructive (destructiveHint=true) and idempotent (idempotentHint=true). The description adds context about overriding existing alias IPs, but does not disclose additional behaviors such as prerequisites, permissions, or error scenarios beyond what the annotations and schema provide.

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

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

The description is a single sentence of 18 words, front-loading the action and using imperative mood. No extraneous information, and it efficiently conveys the core functionality.

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

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

For a simple tool with three required parameters and no output schema, the description covers the essential operation. However, it does not mention return values or prerequisites (e.g., server must be attached to the network), which would improve completeness.

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

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

Schema description coverage is 100%, with each parameter having a clear description. The tool description does not add new semantic meaning beyond what the schema already conveys, so it meets the baseline of 3.

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

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

The description clearly states the action ('Replace'), the resource ('alias IPs that a server has on a private network'), and the effect ('overrides any existing alias IPs for that network'). This distinguishes it from other change tools in the sibling list, which target different resources like protection, DNS, or load balancer settings.

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

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

The description implies when to use (when you need to set the alias IPs for a server on a network, replacing existing ones). However, it does not explicitly state when not to use or mention alternatives like adding/removing individual IPs, which are not present in sibling tools but could be relevant.

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, idempotent=true, openWorld=true and destructive=false, so the safety profile is covered. The description adds the meaningful semantic that dns_ptr=null resets to the default, but omits any auth requirements, propagation delay, or error behavior for an invalid IP address.

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: the operation and its scope first, then the reset behavior. Nothing is wasted and the key constraint is front-loaded.

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

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

For a simple idempotent mutation with full schema coverage and complete annotations, the description covers the operation, scope, and reset path adequately. Only the lack of sibling routing keeps it from being 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?

All three parameters have 100% schema description coverage, so the schema already carries the semantics and the baseline is 3. The description's null-to-reset note duplicates what the dns_ptr schema field already states, adding no new parameter information.

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

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

States a specific verb (change) and resource (reverse DNS PTR entry) scoped to a server's public IPv4/IPv6 addresses, which differentiates it from the similarly-named lb/floating-IP/primary-IP rdns siblings. It does not name those alternatives explicitly, so it stops just 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 description gives the null-reset behavior, which is useful operational guidance, but never states when to use this tool versus the parallel rdns tools (change_lb_dns_ptr, change_floating_ip_rdns, change_primary_ip_rdns). Usage is implied by the resource scope rather than stated.

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

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

Annotations already indicate idempotentHint=true, readOnlyHint=false, destructiveHint=false. The description adds context that the tool enables or disables delete protection, which explains the idempotent nature (toggling) and confirms non-destructive behavior. This goes beyond annotations by specifying the protection type.

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

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

The description is a single, concise sentence (17 words) that is front-loaded with the action and resource. Every word contributes meaning without redundancy.

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

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

For a simple boolean toggle with no output schema, the description adequately covers the operation. It does not explain return values, but this is not expected given the tool's simplicity and the absence of an output schema.

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

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

The input schema has 100% coverage with descriptions for both parameters ('id' and 'delete'). The description does not add any new information about the parameters beyond what the schema already provides, hitting the baseline.

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

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

The description clearly states the verb 'enable or disable', the resource 'delete protection on a floating IP', and the purpose 'to guard against accidental destruction'. It distinguishes itself from sibling tools like hetzner_change_floating_ip_rdns and hetzner_update_floating_ip by specifying the exact aspect being changed.

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

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

The description provides clear context for when to use this tool: to toggle delete protection. While it does not explicitly state when not to use it or mention alternatives, the purpose is unambiguous and sufficient for decision-making given the sibling context.

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

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

Annotations already declare readOnlyHint=false, idempotentHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds the reset semantic for null, which is genuinely useful context, but says nothing about propagation delay, auth requirements, or what happens to the previous PTR 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 short sentences, front-loaded with the action and followed by the one non-obvious behavioral note. Nothing 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?

For a simple three-parameter mutation with full schema coverage and annotations, the definition covers the essentials plus the reset edge case. It is complete enough to call correctly, though the lack of sibling disambiguation is a minor gap.

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

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

Schema description coverage is 100%, so all three parameters are documented in the schema, including the null-to-reset behavior for dns_ptr. The description adds no syntax or format detail beyond what the schema already provides; 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 gives a specific verb+resource: changing the reverse DNS (PTR) entry for a floating IP. It is clearly distinct from unrelated siblings, but it does not explicitly differentiate itself from close siblings like hetzner_change_dns_ptr, hetzner_change_lb_dns_ptr, or hetzner_change_primary_ip_rdns.

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 states the reset behavior (set dns_ptr to null) but offers no when-to-use guidance, prerequisites, or routing between this and the several similarly named rDNS tools. The agent must infer scope from the name alone.

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

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

Annotations indicate idempotency and non-destructiveness. The description adds context about delete protection specifically and guarding against accidental destruction. It is consistent with annotations and provides useful behavioral context beyond the structured data.

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

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

The description is a single, efficient sentence of 17 words, front-loaded with key information, and contains no unnecessary details.

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

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

For a simple tool with two parameters and no output schema, the description is sufficient. It specifies the target (snapshot/backup image) and the action. Minor omission: could mention that protection only prevents deletion, not modifications, but overall adequately complete.

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

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

Schema coverage is 100%, so baseline 3 applies. The description does not add additional meaning beyond the schema; the boolean parameter 'delete' mapping is clear from the description but does not enhance schema semantics.

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

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

The description clearly states the tool enables or disables delete protection on snapshot/backup images, specifying the verb, resource, and purpose. It effectively distinguishes from sibling tools like hetzner_delete_image or hetzner_get_image.

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

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

The description implies usage (to protect images from deletion) but does not explicitly state when to use versus alternatives, nor does it mention prerequisites or when not to use.

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?

Adds behavioral context beyond annotations: confirms expansion-only operation and superset requirement. No contradictions with annotations (readOnlyHint=false, destructiveHint=false, 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?

Two sentences, no fluff, front-loaded with the primary action. Every sentence adds necessary information.

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

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

For a simple mutation tool with 2 parameters and no output schema, the description covers purpose, constraint, and behavior. Missing nothing critical.

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

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

Schema coverage is 100% with descriptions for both parameters. The description adds minimal extra meaning beyond what the schema already provides (e.g., 'superset' constraint is already in schema). Baseline 3 is appropriate.

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

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

The description uses a specific verb ('Expand') and resource ('IP range of an existing network'), clearly distinguishing it from sibling tools like create_network or update_network.

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?

Explicitly states the constraint that the new CIDR must contain the current range and that shrinking is not supported, providing clear usage context. However, it does not compare to alternatives or mention when not to use.

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

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

Annotations already indicate the tool is idempotent, non-destructive, and not read-only. The description adds no additional behavioral context beyond the annotation hints, such as whether changing the algorithm affects existing connections or requires a specific load balancer state.

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

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

The description is a single concise sentence with no redundant information. It is front-loaded and efficient.

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

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

Given the tool's simplicity and the presence of good annotations and schema coverage, the minimal description is adequate but lacks context about effects (e.g., impact on traffic) or prerequisites (e.g., load balancer status).

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

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

The input schema has 100% description coverage, with both parameters ('id' and 'type') well-documented. The description does not add any extra meaning beyond the schema; it simply restates the purpose.

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

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

The description clearly states the action ('Change') and the resource ('balancing algorithm of a load balancer'). It distinguishes from sibling tools like 'hetzner_change_lb_type' which modifies a different property (load balancer type).

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

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

No guidance is provided on when to use this tool versus alternatives (e.g., 'hetzner_update_load_balancer' or 'hetzner_change_lb_type'). The description does not mention any prerequisites or conditions for using this tool.

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, idempotent=true, and destructive=false, lowering the burden. The description adds the genuinely useful semantic that dns_ptr=null resets to the default, but does not state the effect on the action/response or any auth prerequisites.

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, front-loaded with the operation and followed by the key null-reset detail. 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?

A simple three-parameter mutation with fully documented schema and no output schema; the description covers what the agent needs to call it correctly. Only minor gaps around response/action behavior remain.

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 dns_ptr description in the schema already explains the null-reset behavior, so the description largely repeats structured data. Baseline 3 is appropriate when 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 (change) and resource (reverse DNS entry) scoped to a load balancer's public IP addresses, which distinguishes it from server/floating-IP rdns siblings. It is clear but does not explicitly name those alternatives.

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

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

The description gives no when-to-use context or contrast with the analogous hetzner_change_dns_ptr, hetzner_change_floating_ip_rdns, or hetzner_change_primary_ip_rdns tools. Usage must be inferred entirely from the name and resource mention.

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 indicate idempotentHint=true, but the description adds no behavioral context—e.g., potential downtime, billing changes, or validation rules. For a mutation tool, this is insufficient.

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

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

The description is a single sentence that directly conveys the purpose without redundancy. It is front-loaded and efficient, though it sacrifices detail.

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

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

With no output schema and only two params, the description should cover typical usage context—like verifying type availability or handling errors—but fails to do so. The tool may be usable but the description leaves 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 coverage is 100% and already explains both parameters ('Resource ID' and 'New load balancer type name or ID'). The description adds no additional meaning beyond the schema, meriting the baseline score.

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

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

The description uses a specific verb 'change' and clearly identifies the resource as 'type (plan) of a load balancer.' It is distinct from sibling tools like change_lb_algorithm or change_load_balancer_protection, which target different aspects.

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

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

No guidance is provided on when to use this tool versus alternatives, such as when to upgrade vs. downgrade, or prerequisites like checking available types via hetzner_list_lb_types. The description lacks context about use cases.

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

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

Annotations already indicate idempotent and non-destructive behavior. The description adds minimal context ('guard against accidental destruction') beyond what the schema and annotations provide. It does not detail side effects or permission requirements.

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

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

The description is a single clear sentence with no extraneous words. It is front-loaded and 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?

For a simple toggle tool, the description, combined with the schema and annotations, provides sufficient information for an agent to understand and invoke the tool correctly. It covers the essential purpose and behavior.

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

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

Schema coverage is 100%, with both parameters described. The description does not add new meaning to the parameters beyond the schema. It could have elaborated on the default behavior when 'delete' is not provided.

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

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

The description clearly states it enables or disables delete protection on a load balancer, specifying both the action and the resource. It distinguishes from sibling protection tools for other resources like floating IP, server, etc.

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

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

The description implies usage for protecting a load balancer from deletion but does not explicitly state when to use this tool versus other protection tools or provide any prerequisites. There is no guidance on when not to use it.

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

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

Annotations already declare write (readOnlyHint=false), non-destructive (destructiveHint=false), and idempotent (idempotentHint=true) behavior. Description adds that it guards against accidental destruction, which aligns with annotations. No additional behavioral details like side effects or required permissions.

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

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

Single sentence of 14 words, directly conveying purpose and effect. No filler, front-loaded with action and resource.

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

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

Given it's a simple toggle with no output schema and good annotations, the description is mostly complete. It could mention that the network must already exist, but this is implied by the resource type.

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 clear descriptions for both parameters (id: Network ID, delete: If true prevents deletion). Description does not add any new meaning beyond the schema; it simply summarizes the boolean parameter.

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

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

Description clearly states the tool enables or disables delete protection on a network, using specific verb (enable/disable) and resource (network protection). It distinguishes from sibling tools by focusing on network protection, matching the naming pattern of other protection tools like hetzner_change_server_protection.

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

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

No guidance on when to use this tool versus alternatives like other protection tools or manual deletion prevention. No mention of prerequisites (e.g., network must exist) or context where toggling protection is appropriate.

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

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

Annotations already provide key behavioral hints (idempotent, not destructive, not readonly). The description adds minimal extra context ('guard against accidental destruction') but doesn't elaborate on side effects or idempotency implications.

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

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

The description is a single concise sentence that efficiently conveys the tool's purpose without any unnecessary words.

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

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

For a simple tool with two well-described parameters and robust annotations, the description provides sufficient context. It covers the essential purpose and benefit, though it could optionally mention the effect of setting delete to false.

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?

Both parameters are fully described in the input schema with clear descriptions. The tool description adds no additional parameter meaning beyond that.

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

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

The description clearly states the tool's function: enable or disable delete protection on a primary IP. It uses specific verbs and resource type, and the name distinguishes it from many similar protection tools for other Hetzner resources.

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

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

The description implies use when wanting to guard against accidental deletion but lacks explicit guidance on when not to use it or alternatives. Given the sibling list, the purpose is clear, but no comparative context is provided.

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

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

Annotations already declare readOnlyHint=false, idempotentHint=true, destructiveHint=false and openWorldHint=true, covering the safety/idempotency profile. The description adds one genuinely useful behavioral detail — passing null clears the PTR record — but says nothing about permissions, propagation/delay, or what happens to the pre-existing record beyond the reset hint.

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, and the core action is front-loaded before the reset caveat. Appropriate size for a simple mutation tool.

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

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

Given existing annotations, a fully documented 3-parameter schema, and no output schema, the description is adequate to invoke the tool correctly. It falls short only on sibling disambiguation (three other change-*_dns/rdns tools exist) and on failure/permission context.

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

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

Schema description coverage is 100%; the schema already documents id, ip, and dns_ptr, including 'or null to reset'. The description's null-reset sentence is therefore a restatement rather than added meaning, so the baseline 3 applies.

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

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

States a specific verb (change) and resource (reverse DNS entry for a primary IP), which is clear on its own. However, the sibling list contains near-identical tools (hetzner_change_dns_ptr, hetzner_change_floating_ip_rdns, hetzner_change_lb_dns_ptr), and the description never explicitly contrasts itself against them beyond the 'primary IP' scope phrase.

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, no prerequisites (e.g. IP must be assigned), and no routing away from the sibling rdns/dns_ptr tools. The only actionable hint is the reset condition, which is a how-to rather than a usage guideline.

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

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

The description adds little behavioral context beyond the annotations. Annotations already indicate idempotent and non-destructive behavior, but the description does not disclose any additional traits like prerequisites or side effects.

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

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

The description is a single efficient sentence with no wasted words, front-loading the key purpose. It is appropriately concise.

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

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

Given the simplicity of the tool and full schema coverage, the description is largely complete. It states the purpose clearly, though it could mention that the server must exist.

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

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

Schema description coverage is 100%, so the baseline is 3. The description briefly summarizes the boolean parameters (delete and rebuild) but does not add meaning beyond what the schema already provides.

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

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

The description clearly states the tool enables or disables delete and rebuild protection on a server, using a specific verb and resource. It distinguishes from sibling protection tools by specifically mentioning 'server'.

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

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

The description implies usage for protecting servers, but does not provide explicit guidance on when to use this tool versus alternatives (e.g., other change_X_protection tools). No when-not-to-use or exclusion criteria 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 indicate non-destructive, idempotent behavior. The description adds rationale ('guard against accidental destruction') but lacks details on idempotency effects or prerequisites.

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?

Single concise sentence that immediately conveys the tool's action. No extraneous 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?

Adequately describes the tool for its simplicity, though it could mention that the 'delete' parameter is optional (not required). Overall sufficient for a protection toggle.

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% for both parameters. The description does not add semantic value beyond what the schema provides.

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

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

The description specifies a clear verb ('Enable or disable delete protection') and resource ('Storage Box'), and is distinct from sibling tools like change_floating_ip_protection.

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

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

The description implies use when toggling delete protection but does not explicitly state when to use or avoid this tool over 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 idempotentHint=true, openWorldHint=true, and non-destructive. The description adds no further behavioral context (e.g., whether existing files are moved). It is adequate but not enhanced.

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?

Single sentence, directly states the action and resource. No redundant words, well-structured.

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

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

For a simple change operation with full schema coverage, the description covers the basics. However, it lacks context about validation, immediacy of the change, or side effects, which would improve completeness.

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

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

Schema description coverage is 100% with clear descriptions for all three parameters, including an example for home_directory. Description adds no extra meaning beyond the schema.

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

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

Description clearly states the verb 'change' and the resource 'home directory a Storage Box subaccount is scoped to', exactly matching the tool name and distinguishing it from sibling tools like hetzner_update_storage_box_subaccount.

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

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

No explicit guidance on when to use this tool versus alternatives (e.g., hetzner_update_storage_box_subaccount). The usage is implied but lacks exclusions or prerequisites.

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

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

Annotations already indicate a mutation (readOnlyHint false) and non-destructive (destructiveHint false). The description adds the capacity constraint but does not disclose error handling, reversibility, or side effects beyond that.

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

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

Two sentences, no fluff, front-loaded with the core action. Every part earns its place.

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

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

Adequate for a simple mutation with 2 params and no output schema. However, it lacks details on return values, potential errors, and whether the operation is reversible. The capacity constraint is helpful but could be expanded.

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

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

Schema coverage is 100%, so the schema already documents both parameters. The description adds the capacity constraint for storage_box_type, but does not explain how to find available types or how the condition is validated.

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

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

The description clearly states it changes the type/capacity tier of a Storage Box, with a constraint on capacity. It distinguishes from get/list tools but not from hetzner_update_storage_box, which might also modify type.

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

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

No guidance on when to use this tool versus alternatives like hetzner_update_storage_box or when not to use it. No prerequisites mentioned, such as checking current usage capacity.

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 indicate readOnlyHint=false and destructiveHint=false, and idempotentHint=true. The description adds that the tool enables/disables delete protection, which is clear. No contradictions. It adequately discloses the mutation behavior beyond annotations.

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

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

A single sentence of 15 words, front-loaded with action and resource. Every word is necessary; no filler.

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

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

For a simple toggle tool with two parameters and no output schema, the description is sufficient. It explains the purpose and the effect. Minor gap: it doesn't state the volume ID is required, but that's in the schema.

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

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

Schema coverage is 100%, so baseline 3. The description ('delete protection') adds context to the 'delete' boolean parameter, but does not add technical details beyond what the schema provides.

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

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

The description clearly states the action (enable/disable delete protection) and resource (volume), with purpose to guard against accidental destruction. The title matches. Among sibling tools with similar 'change_*_protection' patterns, it is distinct for volumes.

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

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

The description gives a use case (protection against accidental deletion) but does not contrast with other protection tools or provide when-not-to-use guidance. The context is implied via sibling tools, but explicit guidelines are missing.

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 indicate mutation (readOnlyHint=false) and idempotency, which the description supports by stating 'Replace'. It adds context about secondary zones and AXFR/IXFR, but does not disclose potential side effects or required permissions beyond what annotations provide.

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

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

Single sentence, 18 words, no redundancy. Essential information is front-loaded and 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?

For a simple two-parameter tool, the description adequately explains purpose and scope (secondary zone, AXFR/IXFR). It does not detail return values (no output schema) or error conditions, but is largely complete given tool 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?

Input schema covers 100% of parameters with descriptions. The description adds no additional meaning beyond schema, so baseline score of 3 applies.

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

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

The description uses the specific verb 'Replace' and clearly identifies the resource ('primary nameservers') and context ('secondary DNS zone for AXFR/IXFR transfers'), distinguishing it from sibling tools like 'hetzner_update_zone'.

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

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

No explicit guidance on when to use this tool versus alternatives, such as 'hetzner_update_zone' or 'hetzner_import_zonefile'. No prerequisites or limitations mentioned.

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

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

Annotations already indicate idempotent and non-destructive behavior. The description adds context about guarding against accidental destruction, which aligns with the idempotentHint. No contradictions.

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

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

A single, front-loaded sentence with no wasted words. Every word earns its place, making it highly efficient.

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

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

Given the simple two-parameter tool with full schema coverage and no output schema, the description provides sufficient context. It covers the purpose and effect, but could mention that the tool is idempotent or that protection can be toggled multiple times.

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 does not elaborate on parameters beyond the schema, which already provides adequate descriptions for 'id_or_name' and 'delete'.

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

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

The description clearly states the action (enable/disable delete protection) and the resource (DNS zone), distinguishing it from sibling protection tools like hetzner_change_floating_ip_protection or hetzner_change_server_protection.

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

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

The description implies usage for managing zone protection but lacks explicit guidance on when to use versus alternatives (e.g., hetzner_change_zone_rrset_protection) or prerequisites. The context is clear but no exclusions are mentioned.

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

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

Annotations already indicate this is mutating, non-destructive, and idempotent. The description adds the consequence that protection guards against accidental modification or deletion, which is useful but mostly reinforces what the tool's name and the `change` parameter already imply. No contradiction with annotations.

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

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

A single sentence that states the action, the resource, and the purpose with no wasted words. The key information is front-loaded and immediately actionable.

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 toggle operation with comprehensive parameter schemas and annotations covering the safety profile, the description is functionally complete. An agent can select the tool and invoke it correctly from the provided information. Minor missing piece is explicit guidance about how this differs from zone-level protection mutations.

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

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

Schema description coverage is 100%, so the schema already documents all four parameters, including the boolean `change` behavior and the id_or_name, name, and type fields. The description does not add meaning beyond the schema, so the baseline 3 applies.

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

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

The description clearly identifies the action ('Enable or disable change protection') and the resource ('on an RRSet'), making it obvious what the tool does. It does not explicitly distinguish itself from sibling protection tools such as hetzner_change_zone_protection, 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 phrase 'to guard against accidental modification or deletion' provides clear context for when this tool should be used. It does not explicitly mention alternatives or when not to use it, but the intended use case is clear for a resource-specific protection toggle.

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

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

Annotations already convey that this is a mutating, non-destructive, idempotent operation, so the description does not need to restate that. However, it adds no behavioral context beyond the null-fallback behavior, which is already in the schema description. There is no mention of propagation, permissions, or side effects on existing records.

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

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

The description is two sentences with no wasted words. It leads with the core action and then adds the key exception/nuance. This is an appropriately sized and well-structured description.

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

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

For a single-attribute mutation with complete schema coverage and helpful annotations, the description is sufficient. It captures the core behavior and the null special-case. It could be slightly richer about relationship to zone-level TTL or expected effects, but nothing critical is missing for correct invocation.

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

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

Schema description coverage is 100%, so every parameter is already documented. The description's 'ttl=null to fall back to the zone default TTL' repeats what the schema already says. The description adds no semantic value beyond the structured schema.

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

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

The description states a specific verb and resource: 'Change the TTL of an RRSet.' It also adds the meaningful null-fallback behavior, clarifying the scope of the operation. It does not explicitly contrast with the sibling change_zone_ttl, but the RRSet-specific focus makes the purpose clear.

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

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

The description implies this tool is for per-RRSet TTL changes, and the phrase 'zone default TTL' hints at a zone-level alternative. However, it does not explicitly say when to use this tool versus change_zone_ttl or other RRSet tools. The usage guidance is only implied, not stated.

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

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

The description adds value beyond annotations by specifying that the change only affects records that do not have an explicit TTL. This behavioral detail is not captured by the annotations, which already indicate idempotent and non-destructive traits. No contradictions found.

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

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

The description is a single, well-structured sentence that clearly conveys the tool's purpose. It is front-loaded and contains no unnecessary words.

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

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

For a simple mutation tool with two parameters and no output schema, the description adequately covers the purpose and key behavioral detail (only affects records without explicit TTL). It does not mention prerequisites or side effects, but these are largely inferable from context.

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

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

Schema coverage is 100%, so baseline is 3. The description does not add any additional meaning beyond the schema, which already describes both parameters adequately.

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

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

The description clearly states the verb 'Change' and the resource 'default TTL applied to records in a DNS zone'. It distinguishes from sibling tools like hetzner_change_zone_rrset_ttl by specifying 'default TTL' for the entire zone versus a specific record set.

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

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

The description provides no guidance on when to use this tool versus alternatives like hetzner_change_zone_rrset_ttl or other zone configuration tools. There is no mention of prerequisites or conditions.

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

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

Annotations already indicate readOnlyHint=false and openWorldHint=true. The description adds context about the two modes but does not disclose behavioral traits like idempotency, rate limits, or potential duplicates. It does not contradict annotations.

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

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

The description is a single sentence of 15 words, starting with the action verb. It is extremely concise and front-loaded, wasting no words.

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

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

Given the complexity (6 parameters, no output schema, open-world hint) and rich schema coverage, the description adds value by clarifying the two creation modes and conditional requirements. It does not mention related operations (e.g., update, retry) but is fairly complete for its purpose.

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

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

The schema has 100% parameter description coverage, so the baseline is 3. The description mentions 'PEM data' and 'domain names' but these are already detailed in the schema parameters. No additional parameter-level meaning is provided.

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

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

The description clearly states that the tool creates a certificate, specifying two distinct types: uploaded (PEM data) and managed (domain names). It uses a specific verb and resource, and distinguishes between sibling tools like hetzner_get_certificate and hetzner_delete_certificate.

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

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

The description implies when to use the tool (to create a certificate of either type) but does not provide exclusions or alternatives. It could mention that for retrieving existing certificates, use get_certificate, or for deleting, use delete_certificate, but it does not.

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

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

Annotations indicate a write operation (readOnlyHint=false) and nondestructive (destructiveHint=false). The description adds no extra behavioral details beyond the annotations, such as idempotency, side effects, or error conditions. With openWorldHint=true, the agent might expect unknown side effects, but the description doesn't clarify.

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

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

The description is a single concise sentence without redundancy. It gets the point across efficiently, but could be slightly more informative without becoming verbose.

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

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

Given the complexity (nested objects, 4 parameters, no output schema), the description is insufficient. It does not explain what the response contains, whether creation succeeds immediately, or any constraints like name uniqueness. For a creation tool, more context is expected.

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

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

Schema coverage is 100%, meaning every parameter has a description in the schema. The tool description merely echoes that rules and apply_to are optional, adding no new semantic nuance. Baseline 3 is appropriate.

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

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

Description states 'Create a new firewall with optional rules and resource assignments.' This clearly identifies the verb (create) and resource (firewall), and distinguishes from siblings like hetzner_apply_firewall (which applies existing firewalls) and hetzner_set_firewall_rules (which modifies rules).

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

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

No guidance is provided on when to use this tool versus alternatives such as hetzner_apply_firewall or hetzner_set_firewall_rules. The description lacks any prerequisites, exclusions, or context for choosing this action.

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

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

Annotations indicate the tool is not read-only, and the description confirms it creates a floating IP. However, it does not disclose additional behavioral traits like idempotency or side effects; the constraint is already implied by schema.

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

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

The description is a single sentence that is direct and contains no unnecessary words. It is front-loaded with the action and key constraint.

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 6 parameters, no output schema, and a simple description, the agent lacks information about return values or post-creation behavior. The description does not compensate for these 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 coverage is 100%, and the description does not add significant meaning beyond what is already in the schema. The constraint about home_location/server is mirrored in field descriptions.

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

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

The description clearly states 'Create a new floating IP' with a specific verb and resource. It distinguishes from siblings like hetzner_create_primary_ip by specifying the resource type.

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 mentions the key constraint 'Either home_location or server must be provided' but does not differentiate from alternative tools or provide when-to-use guidance beyond that.

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 indicate write operation (readOnlyHint=false), but no destructive or idempotent hints. The description does not disclose consequences like potential conflicts or limits. With no output schema, the agent lacks insight into return values.

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 of 8 words with zero wasted words. It is front-loaded and efficient, though it could benefit from slight expansion for context.

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

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

Despite high schema coverage, the description is too minimal for a creation tool with 4 parameters. It omits information about image types, labels, description, and return values, which an agent needs for correct invocation.

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

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

Schema coverage is 100%, so baseline is 3. The description does not add any meaning beyond what the schema already provides for parameters.

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

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

The description clearly states the action (create) and resource (image) and source (existing server). It is specific and distinguishes from sibling tools that create other resources like servers or volumes.

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

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

No guidance on when to use this tool versus alternatives, such as hetzner_enable_backup or when to choose between snapshot and backup types. The description lacks context for decision-making.

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

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

Annotations already indicate this is a write operation (readOnlyHint=false). The description adds no extra behavioral context beyond the obvious creation action. It doesn't disclose potential side effects, permission requirements, or what is returned.

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

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

The description is a single sentence with 16 words, front-loading the core purpose. No wasted words; every part contributes to understanding the tool's primary function.

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

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

Given the tool's complexity (10 parameters, nested objects, no output schema), the description is too brief. It lacks context on prerequisites, behavior when creating, or return values. The description does not adequately prepare the agent for the full scope of the tool's use.

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 descriptions for all parameters. The description only lists a few parameters generically ('type, location, and optional targets and services') without adding value beyond what the schema already provides. Baseline of 3 is appropriate.

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

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

The description explicitly states 'Create a new load balancer' with 'specified type, location, and optional targets and services,' which is a clear verb+resource. The word 'new' distinguishes it from sibling tools that add to existing load balancers.

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

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

The description provides no guidance on when to use this tool versus alternatives like hetzner_add_lb_service or hetzner_add_lb_target. It does not mention prerequisites or typical workflow context.

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

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

Annotations already declare this is a non-readonly, non-idempotent, non-destructive write with open-world effects. The description adds only that subnets/routes are optional, without disclosing auth requirements, rate limits, or what the creation response contains. With annotations carrying the safety profile, this modest addition is a 3.

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

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

A single front-loaded sentence with no filler; the core verb and resource come first. It is efficient, though it does not use its brevity budget to add usage or behavioral context.

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

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

For a 6-parameter create tool with nested objects and no output schema, the description covers what is built but omits when to use it versus the network mutation siblings. Annotations handle the safety profile, so the definition is minimally viable rather than complete.

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

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

Schema description coverage is 100%, so every parameter is already documented in the schema. The description only restates the IP range and optional subnets/routes without adding format or constraint detail beyond the schema, so the baseline 3 applies.

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

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

The description states a specific verb and resource ('Create a new network') and enumerates the created components (IP range, subnets, routes), so an agent can distinguish it from network siblings like get/update/delete. However, it does not explicitly name those alternatives to differentiate.

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, and no reference to alternative tools such as hetzner_add_subnet or hetzner_add_route for extending an existing network. The agent must infer all routing decisions.

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

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

Annotations already indicate a write operation (readOnlyHint=false) and non-destructive nature (destructiveHint=false). The description adds minimal behavioral context beyond stating the creation action; it does not disclose permissions, idempotency (idempotentHint=false), or side effects.

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

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

The description is a single sentence of 11 words, efficiently conveying the core purpose without fluff. It is well-structured and front-loaded with the key action and resource.

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

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

For a creation tool with no output schema, the description is minimally adequate. However, it lacks contextual completeness by not explaining the role of placement groups in server distribution, that creation is a prerequisite for adding servers, or that only 'spread' type is available. An AI agent might need more context to use it appropriately.

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

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

The input schema has 100% parameter description coverage, so the schema already explains each parameter. The description does not add further meaning or context, such as explaining the effect of the 'spread' type or the purpose of labels, beyond what the schema provides.

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

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

The description clearly states the action ('Create') and the resource ('placement group') and provides a brief purpose ('control server distribution across hosts'). This distinguishes it from sibling tools like hetzner_add_server_to_placement_group and hetzner_update_placement_group.

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

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

The description offers no guidance on when to use this tool versus alternatives such as adding servers to an existing group or updating a group. It does not mention prerequisites, appropriateness of the 'spread' type, or scenarios where creation is needed.

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

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

Annotations already indicate a non-read-only, non-idempotent operation, and the description aligns with them without contradiction. However, it adds little behavioral detail beyond 'new' creation, such as billing implications, the create-and-assign behavior enabled by assignee_id, or the assignee_type default transition.

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

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

The description is a single, front-loaded sentence with no filler. It immediately communicates the core action and the most relevant parameter categories.

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 7-parameter create operation with no output schema, the description is somewhat thin on its own, but the schema carries most of the parameter detail. Missing context includes the create-and-assign option via assignee_id and the future default change for assignee_type, both of which are only present in 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 the description does not need to compensate. It mentions type, location, and assignee_type, but these are already described in the schema; it adds no significant meaning beyond what the input schema provides.

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

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

The description clearly states the action ('Create') and the resource ('a new primary IP'), while noting the key distinguishing parameters (type, optional location, optional assignee type). This makes it easy to differentiate from sibling tools like hetzner_create_floating_ip or hetzner_update_primary_ip.

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

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

There is no guidance about when to use this tool versus alternatives such as assign_primary_IP or update_primary_IP. The description does not mention conditions, prerequisites, or exclusions, so the agent must infer usage solely from the word 'Create' and 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 readOnlyHint=false, idempotentHint=false, and openWorldHint=true, so the mutation and non-idempotency profile is covered by structured data. The description adds essentially nothing behavioral - no note about cost/billing, that creation is asynchronous and returns an action, or that calling it twice creates duplicate servers.

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. It is appropriately terse, though that brevity comes at the cost of substance rather than being purely 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?

For a 14-parameter create operation with nested objects and no output schema, this one-line description is thin. It omits cost implications, the async/action-based return, and any preconditions, leaving the agent to infer almost everything beyond what the schema and annotations supply.

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 14 parameters (including nested public_net and firewalls) are already documented in the schema. The description merely gestures at 'type, image, and configuration options' without adding format or semantics beyond what the schema provides, 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 ('Create a new server') and names the three key inputs (type, image, configuration options). It is clearly distinguishable from siblings like hetzner_delete_server, hetzner_update_server, and hetzner_rebuild_server, 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?

There is no guidance on when to use this versus alternatives such as hetzner_rebuild_server or hetzner_resize_server, and no mention of prerequisites (valid server_type/image, quotas, billing). The description only says what the tool does, not when to reach for it.

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

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

Annotations indicate readOnlyHint=false, destructiveHint=false, idempotentHint=false, and the description states 'Add', which is consistent. However, the description adds no extra behavioral context beyond what annotations already provide, such as potential idempotency or side effects.

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

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

The description is a single concise sentence that front-loads the action and purpose. Every word earns its place, with no wasted or redundant phrasing.

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

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

The description explains the core function but lacks details like return value (no output schema), validation of the public key, or potential constraints. Given the tool's simplicity, the description is adequate but not comprehensive.

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

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

Input schema covers 100% of parameters with descriptions. The tool description adds no additional meaning beyond the schema, relying on the schema's parameter descriptions. With high schema coverage, baseline is 3, and no extra value is added from 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 clearly states the verb (Add), resource (SSH public key), and purpose (for use when creating servers). It distinguishes from sibling tools like list, get, update, and delete SSH keys, making the tool's function 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 does not explicitly mention when to use this tool versus alternatives, nor does it provide exclusions or prerequisites. While the context implies it's for creation, the lack of guidance on when to prefer this tool over other SSH-key-related actions is a gap.

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 indicate a non-read-only action, and the description adds the behavioral trait 'Billing applies for the provisioned resource'. This supplements the annotations, but does not disclose other potential side effects like failures or constraints.

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 concise sentences, front-loaded with the core purpose. No unnecessary words, and the billing note is efficiently placed.

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

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

The description covers the basic purpose and billing, but given the tool has 7 parameters, nested objects, and no output schema, it lacks information about the expected return value or any prerequisites/constraints. It is adequate but not comprehensive.

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

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

Schema coverage is 100%, so the schema itself documents all parameters. The description mentions 'location and type' but adds no new semantic meaning beyond what the schema provides, so the baseline score of 3 applies.

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

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

The description clearly states the action ('Create a new Storage Box'), the resource ('Storage Box'), and the key parameters ('in the given location and type'). This distinguishes it from sibling tools like update, delete, or get.

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

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

No guidance on when to use this tool versus alternatives such as 'hetzner_create_storage_box_snapshot' or 'hetzner_get_storage_box'. The description implies usage for creation but does not provide exclusions or alternative suggestions.

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

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

Annotations already indicate this is a non-read-only, non-destructive, non-idempotent operation. The description adds minimal additional context ('manual snapshot') but does not disclose potential costs, concurrency behavior, or whether overwriting exists. It does not contradict annotations.

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

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

The description is a single concise sentence that captures the essence. It is front-loaded with the main action and includes optional parameters. While very brief, it has no redundancy and earns its place.

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

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

Given that there is no output schema, the description could explain return values or behavior (e.g., returns snapshot object, creation time). It does not. However, the tool is simple and well within the context of sibling snapshot tools, making it functional but not fully complete.

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

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

Since schema description coverage is 100%, all parameters are described in the schema. The description repeats this ('optionally with a description and labels') without adding new semantic detail or clarifying usage beyond what the schema provides.

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

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

The description clearly states the action ('Create'), the resource ('manual snapshot of a Storage Box'), and optional parameters ('description and labels'). It distinguishes itself from sibling tools like hetzner_create_storage_box (creates the box itself) and hetzner_enable_storage_box_snapshot_plan (enables automatic snapshots).

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

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

The description does not explicitly state when to use this tool versus alternatives like creating automatic snapshots via plans. It only describes the action without providing usage context or exclusions. The usage is implied but not 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 indicate it is not read-only or destructive, and description confirms it creates a subaccount. However, it does not disclose potential side effects, authentication needs, or behavior under duplicates. Annotations partially cover safety, but description adds limited behavioral context.

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

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

The description is a single 14-word sentence that is entirely front-loaded and to the point. There is no unnecessary information, and every word contributes to understanding the tool's primary action.

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

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

Given the tool has 7 parameters, nested objects, and no output schema, the description is too brief. It does not describe the return value, confirm that the subaccount is created immediately, or address any potential responses. The agent lacks context on what to expect after invocation.

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

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

Schema coverage is 100%, so baseline is 3. The description reiterates the purpose of home_directory, password, and access_settings but does not add new meaning beyond the schema descriptions. It adds no novel parameter semantics.

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

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

The description clearly states the tool creates a subaccount on a Storage Box with scoping to a home directory, password, and access settings. It distinguishes from siblings like create_storage_box (creates the box itself) and update/delete subaccount tools.

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

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

The description provides no explicit guidance on when to use this tool vs alternatives, nor any when-not-to-use conditions. It does not mention prerequisite steps or exclusion criteria.

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

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

Annotations indicate this is a write, non-destructive, non-idempotent operation with open-world effects. The description adds a placement constraint but does not elaborate on side effects like cost, naming conflicts, or return behavior. It offers some value beyond annotations but remains minimal.

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

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

The description is extremely concise: two short sentences. The first sentence states the purpose, the second adds a crucial usage constraint. No wasted words; it earns its place.

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

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

Given the 7 parameters and no output schema, the description is partly complete. It covers the essential placement rule but omits important context: creating with 'server' attaches the volume, cost implications, and that the volume is initially unattached if only location is given. Schema coverage helps but the description could better round out the context.

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

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

All 7 parameters are fully described in the schema (100% coverage), so the baseline is 3. The description does not add any parameter-specific details beyond what's already in the schema, such as format enum or labels structure. It mentions the 'location' vs 'server' choice but not the semantics of each parameter.

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

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

The description clearly states 'Create a new volume', specifying the verb (create) and resource (volume). It adds a key placement constraint ('Either location or server must be provided'), which distinguishes this from sibling tools like attach, list, delete, or update operations.

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

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

The description provides a constraint on parameter usage ('Either location or server must be provided'), but lacks explicit guidance on when to use this tool versus alternatives (e.g., attaching an existing volume, or using a different creation tool). Usage is implied but not differentiated.

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

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

Description accurately states the action without contradicting annotations. Annotations indicate readOnlyHint=false, so creating is expected, but no further behavioral details like idempotency or side effects are provided. With minimal annotations, the description could offer more but is adequate.

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

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

A single sentence with only necessary words. Very concise and front-loaded with the core action.

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

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

Despite having 7 parameters, nested objects, and no output schema, the description is very brief. It does not explain the mutual exclusivity of rrsets and zonefile, the response structure, or any post-creation behavior. This is insufficient for such a complex tool.

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

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

Schema coverage is 100%, so parameters are well-documented. The description adds a note about primary nameservers being required for secondary zones, which is not in the schema, but overall adds little new meaning beyond the schema.

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

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

Description clearly states the verb 'Create', the resource 'DNS zone', and the modes 'primary or secondary'. It distinguishes from siblings like 'hetzner_create_zone_rrset' and 'hetzner_import_zonefile' by specifying the scope and optional parameters.

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?

Description mentions optional parameters and the conditional requirement for primary nameservers for secondary zones, but does not explicitly compare to alternatives like import_zonefile or when to use each mode. Still, it provides clear context for usage.

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

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

Annotations already indicate it is not read-only, not destructive, not idempotent, and open-world. The description adds no additional behavioral context such as authentication needs, error conditions, or idempotency details.

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

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

The description is a single concise sentence that front-loads the purpose. It is efficient, but could benefit from slightly more context without becoming verbose.

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

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

Given the complexity of creating an RRSet (zone requirement, record formatting, TTL implications), the description is too minimal. It lacks context on prerequisites, record structure, and response behavior (no output schema).

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

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

With 100% schema description coverage, the schema already documents parameters well. The description does not add further meaning beyond the schema, so baseline score of 3 is appropriate.

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

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

The description clearly states it creates a new RRSet inside a DNS zone. However, it does not explicitly differentiate from siblings like hetzner_add_zone_rrset_records or hetzner_set_zone_rrset_records, which modify existing RRSets.

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

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

No guidance is provided on when to use this tool vs alternatives. It does not mention prerequisites (zone must exist), potential conflicts (duplicate name/type), or related tools for listing zones or adding 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 indicate destructive nature, but the description adds the constraint that the certificate must not be in use, which is beyond annotation coverage. No contradictions.

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

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

Two concise sentences, front-loaded, no filler. Every sentence adds value.

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

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

For a simple tool with one parameter and no output schema, the description covers purpose and a key constraint. Could briefly mention error behavior if certificate is in use, but it's nearly complete.

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

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

The description does not add meaning beyond the schema's description for the id parameter, which already covers it fully. Baseline 3 applies due to 100% schema coverage.

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

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

Clearly states the verb 'Delete' and resource 'certificate'. The constraint about not being in use by load balancers adds specificity and distinguishes it from other delete 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?

Provides a prerequisite (certificate must not be in use by load balancer) but does not explicitly state when to use vs alternatives like update or get, nor when not to use it.

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

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

Adds the key precondition that the firewall must be detached before deletion, which is valuable beyond the destructiveHint annotation. No other side effects mentioned, but the prerequisite is critical.

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

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

Two sentences, no wasted words. Immediately states action then precondition – efficient and front-loaded.

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

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

For a simple delete tool with one parameter, the description covers the crucial prerequisite. Lacks details like error behavior if still attached, but adequate given annotations and schema richness.

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

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

Schema description coverage is 100% (id described as 'Resource ID'). The description adds no further parameter guidance, so baseline score of 3 applies.

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

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

Clearly states 'Delete a firewall' – specific verb and resource. Distinguishes from siblings like hetzner_remove_firewall by the action (delete vs remove).

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 a prerequisite: firewall must be removed from all resources first. However, does not explicitly compare to hetzner_remove_firewall or indicate when to use delete versus remove.

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