Hetzner Cloud MCP by usefulapi

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

Annotations only declare destructiveHint=true; the description adds the API endpoint and the directional note that enabling protection is the safest write, which partially compensates. However it omits that turning protection OFF is the destructive direction, whether the change takes effect immediately, and any permission requirements.

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

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

Two short sentences, front-loaded with the operation and followed by the endpoint reference. Nothing is wasted, though the 'safest write' aside is more editorial than informational.

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

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

A mutation tool with no output schema and minimal annotations; the description covers what changes but not the resulting state, error conditions, or whether protection changes are reversible. Adequate but leaves behavioral gaps for a write operation.

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

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

Schema description coverage is 100%, so delete, rebuild, and server_id are already documented in the schema. The description adds no format or default guidance beyond restating that protection can be turned on or off, 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 (turn on/off) applied to a specific resource (deletion and rebuild protection for a server), naming both toggled flags. An agent can distinguish this from siblings like enable_server_backup 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?

Usage is implied by the resource name, but there is no explicit when-to-use guidance, no prerequisites, and no reference to related tools (e.g. rebuild or delete actions) that this protection gates. The claim that ON is 'the safest write' hints at intent without stating a selection rule.

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 provide destructiveHint=true, and the description usefully adds cost behavior ('Snapshots are billed for the space they use') and timing guidance. It does not, however, reconcile the destructive annotation (e.g., that backups consume a backup slot) or explain side effects on the source server, so disclosure is partial 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, front-loaded sentences: purpose first, then the usage cue, then cost, then the API mapping. Each sentence earns its place with no filler or repetition.

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

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

For a three-parameter create tool with no output schema, the description covers purpose, timing, cost, and endpoint, which is enough to invoke it correctly. It is only slightly incomplete in not stating the outcome (e.g., that an image ID is produced / an action is returned) or failure 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% and the enum for type (snapshot vs backup, default snapshot) is already documented in the schema. The description adds no parameter-level syntax or format detail, so the baseline 3 applies.

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

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

