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

Annotations already indicate a non-read-only, non-idempotent operation. The description adds useful behavioral context: it returns the new server details including IP address and root password (if no SSH keys specified). However, it does not mention side effects like billing or provisioning time.

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 well-structured with required and optional sections, front-loaded with the primary purpose, and contains 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?

While the schema fully documents all 8 parameters, the description omits response_format and start_after_create from its optional list, giving an incomplete picture of invocable parameters. It otherwise covers key aspects like return details and parameter discovery.

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%, but the description goes beyond schema by giving concrete examples ('cx22', 'ubuntu-24.04', 'fsn1') and referencing list tools to discover valid options. This significantly helps correct invocation.

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 starts with 'Create a new server,' which is a specific verb+resource. It clearly differentiates from sibling operations like reboot, power on/off, and delete. The scope of creating a server is unambiguous.

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

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

The description provides clear usage context by listing required vs optional parameters and pointing to sibling list tools (e.g., hetzner_list_server_types) for valid values. It does not explicitly state when not to use the tool, but for a create operation the guidance is sufficient.

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

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

Annotations already indicate non-read-only (readOnlyHint=false) and non-destructive (destructiveHint=false), so the description need not repeat those. It adds useful context about usage (keys are used when creating servers) and provides input format hints, but it does not disclose behavior such as duplicate key handling, idempotency, or response characteristics. This is adequate but not rich.

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

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

The description is concise and front-loaded, stating the core action in the first sentence. The Args list is compact and directly useful, with no filler. Every sentence contributes to understanding the tool's purpose or parameters.

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

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

For a simple create tool with no output schema, the description explains the outcome (key added, usable for servers) and core parameters. However, it omits the optional 'response_format' parameter that appears in the schema, which is a minor gap. Overall, it is sufficiently complete for an agent to invoke the tool correctly.

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

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

Schema coverage is 100%, so descriptions exist for all parameters. The description adds value beyond the schema by providing concrete examples for 'name' (e.g., 'my-laptop') and specifying that 'public_key' must start with formats like 'ssh-rsa' or 'ssh-ed25519'. It also clarifies that 'labels' is optional, which reinforces 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 uses a specific verb ('Add') and resource ('SSH public key to the project'), clearly distinguishing this create operation from sibling tools like hetzner_list_ssh_keys, hetzner_get_ssh_key, and hetzner_delete_ssh_key. It also explains the purpose (enabling SSH access on servers), removing ambiguity.

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

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

The description clearly states when to use this tool: when adding an SSH key to enable SSH access on future servers. It does not explicitly list exclusions or alternative tools, but the purpose is clear enough that an agent would not confuse it with list, get, or delete operations.

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

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

Annotations already indicate destructiveHint=true and readOnlyHint=false, so the operation's destructive nature is known. The description adds meaningful context beyond that by explicitly stating the consequences: 'irreversible' and 'all data on the server will be lost.' This goes beyond the structured annotation and helps the agent appreciate the impact.

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

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

The description is extremely concise, using two short sentences and a warning emoji to convey the purpose and the critical irreversible consequence. Every word earns its place, and the warning is appropriately highlighted without unnecessary 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?

For a simple delete operation with a single well-described parameter and destructive annotations, the description is quite complete. It does not explain return values, but no output schema exists and the operation's outcome is predictable. It could have added context about server ID lookup or confirmation, but those are minor gaps.

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

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

The input schema fully describes the only parameter (id) with a clear description: 'The server ID to delete.' Schema coverage is 100%, so the description adds no extra parameter meaning, but none is needed. The baseline of 3 applies because the schema handles all parameter documentation.

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

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

The description clearly states the action ('Delete a server permanently') with a specific verb and resource, and it is distinct from sibling tools like power_on/off or reboot. The word 'permanently' reinforces finality and differentiates it from non-destructive 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 no explicit guidance on when to use this tool versus alternatives such as powering off or rebooting. The warning about data loss implies a final farewell scenario, but there is no direct statement like 'use this only when the server is no longer needed' or 'prefer power_off to preserve data.'

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

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

