hetzner-cloud

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

Annotations already flag destructiveHint=true, and the description usefully nuances this by noting that turning protection ON is safe while the tool can also turn it off (which is the destructive direction). It adds the underlying API endpoint but omits auth requirements and side effects of disabling protection on an already-protected server.

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

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

Two sentences, front-loaded with the action and resource, then safety context and endpoint. No filler and every sentence carries 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 mutation tool with no output schema and only a destructiveHint annotation, the description covers what is changed, which direction is safe, and the endpoint. It could do more on the consequences of disabling protection, but is largely 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% and each parameter is documented in the schema, so the baseline is 3. The description's phrase 'deletion and rebuild protection' loosely maps to the delete/rebuild booleans but adds no syntax or default-value detail beyond the schema.

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

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

States a specific verb (turn on/off) and resource (deletion and rebuild protection for a server), which cleanly distinguishes it from siblings like hetzner_shutdown_server or hetzner_enable_server_backup. An agent can identify the operation without opening the schema.

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

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

Offers directional context ('Turning protection ON is the safest write in this server') but never states when to use this tool versus alternatives, nor any prerequisites or when-not conditions. Usage is implied rather than 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?

The only annotation provided is destructiveHint=true, so the description meaningfully adds billing behavior ('Snapshots are billed for the space they use') and the underlying API operation. There is mild tension between the annotation's destructiveHint and the description calling the action 'safe', but 'safe' refers to risk mitigation rather than to read-only status, so this is not a contradiction; it also omits whether the operation is reversible or what happens to the returned image.

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

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

Two compact sentences with the action and the workflow rationale front-loaded, followed by the cost caveat and API endpoint. Every clause carries information; nothing is padding.

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

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

There is no output schema, and for a single-action tool the description covers what it does, why to call it, cost implications, and the API endpoint. It does not say how to track the resulting image/action (e.g. via hetzner_get_action or hetzner_list_images), which is a modest remaining gap.

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

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

Schema description coverage is 100% and the enum's snapshot/backup trade-off plus the label parameter are already documented in the schema. The description adds no parameter-level detail beyond the schema, so the baseline of 3 applies.

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

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

States a specific verb and resource: 'Create a snapshot image from a server's disk', which is clearly distinguishable from the listing/getter siblings and from the backup-toggle tools. It does not, however, explicitly contrast itself with hetzner_enable_server_backup or explain image vs. backup semantics, so sibling differentiation is only implicit.

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

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

Gives concrete usage context — 'the safe thing to do BEFORE a risky change' — which tells the agent when this tool belongs in a workflow. It stops short of naming alternatives or when-not conditions (e.g. use backups for scheduled protection instead of one-off snapshots), so it is clear context rather than full routing guidance.

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

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

Adds critical context the annotations do not: billing begins per-hour on boot, the exact parameter driving cost (server type), and where to learn prices. It also surfaces the credential consequence of omitting ssh_keys (root password emailed), which is genuinely operationally important for a provisioning call.

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

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

Three tight sentences with the highest-stakes fact (billing starts) front-loaded in caps, followed by prerequisites and the API endpoint. Nothing is wasted or buried.

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

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

Covers the preconditions, cost implications and credential behaviour needed to invoke it correctly. The only gap is the lack of any hint about the returned resource (e.g. a server object plus an action), which matters since there is no output schema; otherwise it is 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 name, image, server_type, labels, location, ssh_keys, user_data and start_after_create are all self-documented including defaults and examples. The description adds no parameter-level detail beyond what the schema already 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 ('Provision a new server') that no sibling shares, and names the underlying API call. An agent can immediately distinguish this from power/reboot/backup siblings.

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

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

Explicitly directs the agent to call hetzner_list_server_types first for prices and hetzner_list_images for a bootable image, which is strong prerequisite routing. It does not state when *not* to use it or contrast with a sibling create-path, but the preconditions are clear.

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

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

The destructiveHint annotation flags that this is a destructive action, but the description goes further and specifies exactly what is lost: 'Existing backups are DELETED.' That is the single most decision-relevant fact for this operation and is precisely the kind of detail annotations do not carry.

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

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

Three short sentences, no filler, and the irreversible consequence is placed early where it can stop a wrong call. Every sentence carries 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 endpoint with no output schema, the description supplies the operation, its scope, its destructive consequence, and the underlying API route. Nothing an agent needs to invoke it safely is missing.

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

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

Schema description coverage is 100% with a single required server_id, so the schema already documents the parameter fully. The description adds no format, range, or selection semantics beyond 'for a server,' which is the baseline 3 for schema-covered 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?

States a precise verb ('Turn off') plus resource ('automatic backups for a server'), and the inverse relationship to hetzner_enable_server_backup is unambiguous from the wording. The added API endpoint removes any residual doubt about which operation this maps to.

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

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