The description states a specific verb and resource ('Create a snapshot image from a server's disk') and even maps it to the underlying API endpoint, so there is no ambiguity about what the tool produces. It is easily distinguished from read-oriented siblings like hetzner_get_server and from hetzner_create_server, which provisions rather than snapshots.

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

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

It gives a clear contextual trigger: 'the safe thing to do BEFORE a risky change,' which tells the agent when this tool is appropriate. However, it never contrasts the snapshot path against the backup path (hetzner_enable_server_backup) or states any preconditions/exclusions, so routing guidance is context but not alternatives.

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

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

Annotations only carry destructiveHint=true, so the description usefully discloses that billing starts on boot and is metered hourly — a consequential behavioral fact the annotations do not convey. It still omits what happens on partial failure, auth/permission requirements, and the shape of the response, leaving some transparency burden unmet.

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 billing warning front-loaded in caps immediately after the purpose, then prerequisites, then the API mapping. 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 an 8-parameter mutation with nested objects and no output schema, the description covers the two things an agent most needs (cost implications and prerequisite lookups). It leaves the return value and failure modes unexplained, but the high schema coverage limits how much that matters.

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 eight parameters (including nested labels and the ssh_keys fallback-to-emailed-root-password behavior) are already documented in the schema. The description adds no parameter-level detail beyond indirectly pointing at server_type pricing, 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?

Names a specific verb and resource ('Provision a new server') and is instantly distinguishable from the read-side siblings like hetzner_get_server or hetzner_list_servers. It also states the underlying API mapping (POST /servers), removing any ambiguity about the operation being a creation.

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

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

Gives explicit prerequisite ordering: call hetzner_list_server_types for prices and hetzner_list_images for a bootable image before provisioning. It does not state when-not to use this tool (e.g. reusing an existing server), so it stops short of the full when/when-not/alternatives bar.

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 flag destructiveHint=true, which tells the agent a mutation occurs but not what it destroys. The description goes beyond that by stating explicitly that existing backups are DELETED, which is exactly the consequence an agent must weigh before calling. It also pins the underlying API endpoint for traceability.

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, each earning its place: purpose, destructive consequence, and API endpoint. The most decision-relevant fact (backups are deleted) is placed early rather than buried.

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

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

For a single-parameter destructive action with no output schema, the description covers what an agent needs: what the action does, the irreversibility of the backup loss, and the API mapping. Nothing material is 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?

There is a single parameter with 100% schema description coverage ('The server to stop backing up'), so the schema already carries the semantics. The description adds no format, ID-source, or constraint detail beyond it, 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 and resource ('Turn off automatic backups for a server') that is immediately distinguishable from its mirror sibling hetzner_enable_server_backup. The tool name plus the explicit consequence sentence leave no ambiguity about what it does.

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

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

Usage is implied rather than stated: the agent can infer this is the inverse of hetzner_enable_server_backup, but the description never names that alternative or states when backups should be turned off. The destructive warning functions as a caution, not as selection guidance.

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

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

Annotations supply title and destructiveHint=true, so the safety profile is partly covered. The description usefully adds the 20% price impact and the underlying API action, but omits whether this is an async action requiring polling, and does not note reversibility via disable_backup.

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 price note. The trailing API endpoint is mildly extraneous for an agent but is compact and not disruptive.

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 and partial annotation coverage, the description covers purpose and cost but leaves gaps around async action behavior and what happens to existing backups/data. Adequate but not 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?

Only one parameter and schema description coverage is 100% ('The server to protect.'), so the schema already carries the meaning. The description adds nothing about server_id format or constraints, matching the baseline for fully documented schemas.

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 ('Turn on automatic backups for a server'), which is unambiguous and clearly the inverse of the sibling hetzner_disable_server_backup. It does not explicitly name siblings, but the purpose is immediately legible.

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 context (enabling automatic backups, with the 20% cost implication) is implied rather than stated as a when/when-not rule. There is no guidance on prerequisites, alternatives, or when to prefer a snapshot/image tool instead.

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 declare readOnlyHint=true, so the description carries the async-polling context: it explains that writes return action ids and that this tool resolves their final state. It doesn't say how long results stay available or what status values appear, but it adds genuine 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?

Three short sentences with zero waste; the core purpose leads and the polling guidance and endpoint follow without 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?

For a single-param read tool with no output schema, the description covers purpose, usage trigger, and endpoint adequately. It stops short of describing the returned status fields an agent will need to interpret the poll result, a minor gap.

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

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

Schema coverage is 100% and the single parameter's meaning (numeric action id) is already documented, so the description adds no syntax or format detail. Baseline 3 is appropriate when the schema does all the work.

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

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

States a specific verb and resource ('Fetch the status of one asynchronous action') and identifies the endpoint. It is clearly distinguishable from all siblings, none of which poll action status.

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 says when to use it: every write tool returns an action id, and this polls that id to check completion. No exclusions or retry-cadence guidance, but the triggering condition is unambiguous.

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. The description adds the underlying REST mapping (GET /certificates/{id}), which is minor context, but says nothing about auth requirements, rate limits, or not-found 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 no waste, leading with the action and following with the concrete HTTP endpoint. Every element 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 single-resource tool with full schema coverage and readOnlyHint annotations, the definition is nearly sufficient. It lacks any hint of what a certificate object contains, though with no output schema that is a minor gap.

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

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

Schema description coverage is 100% and the single 'id' parameter is fully documented in the schema, so the baseline is 3. The description's 'by id' adds no syntax or constraint detail 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 clear verb and, via the endpoint, the resource ('GET /certificates/{id}'), so an agent can tell this fetches one certificate. However, the body text says only 'a single resource by id' rather than naming the certificate resource directly, and it does not explicitly contrast with the sibling hetzner_list_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?

No guidance on when to use this versus the sibling hetzner_list_certificates or the other get_* tools. The 'by id' phrasing weakly implies single-item lookup, but no conditions or alternatives 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?

The readOnlyHint annotation already declares this is a safe read operation. The description adds the concrete REST endpoint mapping, which is useful context, but it does not disclose error behavior (e.g., what happens if the id does not exist) or return characteristics beyond the implicit GET semantics.

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 core purpose and immediately followed by the API mapping. There is no filler, and both sentences carry useful 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 one-parameter read operation with full schema coverage and a readOnlyHint annotation, the description covers purpose and endpoint adequately. However, with no output schema, it does not describe the return value or error cases, which is a clear gap for an agent that needs to know what to expect back.

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

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

The schema documents the sole parameter fully ('The resource's numeric id.') with type and range, so coverage is 100%. The description adds no additional parameter meaning beyond what the schema already provides, making the baseline of 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?

The description states a specific verb ('Fetch') and identifies the endpoint ('GET /firewalls/{id}'), which clearly distinguishes a single-resource fetch from the list_* siblings. However, it does not explicitly name the alternative (hetzner_list_firewalls), and the description itself says 'a single resource' rather than 'a firewall' — the endpoint supplies that detail.

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

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

The description gives no when-to-use guidance, prerequisites, or alternative tools. 'By id' indicates a required input, not a usage condition; an agent is left to infer that this tool is for when it already has a numeric firewall id.

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. The description adds only the REST endpoint mapping, which offers little behavioral context beyond that — no note on 404 behavior for unknown ids, idempotency, or what the returned resource contains. With annotations carrying the safety profile, this is thin added value.

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

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

Two short sentences, front-loaded with the access pattern and capped by the endpoint reference — no padding or repetition. The endpoint sentence is close to boilerplate across this tool family, keeping it just short of a 5.

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 whose safety profile is covered by annotations, the description is sufficient to invoke the tool correctly. The only real gap is that, with no output schema, it never indicates what a fetched floating IP record contains or how failures (unknown id) surface.

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 integer 'id' parameter with 100% schema description coverage ('The resource's numeric id.'), so the schema fully documents it. The description adds no format, range, or sourcing guidance for the id (e.g., where to obtain it), 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 gives a specific verb and retrieval mode ('Fetch a single resource by id') and the endpoint path GET /floating_ips/{id} identifies the resource type and distinguishes it from the sibling list_floating_ips. It loses a point because the prose itself calls it a generic 'single resource' rather than naming floating IPs, relying on the endpoint string to carry that meaning.

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 'single resource by id' phrasing implies usage (fetch one known record rather than enumerate), which separates it implicitly from list_floating_ips. However, there is no explicit statement of when to prefer this over the list variant, nor any prerequisite/error guidance for a missing or invalid id.

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 structurally. The description adds only the raw HTTP mapping and nothing else – no error behavior (e.g., what happens for an unknown id), no auth/permission requirements, no note on what is returned. Against a lower bar set by annotations, it still contributes very little.

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 API endpoint; nothing is padded. The first sentence is generic boilerplate, but it is not 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 trivial one-parameter read tool with annotations covering safety and no output schema, this is minimally sufficient. It stops short of naming the resource in its own text and gives no error/return context, so it is adequate rather than complete.

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

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

Schema description coverage is 100% for the single `id` parameter, and the description's "by id" adds no syntax or constraint detail beyond the schema. Baseline 3 is appropriate when the schema fully carries the parameter burden.

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 scope ("a single resource by id") are clear, and the endpoint path GET /load_balancers/{id} pins down the resource even though the body text says only "resource". The description usefully resolves the name/title mismatch (plural tool name, singular result) by stating it returns one item. It does not, however, explicitly differentiate itself from the sibling hetzner_list_load_balancers.

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

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

There is no when-to-use guidance and no named alternative. The "by id" phrasing weakly implies you must already hold an id (i.e., call list_load_balancers first), but this is left for the agent to infer 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 declares this is a safe read, so the description's remaining job is small; the endpoint mapping (GET /networks/{id}) adds mildly useful grounding. It does not, however, mention failure behavior (e.g. 404 for an unknown id) or whether the response is a raw API object.

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, no filler, with the core action stated first and the API reference second. Every word earns its place.

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

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

For a single-parameter read tool with no output schema and existing annotations, this is close to sufficient, but it leaves the return shape and error behavior entirely undocumented and gives no routing hint to the list variant.

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

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

Schema coverage is 100% with a single well-described integer id, so the schema carries the parameter meaning. The description adds no syntax, format, or sourcing detail beyond what the schema already provides — baseline 3.

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

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

States a specific verb ("Fetch") and resource ("a single resource by id"), and the explicit endpoint mapping GET /networks/{id} pins it to networks. It could have named the sibling it complements (hetzner_list_networks), but an agent can still tell it apart.

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

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

There is no guidance on when to use this versus hetzner_list_networks, nor any note about the id being required or where to obtain it. The agent is left to infer everything about selection context.

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

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

readOnlyHint=true already tells the agent this is a safe read, so the bar is lower; the description adds genuine context beyond that by scoping the result to the project's currency and naming the six pricing categories returned. It does not mention VAT/tax treatment or whether prices are hourly vs monthly, which is the only real gap for a tool with no output schema.

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

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

Two sentences, no filler: the scope and contents come first, the upstream API endpoint is a compact trailing reference. 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 carries the burden of describing what comes back, and it does so by listing the priced categories. It falls just short of complete because it omits currency/VAT nuances and whether the payload is project-wide or location-dependent.

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 per the rubric the baseline is 4. There is no parameter behavior to describe and the description correctly adds no noise about inputs.

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 a precisely scoped resource ('the full price list for the project's currency'), and it enumerates the covered categories (server types, volumes, traffic, floating IPs, load balancers, backups). No sibling does anything similar, so it is unambiguously distinguishable from the list_*/get_* resource tools.

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

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

The description implies usage — call this when you need cost information for the project — but never states when to reach for it, whether it should be called before provisioning, or any caching/refresh guidance. With no competing pricing sibling, no exclusions are strictly needed, so this is adequate-but-implicit.

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

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

The readOnlyHint=true annotation already establishes this is a safe, non-mutating read, so the description's burden is lighter. It adds the underlying endpoint mapping (GET /primary_ips/{id}), which is mildly useful context, but says nothing about error behavior for an unknown id or what fields come back — and there is no output schema to cover that.

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

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

Two short sentences, front-loaded with the action, with no filler. It is efficient, though the first sentence is boilerplate that could have carried more specificity at the same length.

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 read with full schema coverage this is minimally adequate, but with no output schema the description could have sketched the returned primary IP fields or noted behavior for a missing id. The endpoint mapping is the only extra context supplied.

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 ("The resource's numeric id."), so the baseline of 3 applies. The description adds no format, range, or sourcing detail beyond what the schema already states.

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

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

The description says "Fetch a single resource by id" — a generic template phrase that never names the resource as a primary IP; only the HTTP path suffix "primary_ips/{id}" pins it down. It implicitly contrasts with the sibling hetzner_list_primary_ips (single vs. list) but never states that distinction.

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

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

No when-to-use guidance is given: nothing tells the agent to pick this over hetzner_list_primary_ips when it already has an id, nor that it is a point lookup rather than a search. The only usable cue is the name and endpoint.

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 still adds value by listing exactly which fields come back (type, image, IPs, volumes, networks, protection flags) and by citing the backing endpoint GET /servers/{id}. It does not discuss error behavior for a nonexistent id, but that is a modest 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 compact sentences, zero padding, and the payload contents are front-loaded before the API endpoint reference. 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 usefully enumerates the response contents, which is the main completeness risk for a getter. Only minor gaps remain (error/not-found behavior, whether related resources are embedded or referenced).

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 documented integer parameter, so the schema carries the parameter burden. The description adds nothing about server_id syntax beyond the endpoint template {id}, which matches the baseline of 3 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?

Specific verb ("Fetch") plus resource ("a single server") and an enumeration of the returned sub-resources (type, image, IPs, volumes, networks, protection flags). The word "single" implicitly distinguishes it from hetzner_list_servers, but no sibling is named explicitly.

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

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

Usage is implied by the singular-resource phrasing and the required server_id, but there is no explicit when-to-use guidance and no reference to alternatives such as hetzner_list_servers for discovering ids or hetzner_get_server_metrics for performance data.

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

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

readOnlyHint=true already tells the agent this is a safe, non-mutating read, so the description only needs to add value beyond that. It contributes the API route mapping, which aids traceability, but says nothing about rate limits, result density, or how 'step' affects the returned sample count.

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, no filler, with the functional scope front-loaded and the endpoint reference as a secondary clause. Every element 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?

There is no output schema, so the description carries the burden of telling the agent what comes back — yet it never describes the shape of the time series (samples, timestamps, units) or the effect of 'step' on granularity. For a data-returning metrics tool this is a real gap, though the read-only annotation covers the safety side.

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 (including the cpu/disk/network enum and step resolution) are already documented. The description's 'CPU, disk or network' and 'over a window' merely restate the enum and the start/end pair, adding no format or constraint detail beyond the schema. 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 precise verb ('Fetch') plus the exact resource ('CPU, disk or network time series for one server over a window'), which is enough to distinguish it from hetzner_get_server and every list/get sibling. The added endpoint mapping (GET /servers/{id}/metrics) reinforces the scope. Nothing about the purpose is left ambiguous.

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 'for one server over a window' implies the scenario (per-server time-series queries) but never states when to prefer this over hetzner_get_server for a point-in-time snapshot, nor any exclusions. Usage is inferable rather than spelled out.

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 needs to add something beyond that; it only restates the HTTP endpoint. No mention of error behavior (404 on missing id), auth requirements, or response shape — all of which would be genuinely additive here.

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 then the endpoint; nothing is padded. It is efficient, though the endpoint sentence is arguably redundant with the tool name and adds little for an agent.

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

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

For a one-parameter read-only getter the essentials are covered by the schema and annotations, but there is no output schema, so the agent receives no signal about what a fetched SSH key record contains or how failures surface. Adequate but with a visible 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% with a single well-documented integer id, so the schema carries the parameter semantics. The phrase "by id" only echoes the schema and adds no format, range, or lookup 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?

The description states a specific verb+scope ("Fetch a single resource by id") and pins the exact upstream endpoint GET /ssh_keys/{id}, which makes the target resource unambiguous when combined with the title. It loses a point because the description body itself never names SSH keys, relying on the title, and the plural tool name (hetzner_get_ssh_keys) sits next to hetzner_list_ssh_keys without an explicit 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?

"Fetch a single resource" implies the by-id case versus listing, but the description never states when to use this instead of hetzner_list_ssh_keys or what happens with an unknown id. No prerequisites, no exclusions, no named alternative.

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 bar is lower. The description adds the upstream endpoint mapping, which is mildly useful, but says nothing about error behavior (404), pagination, 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 very short sentences with no filler, and the core action is front-loaded. It is terse but every clause 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 read with full schema coverage and a readOnlyHint, the description is adequate. With no output schema, a brief note on what is returned or on not-found behavior would round it out, but nothing essential 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% and the single id parameter is fully documented in the schema, so the description cannot add much. It confirms the id-based lookup but provides no format or range nuance. Baseline 3.

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

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

States a specific verb (Fetch) and scope (a single resource by id), and the endpoint line 'GET /volumes/{id}' pins down the resource even though the prose itself says only 'resource'. An agent can distinguish this from the list_volumes sibling via the 'single' vs. list pattern.

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 — fetch one by id — but the description never says when to prefer this over hetzner_list_volumes or what happens if the id does not exist. 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?

readOnlyHint=true already establishes this is a safe read. The description adds that both managed and uploaded certificates are returned and that expiry is included, which is modest but genuine value beyond the annotations. It says nothing about pagination behavior or result limits, which the schema's page/per_page params imply exist.

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

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

Two short sentences, the substantive scope statement first and the API mapping second. No filler and nothing buried.

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

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

For a read-only list tool with full schema coverage and annotation-carried safety, the description covers what is returned (cert types, expiry). The only real omission is disambiguating from hetzner_get_certificates, and pagination behavior is left implicit.

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

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

Schema description coverage is 100%, so name, page, per_page, and label_selector are already fully documented in the schema. The description adds no parameter-level meaning, so the baseline 3 applies.

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

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

States a specific verb and resource ('List TLS certificates') and adds scope ('managed or uploaded, and their expiry'), which tells the agent what the results contain. It does not, however, distinguish itself from the closely named sibling hetzner_get_certificates, leaving an ambiguity the agent must resolve 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 when-to-use guidance, no exclusions, and no routing to an alternative. With hetzner_get_certificates sitting in the sibling list, the absence of any 'use this to enumerate, use get_certificates to fetch one' distinction is a real gap.

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

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

The readOnlyHint annotation already establishes this is a safe, non-mutating read, so the bar for the description is lower. The description adds that the response includes rules and resource bindings, which is useful return-shape context, but says nothing about pagination behavior or result-size 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, zero waste, with the most informative content (what gets returned) front-loaded and the upstream API reference appended as compact provenance.

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

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

With no output schema, the description carries the burden of describing the return payload and does so briefly (firewalls, rules, applied resources). The remaining gap is the lack of differentiation from hetzner_get_firewalls and any pagination note, both minor for a simple read-only list.

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 with types, bounds, and examples. The description adds no parameter-level detail beyond what the schema provides, which is the expected baseline 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 (List) and resource (firewalls) and even sketches the payload — rules and applied resources. However, it does not distinguish itself from the sibling hetzner_get_firewalls, so an agent cannot tell from the description alone when to list versus fetch a single firewall.

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

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

No when-to-use guidance, no mention of the filtering options (name, label_selector) as selection criteria, and no routing to or away from hetzner_get_firewalls. The agent must infer usage entirely from the 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 description has a lower bar. It adds that results include the server assignment mapping, which is real behavioral context, but it says nothing about pagination or how many records come back by default despite exposing 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 terse sentences with zero padding; the resource and its notable return detail are front-loaded before the endpoint reference. 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 read-only list tool with a fully documented schema and no output schema, the description covers what the tool returns (IPs plus server assignment) adequately. It is slightly thin on pagination behavior, which matters for a tool whose schema exposes paging, but overall it is complete enough to call correctly.

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

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

Schema description coverage is 100% and each of the four parameters (name, page, per_page, label_selector) is documented in the schema with constraints and an example. The description adds no parameter-level meaning 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 (List) and resource (floating IPs) and adds the useful scope detail that each IP's server assignment is included, plus the underlying endpoint GET /floating_ips. It does not, however, distinguish itself from the sibling hetzner_get_floating_ips, leaving the list-vs-get split 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?

There is no when-to-use guidance, no statement of prerequisites, and no pointer to alternatives such as hetzner_get_floating_ips for a single resource. The 'List' verb is the only signal about context, and nothing tells the agent when this tool is the wrong choice.

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 known. The description does add the useful clarification that results include snapshots and backups, not just system images, but 'Hetzner Cloud: GET /images.' is just an endpoint mapping and conveys no extra behavior such as pagination defaults or filtering semantics.

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 purpose. The trailing 'Hetzner Cloud: GET /images.' earns marginal value as an API reference but is not the leading information an agent needs.

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 6 optional filters, a 100%-covered schema, and no output schema, the description is sufficient to know what is returned and what can be filtered. It could mention that results are paginated, but nothing critical is missing.

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

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

Schema description coverage is 100%, so all six filters (name, type, architecture, label_selector, page, per_page) are already documented in the schema. The description adds no syntax, defaults, or filter-combination guidance beyond that, 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 ('List') plus resource ('OS images, snapshots and backups') and the scope of what they're for ('you can boot or restore from'). It is clearly distinct from the mutating siblings like hetzner_create_image_from_server, though it never names a sibling to route against.

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 'you can boot or restore from' hints at the scenario (finding an image to provision a server), but there are no explicit when-to-use, when-not-to-use, or alternative conditions given. Usage is implied 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?

The readOnlyHint annotation already establishes this as a safe, non-mutating read, so the description's burden is low. It usefully discloses the shape of each returned record (services, targets, health status), which annotations do not cover. It still says nothing about pagination behavior, default page size, or how large result sets are returned.

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

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

Two short sentences, front-loaded with the action and the returned data. The trailing 'Hetzner Cloud: GET /load_balancers' is a compact API reference that earns its place for grounding, with no filler text.

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

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

For a simple read-only list tool with no output schema, the description covers the action and the returned fields, and the schema covers all filters and paging. The only real gap is the lack of disambiguation from hetzner_get_load_balancers and unknown paging defaults.

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 fully documented in the schema, including the label selector syntax. The description adds no parameter-level detail beyond that, making the baseline 3 correct.

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

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

The description states a specific verb and resource ('List load balancers') and even enumerates what each entry contains (services, targets, health status), so the agent knows what it is getting back. It does not, however, distinguish itself from the sibling hetzner_get_load_balancers, which an agent could easily confuse with a pure list call.

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

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

There is no when-to-use statement, no mention of the filtering parameters, and no routing against hetzner_get_load_balancers (singular fetch) or other list_* siblings. Usage is only weakly inferable from the word 'List' and the presence of name/label_selector params.

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 bar is lower. The description adds that results are informational metadata (city, country, network zone) about where servers can run, which is useful context, but says nothing about result volume, stability, 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 with zero waste: the resource and its returned fields are front-loaded, and the API mapping trails as supplementary 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 read-only list tool with no output schema, annotations covering the safety profile, and full parameter coverage, the description does enough: it identifies the resource and the fields returned, compensating for the absent output schema. Only the usage guidance is genuinely thin.

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

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

Schema description coverage is 100% (the single 'name' parameter is documented as a filter with an example, fsn1), so the schema carries parameter semantics. The description adds no further meaning beyond noting that locations are where servers run, which is the expected baseline 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?

The description gives a specific verb (List) and resource (datacentre locations), and even names the fields returned (city, country, network zone) plus the underlying API route. An agent can tell it apart from read/write siblings like hetzner_get_server, though the 'list vs get' distinction is left to naming conventions rather than stated 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?

There is no when-to-use guidance, no mention of related reference-data siblings (hetzner_list_server_types, hetzner_get_pricing), and no indication of when the optional name filter is worth using. The agent gets no help choosing this tool over alternatives.

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

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

The readOnlyHint annotation already establishes that this is a safe read, and the GET /networks reference reinforces that. The description adds useful context about what a network record contains (IP ranges, subnets, routes), but says nothing about pagination behavior or result-set size, which matters given 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, zero filler, with the resource and returned data front-loaded and the API endpoint trailing as supporting detail. Nothing should be cut.

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 endpoint with full schema coverage and a readOnlyHint, the description is nearly sufficient: it conveys scope, returned fields, and the backing API. It only misses pagination/result-size expectations and any list-vs-get disambiguation.

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

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

Schema description coverage is 100%, so every parameter (name, page, per_page, label_selector) is already documented in the schema, including the label-selector idiom. The description adds no parameter-level meaning beyond that, 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 ('List') and resource ('private networks') and names the fields returned (IP ranges, subnets, routes), plus the underlying API call (GET /networks). This is enough to separate it from most siblings, though it never explicitly contrasts with the singular hetzner_get_networks.

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 verb 'List' suggests enumerating all networks, but there is no statement of when to prefer this over hetzner_get_networks, nor any hint that name/label_selector can narrow results. A reader can infer the intent but gets no 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 tells the agent this is a safe read. The description adds a little useful context by noting it returns 'their assignments' and naming the underlying endpoint, but discloses nothing about pagination behavior or result 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, front-loaded sentences with no filler. The endpoint reference is marginally redundant but the structure is tight and scannable.

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, so the description could carry more of the return-value burden; it only hints that assignments are included. Params are fully covered by the schema, keeping this adequate but not complete for a list tool with pagination.

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. The description adds no syntax or filtering guidance beyond the schema, matching the baseline for fully-covered params.

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 (primary IPs) plus their assignments, so the basic purpose is unambiguous. However, it never distinguishes itself from the sibling 'hetzner_get_primary_ips', leaving the list-vs-get distinction 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?

No when-to-use, when-not-to-use, or alternative is given. With 'hetzner_get_primary_ips' sitting in the sibling list, the description should route the agent but does not.

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

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

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds the underlying endpoint (GET /servers) but says nothing about pagination behavior, default page size, or result volume — the main behavioral facts an agent needs for a paginated list 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?

Two tight sentences: scope and filters first, endpoint last. Nothing is redundant or buried, and every clause 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 read-only list tool with full schema coverage and no output schema, the description is nearly sufficient. The one real gap is pagination: page/per_page exist in the schema but the description never notes that results are paged or how to iterate.

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

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

Schema description coverage is 100%, so every parameter (name, page, per_page, status, label_selector) is already documented in the schema. The description merely echoes the filter trio and adds no semantics beyond it, 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 and resource ("List the servers") and scopes it to "the token's project." The plural/singular contrast with sibling hetzner_get_server is inferable, but the description never explicitly names that sibling or the list_* peers to sharpen the boundary.

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?

"Optionally filtered by name, status or a label selector" implies when the filters are useful, but there is no explicit when-to-use vs. hetzner_get_server, no guidance on when filtering is better than fetching everything, and no mention of how pagination should be driven.

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 description's main added value is noting the returned fields and citing the underlying endpoint GET /server_types. It does not mention pagination behavior or defaults, but with annotations covering the safety profile this is adequate.

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

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

A single front-loaded sentence carries the payload (what it lists, what fields it returns, when to use it), followed by a short API reference. No filler, no redundancy.

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

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

For a read-only, zero-required-parameter list tool with no output schema, the description covers purpose, return contents, and the create-server precondition. Pagination behavior is left to the schema's page/per_page fields, so nothing critical is missing, though a note on default page size would close the last 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% — all three optional parameters (name, page, per_page) are documented with examples and bounds in the schema itself. The description adds no parameter-level 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?

States a specific verb and resource ("List the available server types") and enumerates the returned fields (cores, memory, disk, hourly and monthly prices), which cleanly separates it from sibling list tools like hetzner_list_locations or hetzner_list_images. An agent can identify it 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?

"read this before creating a server" gives an explicit precondition linking it to hetzner_create_server, which is the key routing signal. It stops short of naming alternative tools or when-not to use it (e.g. use hetzner_get_pricing for broader pricing data), so it is clear but not exhaustive.

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 agent knows this is a safe read. The description adds the upstream endpoint (GET /ssh_keys) but does not disclose pagination behavior, return shape, or filtering semantics beyond what the schema states. With annotations carrying the safety profile, this is adequate but not rich.

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

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

Two short sentences that front-load the action and resource, then the upstream endpoint. The endpoint reference is mildly redundant but cheap; 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 simple read-only list tool with full schema coverage and annotations carrying the safety profile, the description is nearly complete. With no output schema, the only minor gap is not hinting at the returned fields, which is acceptable for a list operation.

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

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

Schema description coverage is 100%, with each of the four parameters (name, page, per_page, label_selector) already documented in the schema. The description adds no parameter syntax or semantics 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?

States a specific verb and resource ('List the SSH public keys') and adds useful scope ('available to inject when creating a server'). It does not explicitly distinguish itself from the sibling hetzner_get_ssh_keys, relying on the reader to infer list-vs-single from naming.

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 'available to inject when creating a server' implies the context in which the result is consumed, giving an implied use case. However, there is no explicit when-to-use/when-not guidance and no named alternative (e.g. hetzner_get_ssh_keys) to route between.

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 endpoint mapping and the shape of the returned items, but says nothing about pagination behavior or result limits (per_page max 50 is only in the schema).

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

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

Two short sentences, front-loaded with the resource and its returned attributes, then the endpoint. 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?

Given no output schema, the description usefully previews the returned fields and the underlying endpoint. It remains slightly incomplete on pagination semantics for a paginated list endpoint, but that gap is minor.

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 with examples and bounds. The description adds no parameter-level 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 ('List block-storage volumes') and even names the returned fields (size, attached server), which separates it from hetzner_get_volumes. It doesn't explicitly contrast with the sibling, but the list/get distinction is discernible.

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 'List' verb and the inclusion of the endpoint 'GET /volumes'. There is no statement of when to prefer this over hetzner_get_volumes or how the filters (name, label_selector) should drive selection.

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

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

Adds genuinely useful context beyond annotations: the call is asynchronous and returns an action id that must be polled via hetzner_get_action, plus the underlying API endpoint. It does not explain implications of the destructiveHint, but the async workflow disclosure is the more important behavioral fact here.

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 action, then the return/polling contract, then the endpoint. 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 what it does, the precondition, what it returns, and how to follow up. Nothing an agent needs to invoke it correctly is missing.

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

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

One parameter with 100% schema description coverage, so the schema already documents server_id ('The server to start.'). The description adds nothing parameter-specific; 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 (power on a server) with the state precondition (stopped). An agent can separate it from hetzner_reboot_server and hetzner_shutdown_server from the description 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?

The phrase 'stopped server' gives the condition that selects this tool, and the description routes the agent to hetzner_get_action for the follow-up. It does not explicitly contrast with the reboot/shutdown siblings, but the state precondition makes the intent clear.

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

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

Annotations declare destructiveHint=true, and the description usefully adds that the reboot is graceful via ACPI, which distinguishes it from a hard power cycle. However, it omits real behavioral consequences such as service interruption, whether the call is asynchronous and returns an action object, and whether it blocks until the server is back.

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 zero filler, front-loading the action and its graceful nature before the API endpoint detail. Every clause 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 one-parameter mutation with no output schema, the definition covers the action and mechanism but leaves the async/action-response behavior and the relationship to sibling lifecycle tools unstated. Adequate but with visible gaps.

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

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

Schema description coverage is 100% with a single required server_id documented as 'The server to reboot.' The description adds nothing beyond that, so the baseline 3 is appropriate for a one-parameter tool whose schema already does the work.

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

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

States a specific verb and resource ('Reboot a server') and adds mechanism detail ('gracefully via ACPI') plus the underlying API endpoint. It does not explicitly contrast itself with near-siblings like hetzner_shutdown_server or hetzner_poweron_server, so an agent must still infer the distinction.

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

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

No when-to-use, when-not-to-use, or alternative guidance is given, even though the sibling list contains hetzner_shutdown_server and hetzner_poweron_server, which are the obvious competing actions. The agent must choose among reboot/poweron/shutdown entirely on its own.

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 supply only destructiveHint=true, so the description carries most of the burden and delivers real value: it discloses the ACPI/graceful mechanism, the preference ordering against hard power-off, the billing consequence of a stopped-but-existing server, and the underlying API call. It omits that the operation is asynchronous and typically returns an action to poll via get_action.

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

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

Three tight sentences, front-loaded with the action and mechanism before the preference and the cost caveat; every sentence carries information. The trailing raw endpoint string is marginally useful for debugging but is the least essential part.

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 mechanism, safety posture, and cost consequences well. The missing piece is post-call behavior — that shutdown is asynchronous and the server may take time to actually stop, which an agent needs to set expectations.

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?

One parameter with 100% schema description coverage ('The server to shut down.'), so the schema already fully documents the input. The description adds no id format, ownership, or validation detail beyond that, which is the expected baseline when coverage is complete.

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 mechanism — 'Ask the guest OS to shut down gracefully via ACPI' — which is far more precise than the title 'Shut down a server'. It contrasts with a hard power-off, though it does not name a sibling tool (reboot_server, poweron_server) to anchor the distinction.

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

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

'Prefer this over a hard power-off' gives a clear selection rule for the graceful-vs-forceful choice, and the cost note hints at when stopping is insufficient (deleting is required to stop billing). No explicit exclusions relative to siblings like reboot_server or poweron_server are given.

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