Annotations already mark destructiveHint=true and idempotentHint=true, and the description complements this by explaining the consequence of deletion on existing servers. This is valuable behavioral context that goes beyond the annotations.

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

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

Two short sentences with the main action first and a clarifying note second. 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 delete operation with one parameter, no output schema, and annotations providing safety hints, the description covers the essential behavior and the only significant edge case (existing servers remain unaffected).

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

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

The schema fully documents the single 'id' parameter with a clear description ('The SSH key ID to delete'), and the tool description does not add extra detail. This meets the baseline for high schema coverage.

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

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

The description uses the specific verb 'Delete' and resource 'SSH key', and clarifies scope as 'from the project'. It clearly distinguishes from sibling tools like hetzner_create_ssh_key and hetzner_delete_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?

It states the core action and adds an important usage caveat about not affecting existing servers, which helps the agent know when it's safe to delete. However, it does not explicitly compare with alternatives or say when not to use it, though sibling names make the scope clear.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the scope 'specific server' but no additional behavioral context like response details or pagination, which is acceptable given the strong 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 fully conveys the tool's purpose without any fluff. Every word earns its place.

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

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

For a simple read operation with comprehensive annotations and high schema coverage, the description is complete. No output schema exists, so the description need not explain return values. The tool is straightforward, and the description sufficiently covers its role.

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

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

Schema description coverage is 100%, with both parameters (id and response_format) described in the schema. The description adds no extra meaning beyond the schema, 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 tool's function: 'Get detailed information about a specific server.' This uses a specific verb (get), identifies the resource (server), and distinguishes from sibling tools like list_servers by emphasizing 'a specific 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 a single server by ID, which is clear from 'a specific server.' However, it does not explicitly name alternatives or state when not to use it, so it falls short of the explicit guidance seen in top-tier examples.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds nothing beyond the fact that it retrieves details; it doesn't disclose return format, pagination (not applicable), error behavior, or rate limits. Given the strong annotations, this is acceptable but not exceptional.

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

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

The description is a single sentence, front-loaded with the key facts, and contains zero redundant or filler text. It is optimally concise for the tool's purpose.

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

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

For a simple get-by-ID operation with rich annotations (readOnly, idempotent, non-destructive) and a fully documented schema, the description is nearly sufficient. It lacks a note about output format or links to sibling tools, but these are not critical for basic 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% (both 'id' and 'response_format' have descriptions). The description's 'by ID' aligns with the required id parameter but adds no extra meaning beyond the schema. Baseline 3 is appropriate.

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

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

The description clearly states a specific action ('Get details') on a specific resource ('specific SSH key') identified by ID. This distinguishes it from sibling tools like list_ssh_keys (which lists all keys) and create/delete 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 phrase 'by ID' implies this tool is used when a single SSH key is needed, and the sibling list tool implies the alternative for enumerating all keys. However, there is no explicit when-to-use or when-not-to-use guidance, no mention of prerequisites, and no explicit alternative naming.

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

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

Annotations already declare read-only/idempotent behavior. The description adds value by disclosing what the response contains (image name, OS flavor/version, architecture), which goes beyond the safe operation hint. It doesn't discuss pagination or rate limits, but for a list tool with no output schema, this is sufficient.

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

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

The description is front-loaded with the core purpose and remains concise. The bullet list adds useful detail without bloat. Minor redundancy between 'available OS images' and 'system images (operating systems)' prevents a perfect score.

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

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

For a read-only list operation with two optional, fully described parameters and no output schema, the description adequately covers purpose, output content, and usage context. The only gap is not explicitly mentioning that the tool can also list snapshots/backups/apps via the 'type' parameter, but the schema handles that.

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

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

Schema description coverage is 100% with both 'type' and 'response_format' fully documented. The description adds minimal new parameter meaning—only reinforcing that system images are the default focus. No additional syntax or format details beyond the schema.

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

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

The description states a specific action ('List available OS images') and resource ('for creating servers'), clearly distinguishing it from sibling tools like list_servers or list_locations. It also notes the tool's purpose in server creation workflow.

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

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