Usage is only implied: an agent can infer this is used when backups are no longer wanted, and the data-loss warning implicitly signals caution. It never names the counterpart tool (hetzner_enable_server_backup) or states prerequisites/exclusions, so no explicit when/when-not guidance is given.

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

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

Annotations only carry destructiveHint=true, so the description's disclosure that this adds roughly 20% to the server's price is meaningful behavioral context an agent cannot get elsewhere. It still omits whether the change is idempotent or immediately billable.

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 plus an endpoint reference, front-loaded with the action and the cost consequence. 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 single-parameter mutation with no output schema, the description covers the action, cost impact, and API mapping. Minor gaps around permissions and reversibility remain but are not critical here.

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

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

Schema description coverage is 100% for the single server_id parameter, so the description adds no meaning beyond what the schema already provides. Baseline 3 applies 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+resource: 'Turn on automatic backups for a server.' It is clearly the inverse of the sibling hetzner_disable_server_backup, though the description never names that sibling to make the routing explicit.

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

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

Usage is implied by the action itself, but there is no explicit guidance on when to enable backups versus using hetzner_change_server_protection, nor any prerequisites or exclusions.

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

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

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds genuine context beyond that: the tool is a polling primitive for async operations and every write tool feeds it. It stops short of documenting return status values or any retry/backoff guidance, which would be the remaining gap.

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 plus a short API reference, front-loaded with the purpose and immediately followed by the workflow hint. No filler; every sentence earns its place.

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

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

With no output schema, the description could say more about what 'status' resolves to (e.g. running/success/error), though it does convey the binary 'finished or not' question. For a one-parameter read tool this is nearly complete, with only the return shape under-specified.

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

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

Schema coverage is 100% and the single parameter is fully described in the schema, so baseline 3 applies. The description restates that the tool operates on an action id but adds no format or constraint detail beyond the schema.

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

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

States a specific verb and resource ('Fetch the status of one asynchronous action') and is unambiguously distinguishable from every sibling, which are list/get resource tools rather than action pollers. The added API mapping (GET /actions/{id}) pins the exact operation.

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

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

'Every write tool here returns an action id — poll it with this to see whether the operation finished' gives an explicit trigger condition (after a write returns an id) and the purpose of polling. An agent knows exactly when to reach for this versus the get/list siblings.

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 readOnlyHint annotation already establishes this as a safe read. The description reinforces that with 'Fetch' and 'GET /certificates/{id}', but adds nothing about error behavior (e.g., 404 for unknown id), authentication, or what is returned, so it goes only marginally beyond the structured metadata.

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 with zero filler. The efficiency is good, though the brevity partly reflects generic template content rather than tight, tailored 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?

For a one-parameter fetch with no output schema, the definition is barely adequate: it does not say what a successful call returns (a certificate object and its fields) or how failures manifest. The endpoint mapping helps, but an agent has no picture of the response shape.

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

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

Schema coverage is 100% and the single 'id' parameter is fully documented in the schema. The description's 'by id' merely echoes that, adding no format or constraint details 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 verb 'Fetch' and the endpoint '/certificates/{id}' identify the resource, but the prose itself only says 'a single resource by id' — generic template text that would apply to any getter. Specificity comes from the URL, not the description, and the plural tool name vs. singular title is a mild inconsistency.

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 rather than hetzner_list_certificates (to discover an id) or any other sibling; the agent gets no hint about prerequisites such as needing a valid certificate id. The endpoint implies a direct lookup but no usage context is 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 readOnlyHint=true annotation already establishes the safe-read profile, and the description reinforces it with the literal GET endpoint. Beyond that it adds little behavior: nothing about 404/not-found handling, auth requirements, or rate limiting. With annotations covering the safety profile, a 3 is appropriate.

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

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

Two short sentences, front-loaded with the action and scope, then the endpoint. Every clause carries information and there is no padding.

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

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

This is a low-complexity single-parameter lookup, but there is no output schema and no annotation detail on returns, so the description is the only place that could mention what comes back (a single firewall object) and what happens on a missing id. As written, the agent knows how to call it but not what to expect back or on failure.

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?

Only one parameter (id) exists and schema description coverage is 100%, so the schema fully documents it as 'The resource's numeric id.' The description's 'by id' adds no syntax, 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 ('Fetch') and a retrieval scope ('a single resource by id'), and names the underlying endpoint GET /firewalls/{id}, which pins the actual resource to firewalls. The only weakness is that it calls the entity a generic 'resource' rather than 'firewall', so the reader must lean on the tool name/title and endpoint to resolve what is fetched.

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

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