Provides clear usage context: 'Use this to find the right image when creating a new server.' While it doesn't mention when not to use it or name alternatives, the tool is unique among siblings for image listing, so exclusions are unnecessary.

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 read-only, idempotent, and non-destructive behavior, so the description only needs to add extra context. It adds that the tool returns all locations and describes the output fields, but does not disclose additional behavioral aspects like pagination or data freshness. This is moderate value beyond the annotations, so a 3 is appropriate.

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

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

The description is concise and well-structured: a brief opening statement, a bullet list of the output fields, and a one-sentence use case. Every sentence contributes meaning, with no redundancy or filler, 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?

For a simple list operation with no required parameters and no output schema, the description is complete: it defines the tool's scope, lists the returned fields, and gives a clear use case. The annotations cover safety, and the schema covers the only param, so nothing critical is missing.

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

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

The input schema covers the single parameter 'response_format' with a clear enum and description, achieving 100% schema coverage. The description does not mention parameters, but the schema fully documents them, so the baseline of 3 applies; no additional value is added, but none is necessary.

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 lists available datacenter locations, uses a specific verb ('List') and resource ('datacenter locations'), and distinguishes it from sibling list tools by focusing on locations. It also provides useful details about the returned fields (code, city, country, network zone), making the purpose unmistakable.

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 ('Use this to choose where to deploy your server'). It does not explicitly name alternatives or explain when not to use it, but the context is sufficient for typical selection among sibling list tools, earning a 4.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the list of returned fields, which is useful, but it does not mention pagination, rate limits, or any other behavioral caveats beyond what annotations provide.

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

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

The description is concise and front-loaded with a single clear sentence followed by a bulleted list of return fields. Every line adds value and there is no redundant text.

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

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

For a simple list tool with strong annotations and full schema coverage, the description adequately explains the purpose and lists the key return fields. It could mention pagination or response format details, but these are either implied or covered by the schema, so it is 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 input schema provides full descriptions for both parameters (label_selector and response_format) with 100% coverage, so the baseline is 3. The description does not add any additional parameter semantics beyond what the schema already includes.

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 'list' with a clear resource 'servers' and scope 'in the project', which clearly distinguishes it from sibling tools like 'hetzner_get_server' (single server) and 'hetzner_list_server_types' (different resource).

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

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

The description implies usage for listing all servers but does not explicitly mention when to use this versus alternatives like 'hetzner_get_server' for individual servers. No exclusions or when-not guidance is provided, making the guidance only implicit.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered. The description adds useful context about the returned data (CPU, memory, disk, pricing) but does not disclose additional behavioral traits such as pagination, authentication, or rate limits. It meets the baseline for a read-only listing tool with strong annotation coverage.

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 well-structured with a lead sentence, bullet points of returned fields, and a closing usage sentence. It is efficient, though the first sentence and the 'Returns information about...' sentence partially overlap, making it slightly redundant. Overall it is easy to scan and free of filler.

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

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

For a simple list tool with one optional parameter, no output schema, and rich annotations, the description adequately covers what the tool returns (name, CPU, memory, disk, pricing) and when to use it. It could mention output structure or lack of pagination, but 'List all available server types' implies a complete listing, and the provided details are sufficient for typical selection and invocation.

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

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

The input schema has 100% coverage: the single parameter 'response_format' is fully described with an enum ('markdown' or 'json') and a default value. The description does not add parameter-level detail, but the schema already carries the full burden, so a 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 uses the specific verb 'List' with the resource 'server types' and clarifies scope with '(instance sizes) with their specs and pricing.' It clearly distinguishes this from sibling tools like hetzner_list_servers, which lists actual servers, by focusing on available configurations rather than user-created 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 explicitly states the intended use case: 'Use this to find the right server type when creating a new server.' This provides clear context for when to invoke the tool. It does not explicitly name alternatives or exclusions, but the sibling list (hetzner_list_servers) and the phrase 'server types' make the distinction obvious.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is clear. The description adds that it returns all SSH public keys added to the project, clarifying scope and content. It does not describe pagination, ordering, or response structure, but for a simple list operation with rich annotations this is adequate.

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

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

The description is concise and front-loaded with the primary action, but it contains slight redundancy: the first and second sentences both say it lists all SSH keys. The third sentence about SSH key usage is useful context. Despite minor repetition, it is efficient and clear.

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

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