Usage is only implied: 'by id' signals this is for retrieving one known firewall, which implicitly contrasts with the sibling hetzner_list_firewalls. There is no explicit when-to-use statement, no mention of the list alternative, and no prerequisites or error 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?

The readOnlyHint=true annotation already establishes this is a safe, non-mutating read, so the bar is lower. The description adds only the HTTP endpoint, and says nothing about failure modes (missing/nonexistent id), rate limits, or what the returned object contains.

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

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

Two short sentences with the operation front-loaded and zero padding. The first sentence is generic family boilerplate rather than floating-IP-specific, which slightly dilutes it, but 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 single-parameter read tool with annotations covering the safety profile and no output schema to explain, the description supplies the operation and the exact REST path, which is sufficient to invoke correctly. Only failure behavior is unaddressed.

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

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

With one parameter and 100% schema description coverage, the schema already documents "The resource's numeric id." The description adds no format, range, or sourcing guidance beyond that, 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+resource pattern ("Fetch a single resource by id") and the concrete endpoint GET /floating_ips/{id}, which pins it to floating IPs and to a single-item retrieve. It distinguishes itself from the sibling hetzner_list_floating_ips by the id-based single-resource phrasing, though the first sentence is generic boilerplate shared across the family.

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

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

Usage is only implied: the id parameter and "single resource" wording signal this is the by-id lookup counterpart to hetzner_list_floating_ips, but the description never states when to prefer either. No prerequisites, auth requirements, or 404 behavior 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?

readOnlyHint=true already tells the agent this is a safe read, so the description's job is lighter. It adds the underlying endpoint mapping, which is mildly useful, but says nothing about return shape, missing-resource behavior, or error handling.

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, with no filler. Slightly terse — the endpoint clause is the only extra and it is compact rather than 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?

For a one-parameter read tool with readOnlyHint set, the essentials are covered, but with no output schema the description should indicate what is returned (a load balancer object) and what happens on an invalid id. That gap keeps it at minimum-viable 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?

There is one parameter with 100% schema description coverage, so the schema already documents 'id' as the numeric resource id. The description adds no format or sourcing detail beyond that 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?

States a specific verb (fetch) and resource (single resource by id), and names the concrete API endpoint GET /load_balancers/{id}, which implicitly separates it from the plural list tool. It does not explicitly name hetzner_list_load_balancers as the alternative, so it falls short of full sibling differentiation.

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

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

Usage is implied by 'by id' versus the plural list sibling, but the description never states when to use this tool versus hetzner_list_load_balancers or what a valid id is. An agent can infer the intent but gets no explicit routing guidance.

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

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

readOnlyHint=true already establishes the safe read-only profile, so the description's main addition is the REST endpoint mapping. It says nothing about 404/not-found behavior, whether the id must exist, or what the payload contains, so it adds limited behavioral context beyond the annotation.

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, with the core action front-loaded and the API mapping as supporting detail. Nothing here needs trimming.

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 trivial one-parameter read tool with full schema coverage and a readOnlyHint annotation, the description covers what is needed to invoke it correctly, and no output schema means return values need not be explained. It is slightly generic ('a single resource' rather than naming networks) but functionally 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% and the single 'id' parameter is fully documented in the schema, so baseline 3 applies. The description's 'by id' merely restates the parameter rather than adding format or range guidance.

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 ('Fetch a single resource by id') and pins it to the concrete REST call 'GET /networks/{id}', so the agent knows this is a single-network lookup rather than a list. It does not explicitly name the sibling hetzner_list_networks, but the 'single resource by id' framing distinguishes it from the list-family tools well enough.

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 you must already hold an id, which is the only real usage condition, but there is no explicit when-to-use/when-not statement or pointer to alternatives such as hetzner_list_networks for discovery. Usage is inferable 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?

readOnlyHint=true already establishes this is a safe read with no side effects. Beyond that the description adds real context: the response is the FULL price list (not a filtered subset) and is scoped to the project's currency, plus the underlying endpoint. It omits any note on rate limits or the fact that pricing returns per-location detail.

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

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

One front-loaded sentence stating what is fetched and what it contains, followed by a short API endpoint reference for agents that reason in HTTP terms. No filler, no repetition of the title.

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

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

With no input or output schema, the description carries the burden of describing the return payload, and enumerating the covered resource categories does that reasonably well. It stops short of indicating the price shape (hourly vs monthly, per-location breakdown), which an agent reading only this text would still have to discover from the response.

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

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

The tool takes zero parameters, so the 4 baseline applies. The description still adds value by noting the currency dimension is determined by the project rather than passed in, which preempts an agent from looking for a currency argument.

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?

Specific verb ('Fetch') plus resource ('full price list') with an explicit enumeration of what the list covers: server types, volumes, traffic, floating IPs, load balancers and backups. No sibling tool does pricing, so the agent can distinguish it immediately from the many hetzner_get_*/list_* inventory 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?

Usage is implied (call when you need to compute or display costs) and the description usefully scopes it to the project's currency, but it never states when to reach for this versus the location/type listing tools or whether extra inputs are needed. With no competing pricing sibling there is little routing to do, so this is adequate rather than explicit.

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

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

The readOnlyHint annotation already establishes that this is a safe read, so the description's main additional contribution is confirming the concrete HTTP GET endpoint. It says nothing about behavior on a missing/invalid id (e.g., 404 handling), authentication, or rate limits, which is a modest but acceptable gap given 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?

Two short sentences, front-loaded with the action and followed by the concrete endpoint. No wasted prose, though the generic opening clause is slightly redundant with the title.

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

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

For a single-resource getter with one fully documented parameter and readOnlyHint set, the essentials are covered. With no output schema, the description gives no indication of what the returned primary IP object contains (address, assignment, datacenter), which leaves a real gap for a fetch tool.

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

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

Schema description coverage is 100% and there is exactly one required parameter documented as 'The resource's numeric id.' The description's 'by id' adds nothing beyond the schema, so the baseline 3 applies.

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

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

The description names a specific verb (fetch) and, via the endpoint reference 'GET /primary_ips/{id}', pins the resource to primary IPs, which distinguishes it from the sibling list_primary_ips. However, the opening phrase 'Fetch a single resource by id' is generic and relies on the endpoint string plus the title to identify the resource, so it is clear but not crisp on its own.

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 statement of when to use this versus alternatives. The obvious sibling, hetzner_list_primary_ips, is never mentioned, nor is any condition such as 'use this when you already have an id.' Usage is only inferable from the name pattern.

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 readOnlyHint annotation already confirms this is a safe read operation. The description adds useful context: it specifies the returned fields and the exact API endpoint (GET /servers/{id}), though it does not mention authentication needs or rate limits.

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

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

Two sentences, zero waste. The main purpose and return scope are front-loaded, with the API endpoint as a compact secondary 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 single-resource GET tool with one fully documented parameter and a readOnly annotation, the description sufficiently explains scope and return fields. No output schema exists, and none is needed for this description to be 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% and server_id is already documented as the server's numeric id. The description adds only the endpoint template /servers/{id}, which does not meaningfully extend the schema's 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?

States a specific verb ('Fetch') and resource ('a single server'), then enumerates included related resources (type, image, IPs, volumes, networks, protection flags). The word 'single' distinguishes it from the sibling list_servers tool without ambiguity.

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

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

Implies use when an agent needs details for one specific server, but it does not explicitly compare to alternatives like list_servers for multiple servers or get_server_metrics for metrics. No when-not or exclusion guidance 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=true, so the safe-read profile is covered by structured data. The description adds only the upstream endpoint (GET /servers/{id}/metrics), a minor detail, and says nothing about rate limits, metric retention windows, default resolution, or response shape.

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, both front-loaded: the capability first, the API mapping second. No filler and nothing an agent must scan past to find the 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 read-only fetch with a fully described input schema and no output schema, the description covers the essentials: what is returned, for which server, and over what window. It is slightly thin on what the time series actually contains (units, sample structure) and on default step behavior.

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

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

Schema description coverage is 100%, so all five parameters (server_id, type, start, end, step) are already documented inline, including the type enum. The description's mention of 'CPU, disk or network' and 'over a window' only echoes what the schema states, establishing the baseline 3 rather than adding new semantics.

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

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

The description states a specific verb (Fetch) and resource (CPU, disk or network time series) scoped to a single server and a time window, which distinguishes it from close siblings like hetzner_get_server (metadata) or hetzner_list_servers. It does not explicitly name those siblings, so it stops short of a 5.

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

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

Usage is only implied by the scope: an agent can infer this is the tool for historical metric data, but there is no explicit when-to-use, when-not-to-use, or named alternative (e.g. use hetzner_get_server for static attributes). No prerequisites or retention/cost caveats 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?

readOnlyHint=true already tells the agent this is a safe read, so the description carries no safety burden. It adds nothing further: no not-found behavior, no error semantics, no indication of what the response contains. For a fetch tool with annotations, this is the minimum.

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, front-loaded sentences with no filler or redundancy. It is efficiently structured, though partly because it says so little.

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

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

For a simple single-id fetch this is thin: with no output schema, the description should at least hint at what is returned or how failures surface, and it does neither. It leaves the agent with no more context than the schema and title already provide.

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

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