For a simple list operation with one optional parameter and no output schema, the description adequately conveys scope (all SSH keys), project context, and purpose. It could mention the return format or that it returns a list, but 'List all' implies a list, and the response_format parameter is documented 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% for the only parameter (response_format), which has a description and enum. The description does not add any parameter-specific details, but since the schema fully documents the parameter, the baseline of 3 is appropriate.

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

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

The description clearly states the tool lists all SSH keys in the project, using a specific verb ('list') and resource ('SSH keys') and scoping to 'the project'. This distinguishes it from sibling tools like listing server types or locations, and complements get_ssh_key for individual keys.

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

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

The description implies when to use this tool (when you need to see all SSH keys in the project) and provides context about SSH key usage for server authentication. However, it does not explicitly mention when to prefer this over alternatives like get_ssh_key, nor does it state any 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?

The description adds the hard-shutdown nature and compares it to 'pulling the power cord', effectively conveying the abrupt, potentially destructive behavior beyond the destructiveHint annotation. No contradiction with annotations.

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

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

Two concise sentences with the core action first and the advisory alternative second. No filler or redundant 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 single-parameter action with clear annotations, the description covers purpose, usage, and behavioral caveats sufficiently. No output schema is needed for this simple operation.

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

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

The schema fully describes the only parameter (id) with description and exclusiveMinimum, achieving 100% schema coverage. The tool description adds no additional parameter context, so the baseline of 3 applies.

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

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

The description clearly states 'Power off a server (hard shutdown)', using a specific verb and resource while distinguishing it from graceful shutdown and sibling tools like reboot or power-on.

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

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

It explicitly provides an alternative: 'For a graceful shutdown, SSH into the server and run shutdown.' This tells the agent when not to use this tool and clarifies it is for abrupt hard shutdowns.

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

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

Beyond the annotations, the description adds the key behavioral precondition that the server must be off. It does not describe error cases or what happens if the server is already on, but the idempotentHint annotation covers idempotency, so the description adds useful context without contradiction.

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

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

The description is a single, front-loaded sentence that states the action and condition with no filler. Every word earns its place.

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

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

For a simple tool with one parameter, strong annotations, and no output schema, the description is mostly complete. It could mention potential errors or return values, but these are not critical for a power-on operation.

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

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

The input schema provides a description for the only parameter (id: 'The server ID'), achieving 100% coverage. The tool description does not add any further meaning about the parameter, 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 description clearly identifies the action (power on), the resource (server), and the precondition (currently off). This distinguishes it from sibling tools like hetzner_power_off_server and hetzner_reboot_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 phrase 'that is currently off' implies it should be used when a server is stopped, providing implicit usage context. However, it does not explicitly mention alternatives or when not to use it, though the sibling list and description make it clear.

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

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

Annotations already indicate destructiveHint=true and readOnlyHint=false, but the description adds meaningful context: 'This is like pressing the reset button' conveys abruptness and potential for interrupted processes. This goes beyond the annotation flags, though it does not mention specific side effects like unsaved data loss, which would merit a 5.

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

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

Extremely concise: two short sentences that are front-loaded with the core purpose, followed by a clarifying analogy and an alternative instruction. Every sentence contributes value 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?

Given the tool's simplicity (one parameter, no output schema), the description fully covers purpose, behavior, and usage guidance. It even explains when not to use it. No important context is missing for an agent to invoke it correctly.

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

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

The schema fully documents the only parameter 'id' as 'The server ID' (100% coverage). The description does not add additional parameter semantics beyond what the schema already provides, 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?

States the action clearly: 'Reboot a server (hard reset).' This specifies the verb (reboot), resource (server), and clarifies the method (hard reset), distinguishing it from siblings like power_on_server and power_off_server. The analogy to pressing the reset button reinforces the distinction.

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

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

Explicitly provides an alternative: 'For a graceful reboot, SSH into the server and run reboot.' This tells the agent when to use this tool (hard reset needed) and when not to (graceful reboot preferred), effectively differentiating from other lifecycle tools.

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