Schema description coverage is 100% and there is only one parameter, so the schema already documents 'id' as the numeric resource id. The description adds no meaning beyond that baseline (e.g., no mention of where ids come from or how to find them).

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 says 'Fetch a single resource by id,' which is a generic verb+resource pairing that only becomes specific via the appended API path 'GET /ssh_keys/{id}'. The tool name and title say 'SSH key,' but the description itself never names the resource, and it does little to distinguish itself from sibling getters like hetzner_get_server or hetzner_get_certificates.

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 vs. alternatives such as hetzner_list_ssh_keys or hetzner_get_server. No prerequisites, no mention of what id values are valid beyond the schema, and no exclusions.

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?

readOnlyHint=true already tells the agent this is a non-destructive read, and the description adds only the REST endpoint, which is restatement rather than new behavioral context. It says nothing about what happens when the id does not exist, whether errors are raised or null returned, or rate-limit behavior.

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

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

Two short sentences with the action front-loaded and no filler. The endpoint line is compact and useful for orienting to the underlying API, though it is close to redundant with the tool name.

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

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

For a simple single-resource read with full schema coverage and read-only annotations already present, the definition supplies what is needed to call it correctly. The only meaningful omission is failure semantics for a nonexistent id.

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?

Only one parameter and schema description coverage is 100%, so the schema fully documents 'id' as the numeric resource id. The description's 'by id' adds no syntax, range, or format detail beyond that, making the baseline 3 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 a specific verb (fetch) and resource (a single resource identified by id), and the endpoint mapping 'GET /volumes/{id}' pins it to volumes, so it is distinguishable from siblings like hetzner_list_volumes. The generic phrase 'a single resource' is weaker than the title 'Get one volume', but the endpoint line resolves the 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?

No guidance on when to use this versus hetzner_list_volumes or other get_* siblings, and no mention of prerequisites such as needing a valid volume id. The agent must infer the single-vs-list distinction from the name alone.

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

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

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds the useful fact that results include expiry and that both managed and uploaded certificates are returned, plus the underlying API endpoint. It says nothing about pagination, default page size, or result volume, which is the main behavioral gap for a list endpoint that supports paging.

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 waste, with the resource and the notable scope (managed or uploaded, expiry) front-loaded before the API endpoint reference. Nothing is padded.

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

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

For a read-only list tool with 0 required params, full schema coverage, and no output schema, this is close to complete. The main omission is pagination behavior, though the page/per_page parameters in the schema partly compensate.

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 four well-documented parameters (name, page, per_page, label_selector), so the schema carries the burden. The description adds no parameter detail beyond what the schema already states, making the baseline 3 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 a specific verb (list) and resource (TLS certificates), and adds scope detail that the sibling get_certificates does not: 'managed or uploaded' and 'their expiry'. It does not explicitly differentiate itself from the near-identically named hetzner_get_certificates, which slightly weakens disambiguation.

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

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

No when-to-use guidance and no alternative named. The sibling set contains hetzner_get_certificates, and an agent gets no hint whether that returns one certificate or a filtered set, nor when to prefer this tool. Usage is only implied by the verb 'list'.

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

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

readOnlyHint=true already establishes the safe-read profile, so the description doesn't need to re-assert it. It does add value by disclosing that results include rules and resource bindings, but says nothing about pagination behavior despite page/per_page parameters.

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

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

Two short sentences, front-loaded with the resource and what the listing contains; the API endpoint reference is compact. No wasted prose.

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

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

With no output schema, the description usefully summarizes the return payload (rules and applied resources), and the schema fully covers filtering and paging inputs. Only a pagination/volume note would improve it.

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

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

Schema description coverage is 100%, so all four parameters (name, page, per_page, label_selector) are fully documented in the schema, including the Hetzner label-selector idiom. The description adds no parameter meaning beyond that, so baseline 3 applies.

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

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

States a specific verb ('List') and resource ('firewalls') plus the payload contents (rules, applied resources), which distinguishes it from the singular hetzner_get_firewalls. It stops short of explicitly contrasting itself with that sibling, but the list-vs-get convention is readable.

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 and no mention of the alternative hetzner_get_firewalls for retrieving a single firewall. The agent must infer the choice entirely from naming convention.

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?

readOnlyHint=true already tells the agent this is a safe read. The description usefully notes the response associates each floating IP with a server, but says nothing about pagination behavior despite page/per_page parameters, nor about empty results or rate limits.

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

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

Two short sentences, front-loaded with the action and result. The trailing 'Hetzner Cloud: GET /floating_ips' is mildly redundant but gives the underlying endpoint, so it earns most of its space.

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

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

For a read-only list tool with no output schema, the description omits pagination semantics, which matters given page/per_page are exposed. Safety is covered by annotations, but the paging contract is left entirely to the schema.

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

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

Schema description coverage is 100%, so all four filters (name, page, per_page, label_selector) are already documented in the schema. The description adds no syntax or semantics beyond that, which is the expected 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?

States a specific verb and resource ('List floating IPs') and adds scope detail that this returns server assignment. It does not distinguish itself from the sibling hetzner_get_floating_ips (presumably the single-resource variant), so an agent must infer the list-vs-get split from the names alone.

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, and no mention of the alternative hetzner_get_floating_ips for fetching one IP. Usage is only implied by the verb 'List'.

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

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

Annotations already declare readOnlyHint=true, so safety is covered and the bar is lower. The description adds the useful framing that the results are bootable/restorable rather than raw records, but says nothing about pagination behavior or default result size for a 6-filter listing.

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

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

Two compact sentences with zero filler; the purpose is front-loaded and the endpoint reference is a terse second clause.

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 but thin for a filterable list tool with no output schema. All inputs are covered by the schema, but the description does not note that results are paginated or what shape an image record takes, leaving the agent to discover this at call time.

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 all six optional filters (name, type, architecture, label_selector, page, per_page) documented inline, including enum values and the Hetzner label idiom. The description adds no parameter-level meaning, so baseline 3 applies.

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

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

Specific verb ('List') and resource ('OS images, snapshots and backups'), plus the added semantic gloss that these are bootable/restorable. It is clearly distinct from the mutating sibling hetzner_create_image_from_server, though it does not name that sibling explicitly.

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

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

No when-to-use guidance, no stated prerequisites, and no mention of alternatives such as hetzner_get_server when an agent wants images attached to a specific server. The API endpoint reference (GET /images) is context, not usage 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?

readOnlyHint=true already establishes this is a safe read, and the description usefully adds that results include services, targets and health status. However it says nothing about pagination behavior despite page/per_page parameters, so the add-on context is modest.

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

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

Two short, front-loaded sentences with no filler. The trailing 'Hetzner Cloud: GET /load_balancers' restates the obvious slightly, but costs almost nothing.

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 parameterless-required, read-only list tool with annotations covering safety and a fully described schema, this is nearly complete. The only real gap is the absence of any pagination expectation, and no output schema exists to carry return-shape detail.

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

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

Schema description coverage is 100%, so all four parameters are fully documented in the schema itself. The description adds no syntax, format or defaulting detail beyond what the schema provides, which is the expected 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?

States a specific verb (List) and resource (load balancers) plus what the listing exposes (services, targets, health status). It does not explicitly differentiate itself from the sibling hetzner_get_load_balancers, leaving the list-vs-get routing to inference.

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

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

Usage is implied by the filter-oriented parameters (name, label_selector, page) but the description never says when to use this rather than hetzner_get_load_balancers or hetzner_get_load_balancers. No exclusions or prerequisites are stated.

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

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

Annotations already declare readOnlyHint=true, so the safe-read profile is established. The description adds the API mapping (GET /locations) and the shape of returned entries, but says nothing about pagination or result-size behavior for a list endpoint.

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

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

Two tight sentences with the resource and its fields front-loaded and the API endpoint appended; 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 read-only list tool with full schema coverage and annotations covering safety, the description is nearly complete; it even compensates for the absent output schema by naming the returned fields. Only pagination/ordering behavior is unaddressed.

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

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

Schema description coverage is 100% and the single name parameter is documented with an example (fsn1), so the schema carries the semantics. The description adds no filtering guidance beyond it, which is the expected 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?

States a specific verb (List) and resource (datacentre locations) and describes what each entry contains (city, country, network zone), which lets an agent distinguish it from the numerous get_*/list_* siblings. It stops short of explicitly naming an alternative, but the resource 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 never says when to call this versus the sibling get_* tools, nor does it mention that the optional name parameter can be used to fetch a single location. Usage is only implied by the resource 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?

readOnlyHint=true already tells the agent this is a safe, non-mutating read, so the bar is lower. The description adds useful content detail by naming the returned fields (IP ranges, subnets, routes), but says nothing about pagination behavior despite page/per_page parameters, or about scoping 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 tight sentences with zero filler, and the substantive content (what is returned) is front-loaded before the endpoint reference. Nothing redundant.

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

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

For a read-only list tool with annotations covering the safety profile and a fully documented schema, the description is nearly sufficient, and the return-content enumeration compensates for the absent output schema. Only the lack of pagination context and sibling differentiation keeps it from being 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 all four parameters (name, page, per_page, label_selector) are already documented in the schema. The description adds no syntax, defaults, or filtering semantics beyond what the schema provides, which is the baseline 3 case.

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

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

States a specific verb (List) and resource (private networks) and even enumerates what is returned (IP ranges, subnets, routes). It does not, however, distinguish itself from the sibling hetzner_get_networks (singular fetch), leaving the list-vs-get routing implicit.

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 when-to-use guidance and never references the near-identical sibling hetzner_get_networks or the other list_* tools. The only contextual hint is the raw API endpoint, which does not tell an agent when this tool is preferable.

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 readOnlyHint=true annotation already tells the agent this is a safe, non-mutating read. The description adds a small amount of useful context by noting assignments are included and by naming the upstream endpoint, but it says nothing about pagination behavior or result size despite exposing page/per_page.

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, front-loaded sentences with no filler: the action and scope come first, and the API mapping is a compact second sentence. Every clause 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-only list tool with full schema coverage and a readOnly annotation, the essential information is present. With no output schema, though, the brief mention of 'their assignments' is the only hint at return shape, and list-vs-get selection is unaddressed.

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

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

Schema description coverage is 100%, so name, page, per_page, and label_selector are fully documented in the schema itself. The description adds no format or semantic detail beyond that, which is the expected baseline when the schema carries the load.

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

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

The description gives a specific verb (List) plus resource (primary IPs) and adds scope (their assignments), so the core purpose is unambiguous. However, it does not distinguish itself from the sibling hetzner_get_primary_ips, which an agent must choose between.

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 prerequisites, and no mention of the list-vs-get distinction against the sibling hetzner_get_primary_ips. The agent is left to infer that this is the enumerating variant.

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

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

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds the upstream API mapping (GET /servers), which is modestly useful, but it says nothing about pagination behavior even though page/per_page exist, nor about rate limits or the shape of results. With annotations carrying the safety burden, 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?

A single front-loaded sentence covers scope and filters, followed by a short API reference. Nothing is padded and the essential information comes first, though the trailing API line is near-redundant.

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

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

For a read-only list tool with full schema coverage and annotations covering safety, the description supplies adequate context. The main omission is pagination/result-set behavior, which matters for a paged collection endpoint but is not fatal.

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 five parameters (name, page, per_page, status, label_selector) are documented in the schema itself. The description restates name/status/label_selector at a high level but adds no syntax or semantics beyond the schema, which is exactly the baseline-3 case.

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

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

States a specific verb (List) and resource (servers) and scopes it to "the token's project," with the three filter axes named. The plural/collection scope implicitly separates it from the singular hetzner_get_server sibling, but no sibling is named explicitly, 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?

Usage is only implied: the description makes clear this is for enumerating servers in the current project with optional filters. It never states when to prefer it over hetzner_get_server for a single server, nor any exclusions or prerequisites, so it lands at minimum-viable 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?

readOnlyHint=true already tells the agent this is a safe read, so the description's safety burden is low. It adds the upstream endpoint (GET /server_types) and the shape of the data returned, but says nothing about pagination behavior despite page/per_page parameters existing.

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 clauses: the purpose plus returned fields first, then the pre-creation guidance and endpoint. No filler, and the most decision-relevant information leads.

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?

No output schema exists, and the description compensates by naming the returned fields, which is genuinely useful. It is nearly complete for a simple paginated read, with only pagination semantics left unstated.

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

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

Schema description coverage is 100% and all three parameters (name, page, per_page) are documented in the schema, so the baseline is 3. The description adds no filtering or paging syntax 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?

States a specific verb ('List') and resource ('server types') and enumerates the payload fields returned (cores, memory, disk, prices). This distinguishes it cleanly from sibling list tools such as hetzner_list_locations and hetzner_list_servers.

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 when to use it: 'read this before creating a server', tying it to the hetzner_create_server workflow. There are no stated exclusions or named alternatives, but the usage context is clear and actionable.

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?

readOnlyHint=true already establishes this as a safe read, so the description's job is lighter. It adds the underlying API mapping (GET /ssh_keys), which is modestly useful, but says nothing about pagination behavior, default page sizes, or result ordering despite four paging/filter params.

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 resource and its use case, then the API endpoint. Nothing is redundant and no filler is present.

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

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

For a read-only list tool with full schema coverage and no output schema required, the description is largely sufficient. It could still note pagination defaults or that an empty list is valid, but no critical calling information is missing.

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

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

Schema description coverage is 100%, with name, page, per_page, and label_selector all documented in-schema, so the schema carries the semantic load. The description adds no parameter-level meaning, making the baseline 3 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 a specific verb (list) and resource (SSH public keys) plus a concrete purpose: keys available to inject when creating a server. It does not explicitly differentiate from the sibling hetzner_get_ssh_keys (singular retrieval) or hetzner_create_server, which consumes these keys, so it falls short of the 5 bar.

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 mention of the alternative hetzner_get_ssh_keys for fetching a single key, and no exclusions. The 'available to inject' phrase hints at context but stops short of routing the agent.

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

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

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds that results include size and server attachment, which is useful, but it says nothing about pagination behavior or result-set size. With the annotation carrying the core behavioral signal, a 3 is appropriate.

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

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

Two tight sentences with the resource and returned fields front-loaded. The trailing API endpoint mapping ('GET /volumes') is minor but earns its place by grounding the agent in the underlying REST 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?

With no output schema, the description partially compensates by naming the salient return fields (size, attachment). Combined with a fully documented parameter schema and a readOnly annotation, this is nearly complete, though pagination and total-count behavior remain unstated.

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 four parameters (name, page, per_page, label_selector) are fully documented in the schema. The description adds no parameter-level syntax or semantics beyond what the schema provides, 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?

States a specific verb and resource ('List block-storage volumes') and even summarizes the returned fields (size, attached server), so the agent knows exactly what the tool yields. It does not explicitly distinguish itself from the sibling 'hetzner_get_volumes', but the list-vs-get distinction is clear from the name and body.

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

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

Usage is implied by 'List': enumerate all volumes, optionally narrowed by the schema's name/label filters. There is no explicit when-to-use guidance, no statement of when to prefer this over hetzner_get_volumes, and no mention of prerequisites or pagination expectations.

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 real behavioral context beyond the annotations: this is an asynchronous operation that returns an action id which must be polled via hetzner_get_action, and it cites the underlying endpoint. It does not address permissions or idempotency, but the async contract is the key disclosure an agent needs.

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

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

Three terse sentences that front-load the operation, then the follow-up action, then the API mapping. No filler, every clause 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?

With no output schema, the description compensates by explaining the return value (an action id) and how to consume it. Nothing essential is missing for a single-parameter action tool, though permission or state preconditions would make it fully complete.

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

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

There is a single parameter with 100% schema description coverage ('The server to start'), so the schema already carries the semantics. The description adds nothing about the server_id beyond restating that the server is stopped, which is the correct 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?

States a specific verb and resource ('Power on a stopped server') and scopes it to stopped servers, which implicitly separates it from hetzner_reboot_server and hetzner_shutdown_server. It stops short of naming those siblings explicitly, so an agent must infer the boundary from the word 'stopped'.

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

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

Usage is implied by the 'stopped server' precondition, and the description helpfully routes the caller to hetzner_get_action for polling, but it never states when to prefer this over reboot or shutdown, nor any preconditions such as server state or permissions.

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 flag destructiveHint=true, so the safety profile is covered. The description adds genuinely useful context by disclosing that the reboot is graceful and performed via ACPI, but it omits operational behavior such as service downtime, whether the call is asynchronous and returns an action, or how long the server stays unavailable.

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, front-loaded sentences with no filler. The trailing REST endpoint reference is semi-redundant but cheap and aids API-aware callers.

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

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

For a one-parameter action this is nearly adequate, but with no output schema the description should note that this is an asynchronous action whose result must be polled (via hetzner_get_action), and it should note the server-state prerequisite. Those gaps keep it at minimum-viable.

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?

Only one parameter exists and schema description coverage is 100%, so the schema already documents server_id as the target. The description adds no syntax, format, or constraint detail beyond what the schema 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?

States a specific verb and resource ('Reboot a server') and adds the mechanism ('gracefully via ACPI'), which distinguishes it from a hard reset. It does not explicitly contrast with siblings like hetzner_shutdown_server or hetzner_poweron_server, but the verb itself 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?

There is no guidance on when to use reboot versus the sibling shutdown_server or poweron_server, nor any prerequisites or state requirements (e.g., server must be running). The 'gracefully via ACPI' phrase hints at graceful-vs-hard semantics but never states when each 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 only supply destructiveHint=true, so the description usefully adds the ACPI/graceful nature, the preference ordering, and the cost consequence (a stopped server still bills; only deletion stops it). It omits that the action is asynchronous and returns an action object, but the cost and mechanism disclosures are meaningful value beyond the annotation.

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

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

Three short sentences, front-loaded with the core action and mechanism, then preference, then the non-obvious cost caveat. Every sentence earns its place and nothing is padded.

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

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

For a one-parameter action tool with a destructive annotation, the description covers what happens, how, why to prefer it, and the billing implication. The remaining gap is that no output schema exists yet the return value (an async action object) is not described, which is a minor omission.

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

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

Schema description coverage is 100% and there is a single well-documented required parameter, so the schema carries the parameter semantics. The description adds nothing about server_id beyond what the schema says; 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+resource (shut down a server) and the exact mechanism (graceful ACPI request to the guest OS). This cleanly distinguishes it from siblings like hetzner_poweron_server and hetzner_reboot_server without the agent needing to open either schema.

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

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

"Prefer this over a hard power-off" gives a clear selection criterion and implies the when-to-use condition. However, it never names the competing sibling tools (reboot vs. shutdown vs. poweroff) or states when-not to use it, so it stops short of full routing guidance.

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