hetzner-mcp

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

With no annotations, the description carries the full behavioral burden for what is clearly a mutating operation. It does not say whether the operation is idempotent, whether assigning over an already-assigned IP errors or overwrites, what permissions are needed, or what the response contains.

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

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

A single front-loaded sentence with zero filler or redundancy. It is efficient, though its brevity is a byproduct of under-specification rather than deliberate tightness.

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

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

For a two-required-parameter mutation tool with no annotations and no output schema, the description omits nearly everything an agent would need: required preconditions, error behavior, and post-assignment state. The schema covers the parameters, but the behavioral surface is unaddressed.

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

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

Schema description coverage is 100%: both 'id' (floating IP id) and 'server' (server id) are documented in the schema. The description adds nothing 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?

The description names a specific verb (assign) and resource (floating IP) plus the target (a server), which is immediately distinguishable from the sibling cloud_unassign_floating_ip. It stops short of any explicit sibling differentiation or scope qualifiers, but the core purpose is unambiguous.

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

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

There is no indication of when to use this tool versus cloud_unassign_floating_ip, cloud_create_floating_ip, or cloud_assign_primary_ip, and no prerequisites are stated (e.g., the IP must exist and be unassigned, the server must exist). Usage is left entirely to inference 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?

No annotations are provided, so the description carries the full burden. It helpfully discloses the required server state (off, implying a forced/blocked operation otherwise), but says nothing about permissions, reversibility, or what happens to a pre-existing primary IP.

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

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

Two tight sentences with the action front-loaded and the constraint second, no filler. Well-sized for a simple assignment tool.

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

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

For a mutation tool with no annotations and no output schema, the description covers the action and a key precondition but omits permission requirements, side effects on existing IPs, and response behavior. Adequate but with clear gaps.

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

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

Schema description coverage is 100%, so the schema already documents id, assignee_id and assignee_type. The description only adds that the assignment targets a server, which is baseline reinforcement rather than new detail.

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

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

Clear specific verb+resource: assign a primary IP to a server. It is distinguishable from cloud_assign_floating_ip by the resource name, though it does not explicitly call out that sibling.

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

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

Provides a crucial precondition ('the server must be off'), which is genuine usage guidance, but gives no guidance on when to choose this over cloud_assign_floating_ip or cloud_create_primary_ip, nor what to do if a primary IP is already assigned.

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?

No annotations are provided, so the description carries the full behavioral burden. It does not disclose permissions, prerequisites such as volume/server state, side effects, idempotency, automount behavior, or failure modes.

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

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

One front-loaded sentence with no wasted words. However, it is under-specified for a mutation tool rather than appropriately concise given the missing behavioral context.

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

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

For a mutation tool with no annotations, no output schema, and one undocumented parameter, the description is too thin. It never states prerequisites, side effects, or what automount does.

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 id and server (67% coverage), but the description adds no parameter meaning. The automount parameter is undocumented in both the schema and the description.

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

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

States a specific verb ('attach') and resource ('volume') with a target ('server'), clearly distinct from detach/create/delete/list siblings. However, it provides no explicit sibling comparison or scope conditions.

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, prerequisites, or alternatives are given. The agent must infer that this is for attaching an existing volume to a server, likely after creation and before detach.

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?

No annotations are provided, so the description carries the full behavioral burden. It only adds that rules are included and that the operation is free; it does not disclose permissions, immediate effect, reversibility, or what happens when apply_to is omitted.

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

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

The description is extremely short and front-loaded, with no wasted wording. However, the terse 'Free.' fragment is useful but not structurally integrated into a fuller sentence that would earn 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 mutation tool with no annotations and no output schema, the description is too minimal. It does not explain required vs optional parameters, default behavior for rules or apply_to, or any operational side effects the agent needs to call it safely.

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

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

Schema description coverage is 100%, so the schema itself documents name, rules, and apply_to. The description adds 'with rules' but no syntax, defaults, or constraints 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 and resource: 'Create a firewall with rules.' This is clear and directly distinguishes the action from sibling list/delete operations, but it does not differentiate from other create tools such as cloud_create_network beyond the resource name.

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

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

No when-to-use guidance, prerequisites, or alternatives are provided. 'Free' is a pricing note rather than usage context, leaving the agent to infer when this tool is appropriate.

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

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

With no annotations, the description must carry the full behavioral burden. It does disclose real traits beyond structured data: that the operation is billed and gated behind confirm=true, which is valuable. However it omits what the IP is attached to by default, reversibility, permissions, and how the created IP is identified.

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 with no filler; the cost warning is not buried. It is terse to the point of choppiness but every sentence carries information.

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

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

For a 6-parameter, cost-incurring mutation with no annotations and no output schema, the description is only minimally sufficient. It covers billing and the confirm gate but says nothing about the remaining parameters, defaults, or what the caller receives 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?

Schema coverage is 67%, so the schema already documents type, server, home_location, and confirm. The description only reinforces the confirm/billing semantics, adding no syntax or format detail beyond the schema's own 'Must be true. A floating IP costs money.' Baseline 3 applies.

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

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

States a specific verb+resource ('Create a floating IP'), which is clear and unambiguous. It does not differentiate from near-siblings like cloud_create_primary_ip or cloud_assign_floating_ip, but the resource noun alone is specific enough to route correctly.

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

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

There is no when-to-use guidance, no mention of prerequisites beyond confirm, and no routing to alternatives (cloud_assign_floating_ip, cloud_create_primary_ip). The 'confirm true' note is a precondition, not usage guidance.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses a cost side effect ('Billed') and the mandatory confirm flag, which is genuine non-schema context. However it omits that this is a mutating/state-creating operation, any permission requirements, and what happens on failure.

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

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

Three terse fragments, front-loaded with the action and then the critical billing/confirm constraints. Efficient, though the extreme brevity shades into under-specification rather than pure conciseness.

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 9-parameter create tool with nested objects, no annotations, and no output schema needs substantially more than this. The description leaves the agent without guidance on most parameters or on the operation's side effects and failure modes.

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 67%, and the description only echoes the confirm parameter that the schema already documents ('Must be true. A load balancer costs money'). The nested targets, services, and algorithm objects plus public_interface are undocumented in both places, and the description does nothing to compensate.

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

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

States a specific verb and resource ('Create a load balancer'), which plainly separates it from the delete/list siblings. It stops short of naming or contrasting an alternative create path, but the core purpose is unambiguous.

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

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

The description supplies one real precondition ('Requires confirm true') which tells the agent how to invoke it successfully. It says nothing about when to prefer this tool, prerequisites like networking/location setup, or what alternatives exist.

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?

No annotations are provided, so the description carries the full behavioral burden. 'Private' and 'Free' are the only behavioral disclosures; there is no information about authentication requirements, whether the network is immediately usable, how optional subnets behave, or what happens if the name collides. For a creation tool with zero annotation coverage this is a substantial 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 short sentences with no padding, and the core action is front-loaded. Both sentences carry content ('private' narrows scope, 'Free' is a real cost disclosure), though the extreme brevity reflects under-specification rather than disciplined editing.

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

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

This is a mutation/creation tool with no annotations, no output schema, and four parameters, yet the description explains almost nothing an agent needs to call it correctly. Nothing covers whether subnets can be added later, whether the network is immediately usable, or what the response contains.

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 75%, below the high-coverage threshold, and one parameter (expose_routes_to_vswitch) has no description at all. The description adds no parameter meaning whatsoever - no syntax for ip_range, no explanation of subnet structure or the expose_routes flag - so it fails to compensate for the coverage gap.

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 verb and resource ('Create a private network'), so the basic action is identifiable, but it essentially restates the title 'Create a network' with the word 'private' added. It does not distinguish this tool from siblings like cloud_create_server, cloud_create_firewall, or cloud_create_volume beyond the resource noun.

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 tool versus alternatives such as cloud_create_server's networking options, nor any prerequisites. 'Free' hints at a cost consideration but is not framed as usage guidance. The agent gets no explicit when/when-not 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?

No annotations are provided, so the description carries the full behavioral burden. It discloses one useful trait — that the operation is 'Free' (no cost) — but says nothing about permissions, whether creation is idempotent, what happens on duplicate names, or what side effects occur. For a mutation tool with zero annotation coverage, this is a substantial 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?

It is extremely short and front-loaded, with no wasted words, but the 'Free.' fragment reads as an afterthought rather than structured disclosure. Conciseness here borders on under-specification for a 3-parameter mutation tool.

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

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

With no annotations, no output schema, a nested 'labels' object, and an undocumented enum-like 'type' parameter, the description is too thin to be complete. An agent lacks the behavioral and usage context needed to call this mutation tool confidently.

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 67%, and the description adds no meaning beyond the schema. The 'type' parameter is documented only as 'For example spread' with no enum, and 'labels' is completely undocumented in both schema and description. The description does not compensate for the coverage gap.

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 placement group'), which is enough for an agent to distinguish it from the create_* siblings by resource type. It stops short of explaining what a placement group is or how it differs functionally from other create operations, but the core purpose is unambiguous.

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

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

There is no guidance on when to use this tool versus alternatives, no mention of prerequisites (e.g., needing a location or server context), and no exclusions. The agent is left to infer everything about usage context from the name alone.

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

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

With no annotations, the description carries the full burden. It valuably discloses that the operation is billed and gated behind confirm=true, but omits permission requirements, reversibility, and any rate/lifecycle behavior. The cost disclosure is meaningful context beyond the schema, but coverage is incomplete for a mutation tool.

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 clipped sentences with zero waste, front-loaded with the core action. The telegraphic style ('Billed. Requires confirm true.') is efficient, though slightly terse for a money-spending operation.

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

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

The description covers the key decision points an agent needs: purpose, cost, the confirm gate, and the two creation modes. With a fully documented schema, the main remaining gap is that no return value is described and there is no output schema, but nothing critical to correct invocation 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 every parameter is already documented. The description only restates location-for-standalone and assign-to-server usage, adding no syntax or format meaning beyond the schema. Baseline 3 is appropriate.

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

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

States a specific verb and resource ('Create a primary IP') and clarifies the two creation modes (assigned vs. standalone). It does not distinguish this from the sibling cloud_create_floating_ip, which an agent may confuse with a primary IP, so it stops short of full sibling differentiation.

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

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

The 'Assign to a server, or create standalone with a location' clause implies the two usage paths, and 'Requires confirm true' signals a prerequisite. However, there is no explicit comparison against alternatives like cloud_create_floating_ip or cloud_assign_primary_ip, leaving the choice to inference.

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

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

With no annotations, the description carries the full behavioral burden and does well: it discloses that the operation is billed, requires confirm=true, and previews live hourly/monthly pricing before committing. It stops short of covering auth requirements, failure/reversibility behavior, or what is returned.

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

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

Three tight sentences, zero waste, with the cost/confirm constraint front-loaded before the optional-parameter list. Every sentence earns its place.

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

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

For an 11-param mutating tool with no annotations and no output schema, the description covers the critical cost and confirm gate plus the optional attachments. Remaining gaps (return value shape, error behavior) are less essential given a rich schema, but not fully closed.

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

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

Schema coverage is 100%, so the schema already documents all 11 parameters thoroughly. The description restates the optional attachment params (SSH keys, network, firewalls, user_data, labels) but adds no format or syntax beyond the schema, so baseline 3 applies.

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

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

States a specific verb and resource ("Create a Hetzner Cloud server") that unambiguously distinguishes it from the many sibling creation tools like cloud_create_volume or cloud_create_network without needing 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?

It surfaces a key usage prerequisite (confirm must be true, operation is billed, price shown first), but gives no explicit when-to-use/when-not guidance or alternatives relative to siblings. Usage is implied rather than framed.

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?

No annotations are provided, so the description carries the full disclosure burden. 'Free' is a useful cost signal, but nothing is said about authentication/permissions required, idempotency or duplicate-name handling, or what the operation returns. For a mutation tool with zero annotation coverage this is a substantial 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 very short sentences, front-loaded with the action. The 'Free.' fragment is low-cost and does convey a pricing trait, though it reads as an afterthought rather than structured guidance.

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 write tool with no annotations, no output schema, and an undocumented nested-object parameter, the description is far too thin. It omits auth requirements, failure modes, and return behavior that an agent would need to invoke it reliably.

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 67% and the description mentions no parameters at all. The 'labels' parameter is a nested object with no description in either the schema or the description, so it is completely undocumented. The description adds no meaning beyond the schema.

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

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

The description states a specific verb and resource ('Add an SSH public key'), which cleanly separates it from the list_ssh_keys and delete_ssh_key siblings. It does not, however, explicitly name those siblings or clarify scope (e.g. account-level vs. project-level key).

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 cloud_list_ssh_keys/cloud_delete_ssh_key, nor any prerequisites or preconditions for creation. 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?

No annotations are provided, so the description carries full burden. It usefully discloses that the operation is billed and that 'confirm true' is required — critical behavioral context for a paid mutation. It doesn't state reversibility, idempotency, or permission needs, but the billing/confirm disclosure is the most important trait 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 cost, then placement options. Efficient, though the placement clause is compressed to the point of ambiguity (server vs. location as alternatives).

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

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

For a 7-param paid mutation with no annotations and no output schema, the description covers the essential cost/confirm gate but omits permission requirements, what the returned volume looks like, and clear guidance on choosing server vs. location. Adequate but with clear gaps.

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

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

Schema description coverage is 100%, so the schema already documents all seven params including the confirm flag's billing note. The description restates the confirm requirement but adds no syntax or semantics beyond the schema, so baseline 3 applies.

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

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

States a specific verb+resource ('Create a Hetzner Cloud volume'), clearly distinguished from sibling operations like cloud_delete_volume or cloud_attach_volume. The core action is unambiguous, though the trailing 'Attach to a server or place in a location' reads like usage guidance rather than purpose.

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

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

Implies how to place the volume (server vs. location) but doesn't explicitly say when to use this tool versus cloud_attach_volume or when to prefer server-attach over location. No when-not guidance or prerequisites beyond the confirm flag.

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?

With no annotations, the description carries the full burden, and it does disclose the two most important traits: the operation is destructive and is gated behind confirm true, plus the cost angle ('free'). It omits irreversibility, permission requirements, and side effects on servers referencing the firewall.

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 the action front-loaded and zero filler; the destructive/confirmation constraints follow immediately. 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 mutation tool with no annotations and no output schema, the essential invocation facts (destructive, confirm gate, free) are present, but reversibility, resulting state, and any impact on dependent resources are unaddressed.

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

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

Schema coverage is exactly 50% – id is documented in the schema, but confirm has no schema description. The description compensates by specifying that confirm must be true, resolving the undocumented parameter's required value.

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 clear verb and resource ('Delete a firewall'), matching the title and distinguishing it from siblings like cloud_create_firewall and cloud_list_firewalls by operation type. It does not, however, explicitly differentiate itself from other delete tools or call out the sibling relationship.

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

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

It states the invocation requirement (confirm true) but gives no when-to-use guidance, no exclusions, and no reference to alternatives such as cloud_list_firewalls for verifying the target first. An agent learns how to call it, not when it should.

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?

With no annotations, the description carries the full burden and does a good job: it discloses that the operation is destructive, that it is free of charge, that confirmation is mandatory, and that a dependent state (assigned) blocks it. It omits nothing critical for a delete, though it doesn't mention reversibility or auth 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?

Three short sentences, front-loaded with the core action, then cost/destructiveness, then the prerequisite. The stray 'Note. an assigned IP' punctuation is slightly awkward but costs no meaning.

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

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

For a two-parameter destructive tool with no annotations and no output schema, the description covers destruction, cost, confirmation requirement, and the unassign dependency — everything an agent needs to call it correctly. Only minor gaps (auth/scope) remain.

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

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

Schema coverage is only 50% (only 'id' is documented). The description compensates by explaining the undocumented 'confirm' parameter ('requires confirm true'), which the schema leaves as a bare boolean. The 'id' parameter needs no further explanation than the schema already gives.

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 ('Delete a floating IP') that clearly distinguishes it from the many list_* and create_* siblings. It does not name the closely related cloud_unassign_floating_ip or cloud_create_floating_ip directly, but the prerequisite note implicitly routes to unassign.

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 an explicit precondition ('an assigned IP must be unassigned first') and a required calling condition ('requires confirm true'). It lacks an explicit alternative-tool pointer, but the when-to-use context is clear from the prerequisite.

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?

With no annotations, the description carries the full burden and does disclose two meaningful traits: the operation is free and it is destructive, plus the confirm-true guard. It says nothing about irreversibility, what happens to attached resources or dependent services, or permission requirements.

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

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

Two short sentences with the destructive/cost warning and the confirm requirement front-loaded and nothing wasted. The phrasing is terse but complete.

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

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

For a simple two-parameter delete with no output schema, the description covers the essentials an agent needs: it is destructive, it is free, and confirm must be true. Only the consequence of deletion (irreversibility, cascading effects) is missing.

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

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

Schema coverage is 50% (id documented, confirm not). The description partially compensates by telling the agent that confirm must be true, which the schema leaves as a bare boolean with no description. It adds no format or id-resolution detail beyond that.

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

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

States a specific verb (Delete) and resource (load balancer), matching the title and clearly distinct from the sibling cloud_create_load_balancer. It does not explicitly name alternatives or note that the id must reference an existing LB, so it stops short of a 5.

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

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

No when-to-use or when-not-to-use guidance is given, and no alternatives are named. The only condition supplied is the mechanical prerequisite 'requires confirm true', which is a parameter requirement rather than usage guidance.

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

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

With no annotations, the description carries the full burden, and it does add real context: the operation is flagged as destructive, free of cost, and gated behind a confirm flag. It stops short of disclosing what happens to attached members, whether the action is reversible, or what permissions are required.

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 clauses with zero filler, and the identity of the operation is front-loaded ahead of the cost, destructiveness, and confirmation details. Nothing needs to be trimmed.

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

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

For a destructive tool with no annotations and no output schema, the description covers the essential safety signal and the confirm gate, which is roughly minimum viable. It omits the downstream effects on network members and the irreversibility of deletion, which an agent would need before calling it.

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

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

Schema coverage is only 50% – 'id' is documented in the schema, but 'confirm' has no schema description. The description compensates by stating that confirm must be true, giving the otherwise undocumented parameter meaning and a required value.

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

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

The description states a specific verb and resource ('Delete a private network'), which cleanly separates it from the many sibling delete tools for volumes, servers, firewalls, and load balancers. An agent can identify the operation without opening the schema.

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

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

It states a precondition ('requires confirm true') but never says when to use this versus alternatives, nor what conditions should precede deletion. No exclusions or routing guidance to siblings are given, leaving usage to inference 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?

With no annotations, the description carries the full burden and does disclose the important traits: the operation is destructive, free (no billing impact), and requires an explicit confirm flag. However, it omits material behavior such as what happens to servers still assigned to the group, whether the group must be empty, or whether the call is idempotent.

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, and the key operational fact (destructive + confirm requirement) is front-loaded right after the purpose.

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

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

For a simple 2-parameter mutation with no output schema or annotations, the description covers purpose, cost, destructiveness, and the confirm requirement. It still leaves gaps about side effects on member servers and error behavior, which an agent running this destructive call would benefit from knowing.

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

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

Schema coverage is only 50% — 'id' is documented but 'confirm' has no schema description. The phrase 'requires confirm true' compensates by telling the agent the flag must be set true to proceed, adding real meaning beyond the bare boolean type, though it doesn't explain the failure mode when confirm is false/absent.

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

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

States a specific verb+resource ('Delete a placement group') that is immediately distinguishable from sibling cloud_create_placement_group, cloud_list_placement_groups, and the other cloud_delete_* tools that each name their own resource.

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

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

No explicit when/when-not guidance or named alternatives, but the 'Free but destructive' note implies the cost/safety tradeoff an agent should weigh. Usage is largely self-evident from the verb, so guidance 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?

With no annotations present, the description carries the full burden and does well: it discloses that the operation is destructive, that it is free, and that confirm=true is mandatory. It omits permission/auth requirements and whether deletion is irreversible, which a mutation tool would ideally state.

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

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

Three tight sentences, front-loaded with the action, then cost/safety, then precondition. No filler and every clause conveys distinct 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?

No output schema or annotations exist, so the description must stand alone; it covers destructive intent, cost, the confirm flag, and the unassign prerequisite, which is nearly everything needed for a simple delete. Only auth/permission and post-deletion state are absent.

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

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

Schema coverage is only 50% — 'id' is documented in the schema but 'confirm' is not — and the description compensates by stating 'requires confirm true', which explains both the parameter's meaning and its required value. That closes the coverage gap for the undocumented parameter.

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

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

States a specific verb and resource ('Delete a primary IP'), which is unambiguous against list/create siblings. It does not explicitly name cloud_unassign_primary_ip as the alternative, though the phrase 'must be unassigned first' implicitly separates the two.

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 a clear precondition for calling: the IP must be unassigned before deletion, which is the key when-to-use rule for this tool. It does not spell out fallback alternatives or error behavior, so it stops just short of the top tier.

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?

With no annotations, the description carries the full burden and does well: it discloses that deletion is irreversible, that it stops billing, that a confirm flag is mandatory, and that auto-created primary IPs are released shortly after. It omits permission requirements and any dependency handling (e.g. attached volumes), keeping it short of a 5.

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

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

Two tight sentences with zero filler; the destructive nature and confirm requirement are front-loaded ahead of the secondary IP-release detail. Every clause carries 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 two-parameter destructive tool with no annotations and no output schema, the description covers the key risks: irreversibility, billing impact, the confirm gate, and one notable side effect. Minor gaps remain around prerequisites (server state, dependent resources), but nothing critical for correct invocation is missing.

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

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

Schema coverage is already 100%, so the baseline is 3, but the description adds real semantic weight by explaining the purpose of confirm (gate for permanent destruction) and clarifying the downstream billing/IP effects. It does not add syntax beyond what the schema documents for id.

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 + resource ('Delete a Hetzner Cloud server') that immediately separates it from siblings like cloud_delete_volume, cloud_delete_network, or cloud_delete_primary_ip. An agent knows exactly which resource is targeted 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?

States the precondition (confirm true) and the consequence, which implies when to use it, but names no alternatives and gives no explicit when-not guidance (e.g. powering off first, or deleting attached volumes/IPs separately). Usage is inferred rather than directed.

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?

With no annotations, the description carries the burden and does well by warning the operation is 'destructive' and requires 'confirm true'. It does not explain idempotency, error behavior for invalid IDs, or consequences beyond deletion, but the critical safety warning is present.

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

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

Two concise sentences that front-load the core action and immediately follow with critical safety context. No waste, every word earns its place.

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

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

For a simple 2-param deletion tool with no output schema and no annotations, the description covers the essential safety warning and parameter requirement. It lacks details on failure modes or idempotency, but those are not strictly necessary for correct invocation.

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

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

Schema description coverage is 50%: 'id' is documented in the schema, but 'confirm' has no schema description. The description compensates by mentioning 'confirm true', adding meaning beyond the schema for that parameter. Baseline 3 is appropriate given the mixed coverage.

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

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

States a specific verb (Delete) and resource (SSH key), matching the title exactly. It is clearly distinguishable from sibling cloud_create_ssh_key and cloud_list_ssh_keys 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?

The description does not explicitly state when to use this tool versus alternatives or prerequisites like needing an existing key ID. However, the operation is straightforward and the required 'confirm' flag provides some implicit guidance on the destructive intent.

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?

With no annotations present, the description carries the full burden and does disclose meaningful traits: the operation is free of cost and destructive, and requires an explicit confirmation flag. It stops short of stating whether deletion is permanent/irreversible or what happens to attached volumes.

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 clauses, front-loaded with the action then the key constraints. Efficient, though slightly terse given the destructive nature of the operation.

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

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

For a simple 2-parameter mutation with no annotations and no output schema, the description covers the essentials (cost, destructiveness, confirmation) but omits irreversibility, permission requirements, and the fate of dependent resources.

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

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

Schema coverage is only 50% (id is documented, confirm is not), so the description must compensate. It does explain that confirm must be true, adding semantics beyond the bare boolean type, though the exact consequence of omitting it isn't spelled out.

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 ('Delete a volume') that maps cleanly to the tool name. It does not, however, distinguish itself from close siblings like cloud_detach_volume or cloud_list_volumes, so an agent must infer 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?

The description mentions the confirm=true requirement, which is practical usage information, but gives no explicit when-to-use vs detach/delete alternatives and no prerequisites or warnings about attached volumes.

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?

With no annotations provided, the description carries the full disclosure burden. It does the most important part by warning that detachment can cost a running workload its disk and by requiring an explicit confirm flag. It stops short of stating permission requirements or whether the operation is reversible.

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, zero filler. The risk/reason sentence immediately follows and justifies the confirm requirement, so nothing is 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 simple two-parameter mutation with no annotations and no output schema, the description covers the essential risk and the confirm gate. Minor gaps remain: reversibility, auth/permission needs, and whether the server must be stopped first.

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 both parameters are already documented ('Volume id.', 'Must be true.'). The description echoes confirm=true and adds the rationale for it, which is mildly useful, but adds little semantic detail beyond the schema baseline.

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

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

The description opens with a specific verb+resource: 'Detach a volume from its server.' This clearly distinguishes it from the sibling tools cloud_attach_volume and cloud_delete_volume without requiring the schema to be opened.

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

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

It states a concrete prerequisite (confirm must be true) and the condition that motivates it (a running workload may lose its disk). It does not name alternatives or state when-not-to-use, but the gating requirement gives clear invocation 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?

No annotations are provided, so the description carries the full burden. 'Read only' is a useful safety signal, but it says nothing about whether pricing is cached or live, whether it requires any permission scope, or how large the payload is even when verbose is off.

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 the resource and scope front-loaded and no filler. It is arguably too terse rather than bloated, so it loses a point only for the near-redundant 'Read only' tail.

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 three-parameter tool with a nested query object, no output schema, and no annotations should explain more: what the return shape roughly is, how 'full' interacts with verbose, and whether the id lookup returns a single price. The description leaves an agent with meaningful unknowns.

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

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

Schema description coverage is 100% (id, query, verbose are each documented in the schema), so the baseline is 3. The description adds no parameter meaning beyond that, but there is no gap it needs to fill.

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 ('Get full pricing') plus a scope qualifier ('for the account currency'), so an agent knows exactly what is returned. It does not distinguish itself from any sibling, but no sibling in the list covers pricing, so differentiation is largely moot.

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 call this versus alternatives, nor any prerequisites (e.g., whether an account/currency must be configured first). The scope phrase 'account currency' implies context but stops short of stating usage conditions.

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

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

No annotations are provided, so the description carries the full burden. 'Read only' is the only behavioral claim and it merely mirrors what a readOnlyHint would state. Nothing is said about pagination, filter semantics, or what 'verbose' changes in the response.

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, front-loaded with the core action. Nothing is wasted, though 'Read only' sits oddly as a fragment trailing the main clause.

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

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

With three parameters (including a nested free-form filter object), no annotations, and no output schema, the description is too thin. An agent gets no help on the shape of the query filters or the meaning of verbose, which the schema handles only partly.

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

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

Schema description coverage is 100%, so the schema already documents id, query, and verbose. The description adds nothing beyond the schema, which earns the 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 (List) and resource (certificates), and the 'Read only' clause reinforces the operation class. It does not differentiate from the many cloud_list_* siblings (volumes, networks, images, etc.), but the resource is unambiguous, so an agent can pick it correctly.

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 list tools, nor when to pass id versus query versus verbose. The 'Fetch one by id' hint lives only in the schema, not the description.

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

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

No annotations are provided, so the description carries the full burden. 'Read only' is a genuine behavioral disclosure that a safe read is being performed, but for a list tool it omits pagination behavior, result limits, default filtering, and authentication/permission requirements — all material to correct invocation.

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 verb and resource, with zero filler. It is efficient, though the extreme brevity is arguably under-specification rather than tight editing.

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 zero-required-parameter list tool with fully documented schema fields and no output schema, the description is minimally adequate. An agent can call it, but gets no return-shape or pagination expectations and no guidance on the nested 'query' filter semantics, which the description should supply.

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

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

Schema description coverage is 100% (id, query, verbose are all documented inline), so the baseline is 3. The description adds nothing about the parameters — notably it does not explain the interaction of 'id' (single fetch) with list behavior or the shape of the 'query' filter object.

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 DNS zones'), which is enough to distinguish it from the volume, network, firewall and image list siblings by resource noun. However, it gives no scope detail (e.g. project/region filtering) to separate it from a hypothetical filtered variant, so it stops short of full sibling differentiation.

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

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

There is no when-to-use or when-not-to-use guidance and no named alternative. 'Read only' hints at the safety profile but does not tell the agent when this tool is the right choice versus, say, a single-zone fetch via the id parameter.

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?

With no annotations, the description carries the full behavioral burden and delivers only "Read only." It omits pagination, result limits, auth context, and what the default payload looks like, leaving the agent to infer everything about how the call behaves.

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 fragments, front-loaded with the action and followed by the safety note. Given the absence of annotations, "Read only" earns its place and there is no filler whatsoever.

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

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

For a 3-parameter tool with a nested query object and no output schema, the description is minimally adequate: the schema covers every parameter, but nothing explains filtering behavior or what a listing returns. It is usable but 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%, so id, query and verbose are already documented in the schema; per the baseline rule this earns a 3. The description adds nothing beyond that about filter syntax or the verbose payload, so no credit above baseline.

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

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

"List firewalls" states a clear verb and resource, and the sibling set (cloud_create_firewall, cloud_delete_firewall) makes the list-vs-mutate distinction obvious without naming them. It stops short of 5 because it neither names an alternative nor scopes the listing (e.g. all vs filtered).

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 alternatives named. "Read only" hints at the safe-read context but does not tell the agent when this list tool is the right choice over cloud_list_networks or other inventory calls.

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?

No annotations are provided, so the description carries the full behavioral burden. 'Read only' is a genuine and useful safety disclosure, but nothing is said about pagination, result volume, or the effect of the query/verbose flags.

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

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

Two short sentences with the resource front-loaded and zero filler. It is efficient, though extremely terse rather than richly structured.

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

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

For a simple read-only list with fully documented parameters and no output schema, the description covers the essentials. It leaves pagination/return-shape and filtering behavior unaddressed, which is a minor but real gap given the absent annotations.

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

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

Schema description coverage is 100%, so all three parameters (id, query, verbose) are already documented in the schema. The description adds no parameter syntax or semantics 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 and resource ('List floating IPs'), which cleanly separates it from siblings like cloud_list_primary_ips and cloud_list_ssh_keys. It does not, however, name or contrast with any sibling explicitly, so it stops short of the top band.

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

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

There is no statement of when to use this tool versus the many other list tools, nor any prerequisites or exclusions. Usage can only be inferred from the tool name.

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

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

No annotations are provided, so the description carries the full burden; 'Read only' usefully discloses the safety profile. It stops there, offering nothing about pagination, result volume, or return 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 brevity is appropriate for a simple list tool, though it borders on under-specification.

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 100% schema coverage, the omission of parameter detail is tolerable, and no output schema exists so return values need not be described. Still, for a tool with a nested query object and no annotations, the description is only minimally complete.

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

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

Schema description coverage is 100%, so id, query, and verbose are already documented in the schema. The description adds no parameter meaning beyond that baseline, which is acceptable but not additive.

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+resource ('List images') that an agent can immediately act on. It does not, however, differentiate from the many other cloud_list_* siblings, so an agent must rely on the resource noun 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 description gives no when-to-use or when-not-to-use guidance and names no alternatives. Given the density of similar list tools in the sibling set, basic routing context is missing.

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

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

With no annotations supplied, the description must carry the full behavioral burden, and "Read only" does disclose the single most important trait: this tool does not mutate state. It still omits return shape, pagination, and any permission or scoping notes, so the coverage is thin for a fully un-annotated tool.

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 totalling four words, with the resource identified first and the safety trait second. Nothing is padded and nothing is 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?

There is no output schema and no annotations, so the description is the only place return behavior or filtering semantics could be explained, and it explains neither. The 100% schema coverage on parameters limits the damage, leaving the definition minimally viable rather than complete.

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

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

Schema description coverage is 100%, with id, query, and verbose each documented in the schema itself, so the baseline of 3 applies. The description adds no syntax, example filters, or explanation of the nested query object 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?

"List ISOs" gives a clear verb plus resource, so an agent immediately knows this is a read of the ISO catalog. However, it offers no differentiation from adjacent siblings like cloud_list_images or cloud_list_volumes, leaving the agent to infer the distinction from the name 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 description says nothing about when to reach for this tool versus cloud_list_images or how the id/query parameters change its behavior. "Read only" is a safety note, not usage guidance, so the agent gets no when/when-not 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?

No annotations are provided, so the description carries the full behavioral burden. 'Read only' is a useful safety signal, but it gives no information about pagination, filtering behavior, return shape, or whether an id lookup returns a single object vs a list.

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

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

Two short sentences with the operation front-loaded and no filler. It is efficient, though the extreme brevity leaves useful context unstated.

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 three fully documented parameters and no output schema, the main gaps are pagination behavior and how the id/query/verbose options interact (e.g., whether id bypasses query). For a list tool with no annotations, it is minimally but not fully complete.

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

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

Schema description coverage is 100%, so the schema already documents id, query, and verbose. The description adds no parameter meaning beyond that, making the baseline 3 appropriate.

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

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

States a specific verb and resource ('List load balancers'), which is unambiguous about the operation. It does not, however, differentiate from the sibling cloud_list_load_balancer_types, which lists the types rather than instances.

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 many sibling list tools or the load balancer type listing. The only context offered is an implicit read-only statement, not a usage condition or exclusion.

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?

With no annotations, the description carries the full burden; 'Read only' usefully declares the safety profile for a mutation-free listing. However, it says nothing about pagination, result size, or whether the list is account-scoped or global — details an agent would want before calling a list endpoint.

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

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

Two terse sentences, zero waste, with scope stated first and the read-only trait second. It is efficient though arguably under-specified rather than truly concise.

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

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

No output schema, three optional params, and a nested query object: the agent gets no sense of what a 'load balancer type' contains (flavor, size, bandwidth) or what the default vs verbose payload looks like. Adequate minimum, but gaps remain for a catalog-listing tool.

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

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

Schema description coverage is 100%, so the schema already documents id ('fetch one by id'), query filters, and verbose ('full payload'). The description adds no parameter meaning beyond that, 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 and resource: list load balancer types. An agent can distinguish it from cloud_list_load_balancers (instances) by the 'types' noun, though the description never draws that distinction explicitly.

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

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

No when-to-use guidance, no prerequisites, and no mention of the adjacent cloud_list_load_balancers or cloud_create_load_balancer siblings that would tell an agent when this enumeration is needed (e.g. before creating a load balancer).

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?

No annotations are provided, so the description carries the full burden, and it does disclose the key trait: 'Read only.' That is a genuine safety signal for an agent deciding whether the call mutates state. However, nothing is said about pagination, result size, or what a 'location' contains, which are the remaining behaviors an agent would want.

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, front-loaded with the action and followed by the safety trait; nothing is wasted. It is efficient but borders on under-specification rather than true conciseness.

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 tool with a nested-object filter, an optional verbose flag, and no output schema, the description is too thin: it never explains what a location represents, what verbose changes, or how the query filter behaves. An agent could call it, but not confidently.

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 three parameters is documented inline, so the schema does the heavy lifting and a 3 baseline applies. The description adds no parameter meaning beyond the schema and never mentions the id-based single-fetch path.

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

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

The description names a specific verb and resource ('List locations'), which is unambiguous and distinct from every sibling, none of which touch locations. It stops short of 5 because it offers no scope detail (filtering, pagination, region) that would let an agent anticipate behavior.

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 or when-not-to-use guidance, and no alternative is named. The agent must infer that this is the tool to call whenever location data is needed; the 'id' parameter's single-fetch mode is never mentioned as a usage branch.

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?

No annotations are present, so the description carries the full burden. It does declare the safety profile with 'Read only', which is genuinely useful, but it omits pagination behavior, result shape, and what 'everything' encompasses (subnets, IPs, members).

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, zero filler, with the core action front-loaded before the parameter hint and the safety note. Nothing needs to 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?

With no annotations and no output schema, the description should do more work, particularly for the nested query object and what a member record contains. It is minimally adequate for a read-only list tool but leaves real 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%, so each of the three parameters is already documented in the schema. The description restates the id usage but adds no meaning about the nested 'query' filters or the 'verbose' payload option. 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 everything attached to a private network'), which distinguishes it from sibling cloud_list_networks (which lists the networks themselves). It doesn't explicitly name or contrast any sibling, so it falls short of a 5.

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

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

'Pass the network id' is an invocation instruction, not guidance about when this tool is appropriate. There is no mention of when-not to use it or which alternative (e.g., cloud_list_networks) to prefer.

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?

With no annotations provided, the description carries the full behavioral burden, and "Read only" is the only trait it discloses. It says nothing about pagination, filtering behavior, authentication requirements, or the shape of results, leaving most behavioral questions unanswered.

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 filler, and the purpose is front-loaded before the read-only qualifier. 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 tool with a nested filter object, no output schema, and no annotations, the description does far too little. It never explains the query filters, the verbose flag's effect, or what a listing returns, so an agent cannot confidently invoke it with intended semantics.

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 id, query, and verbose are already documented in the schema. The description adds nothing about parameter usage, 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"), which cleanly distinguishes it from write siblings like cloud_create_network and cloud_delete_network. It does not, however, differentiate from other list tools such as cloud_list_network_members.

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

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

No when-to-use guidance, no prerequisites, and no mention of alternatives. The agent must infer usage purely from the name and the fact that it is read-only.

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?

With no annotations, the description carries the full behavioral burden. 'Read only' is the only trait disclosed; it says nothing about pagination, result limits, permissions, or what happens when the optional id is omitted versus supplied.

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 purpose front-loaded before the read-only note. Nothing is padded, though the brevity tips into under-specification rather than tightness.

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?

Three parameters including a nested free-form filter object and no output schema. The description does not explain the filter key semantics, whether results are paginated, or what the default (non-verbose) payload looks like, leaving real gaps for a filtered-list tool.

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

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

Schema description coverage is 100%, so id, query, and verbose are already documented in the schema, including the nested filter object. 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 (placement groups), which is enough to separate it from the create/delete placement-group siblings. It does not, however, differentiate itself from the many other cloud_list_* tools beyond the resource name.

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

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

'Read only' signals the operation class but gives no guidance on when to call this versus cloud_create_placement_group/cloud_delete_placement_group, or on filtering strategy. No prerequisites or exclusions 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?

No annotations are provided, so the description carries the full behavioral burden. 'Read only' usefully discloses that this is a non-mutating operation, but nothing is said about authentication requirements, pagination, rate limits, or result volume—significant gaps for a list tool with no annotation coverage.

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

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

Two terse sentences, front-loading the resource before the safety note; nothing is wasted. It is arguably under-specified rather than overly wordy, so it lands 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?

There is no output schema, the query parameter is a nested free-form object, and the description does not explain what a 'primary IP' is, what fields are returned, or how filtering behaves. For a list tool in a large cloud/robot family, this is 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%, with id, query, and verbose each documented in the schema, so the baseline is 3. The description adds no meaning beyond the schema, but it does not need to.

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), so an agent knows exactly what the tool returns. It does not differentiate itself from the numerous sibling list tools (cloud_list_floating_ips, robot_list_ips, cloud_list_servers), so it falls short of a 5.

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

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

The description offers no when-to-use guidance, no prerequisites, and no routing to alternatives such as robot_list_ips or cloud_list_floating_ips. Usage is only implied by the tool name.

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

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

With no annotations, the description carries the full behavioral burden. 'Read only' is a useful safety signal, but there is no mention of pagination, result limits, authentication needs, or the shape/size of the returned payload, which matters for a list endpoint.

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

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

Two terse fragments, front-loaded with the core action. Very efficient, though 'Read only' is nearly redundant phrasing that could have carried more useful detail instead.

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 list tool with no annotations and no output schema, the description should explain result format, filtering behavior via the query object, and pagination. None of that is present, leaving the agent under-informed despite full schema coverage.

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

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

Schema description coverage is 100%, so the schema already documents id, query, and verbose. The description adds nothing about parameter semantics, 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 cloud servers'), so the agent knows exactly what it returns. However, it offers no differentiation from the many sibling list tools (cloud_list_volumes, cloud_list_networks, etc.) beyond the resource noun.

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 alternatives such as robot_list_servers or the other cloud_list_* tools, and no prerequisites or filtering conditions are stated. The agent must infer usage from the name alone.

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

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

No annotations are provided, so the description carries the full behavioral burden. 'Read only' is a useful safety signal, but the description says nothing about pagination, whether results are cached, or what 'specs' actually contains. For a tool with zero annotation coverage this is thin.

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 resource, with no filler. Everything stated 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?

A no-params-required read tool with a fully documented schema needs little prose, but with no annotations and no output schema, the description leaves the agent guessing about the shape of 'specs' and whether the id and query parameters are mutually exclusive.

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

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

Schema description coverage is 100%, and all three parameters (id, query, verbose) are documented in the schema itself, so baseline 3 applies. The description adds no syntax or format detail about the query filter object or the id-lookup mode.

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 ('List server types and specs'), and the phrase 'server types' distinguishes it from the many cloud_list_* siblings that list instances, images, or load balancer types. It stops short of naming which sibling to prefer when an agent wants actual servers.

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

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

No indication of when to call this versus cloud_list_servers or cloud_list_load_balancer_types, and no prerequisites or filtering guidance beyond what the schema already shows. The agent must infer that this is a catalog lookup rather than an inventory listing.

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?

No annotations are provided, so the description carries the full burden. It does disclose the key behavioral trait 'Read only,' which is genuinely useful safety context, but it says nothing about pagination, permissions, 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 zero filler; the verb+resource and the safety hint come first. It is efficient, though arguably terse given the absence of annotations.

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 optional-param list tool with a fully documented schema and no output schema, the description is minimally adequate. It omits pagination behavior and any routing versus robot_list_ssh_keys, which a mutation-free listing tool of this kind would benefit from.

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

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

Schema description coverage is 100%, so the schema already documents id, query filters, and verbose. The description adds no meaning beyond that, which is the baseline 3 when the schema 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+resource ('List SSH keys'), which distinguishes it from the many other list siblings by resource type. However, it does not differentiate itself from the closely-named sibling robot_list_ssh_keys, leaving the agent to guess which listing tool applies.

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

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

No when-to-use guidance, no prerequisites, and no mention of the robot_list_ssh_keys alternative that appears in the sibling list. The agent gets no help deciding between the cloud and robot SSH key listings.

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?

No annotations are provided, so the description carries the full behavioral burden. It usefully states "Read only," confirming this is a safe read operation, but it does not disclose auth needs, rate limits, pagination, or return format, leaving significant gaps.

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

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

The description is two short, front-loaded sentences with no wasted words. Both "List volumes" and "Read only" earn their place by conveying purpose and a key behavioral trait.

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 no output schema, the description is minimally adequate. However, it lacks any usage context around filtering, fetching by id, or verbose behavior, so an agent gets only a partial picture.

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 schema documents id, query, and verbose. The description adds no parameter meaning, so the baseline 3 is appropriate when the schema does the heavy lifting.

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

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

The description gives a specific verb and resource, "List volumes," which clearly identifies the operation. It does not differentiate from sibling list tools or describe scope/filtering, but the name and phrase make the purpose clear.

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

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

There is no when-to-use guidance, no mention of alternatives such as cloud_create_volume or cloud_delete_volume, and no prerequisites or filtering context. "Read only" describes behavior rather than usage.

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

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

With no annotations, the description carries the full burden and does disclose real behavior beyond the schema: reads are free, writes are subject to read-only and cost guards, and confirm is needed for billed resources. It still omits auth requirements, error/retry behavior, and rate limits, but the safety and cost profile is unusually well surfaced.

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 capability, then the cost/guard behavior, then the escalation path. Every sentence earns its place with 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 generic 6-parameter proxy tool with no output schema and no annotations, the description covers purpose, cost, guards, and verbose/token tradeoffs adequately. It leaves auth and error-handling expectations unstated, but nothing critical to making a correct call is missing.

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

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

Schema coverage is 100%, so the baseline is 3; each parameter (path, method, body, query, confirm, verbose) is already documented in the schema. The description reinforces path format and read/write cost semantics but adds no syntax or format detail the schema lacks.

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 ('Call any Hetzner Cloud endpoint directly' at api.hetzner.cloud) with a concrete path example. This clearly differentiates the raw escape hatch from the dozens of typed siblings like cloud_list_servers and robot_request.

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 operational context (relative paths, reads free, writes guarded) and routes missing/broken endpoints to contribute_or_report, which is a useful escape instruction. However, it never says when to prefer this raw tool over the many specific siblings (cloud_list_servers, cloud_create_server, etc.), which is the main selection decision an agent faces.

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?

With no annotations, the description carries the full burden and does disclose the key consequence – traffic to the address stops. However, it omits whether the IP is released or merely detached, whether the action is reversible, and any permission requirements, so it only partially covers the behavioral surface.

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

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

Two tight sentences, front-loaded with the action and followed by the constraint and its reason. Every clause earns its place with 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 service-affecting mutation tool with no annotations and no output schema, the description conveys the core requirement and warning. It still leaves gaps about the resulting state of the IP and permission needs, making it adequate but not fully complete.

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

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

Schema description coverage is 100%, so both id and confirm are already documented, establishing the baseline of 3. The description adds a rationale for confirm (traffic stops) but no format or syntax detail beyond the schema.

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

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

The description names a specific verb (Unassign) and resource (floating IP) with scope (from its server), so an agent can distinguish it from cloud_assign_floating_ip and cloud_delete_floating_ip. It does not explicitly contrast itself against those siblings, so it stops short of a 5.

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

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

The description states the confirm prerequisite but never says when to choose unassign versus deleting or reassigning the IP. No alternatives or exclusions are given, leaving selection to inference from the tool name alone.

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

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

With no annotations, the description carries the full burden and does disclose the gating precondition, the mandatory confirm flag, and the operational consequence ('the address stops reaching the server'). It stops short of saying whether the change is reversible, whether auth is required, or what happens to the unassigned address.

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

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

Three short sentences, front-loaded with the action and followed by the two blocking conditions. No filler words and nothing repeated from the title or schema.

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

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

For a two-parameter mutation with no annotations and no output schema, the description covers the essential preconditions and the effect of the call. Remaining gaps (auth requirements, post-state of the IP, reversibility) are minor but real.

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

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

Schema coverage is 100% so the baseline is 3, but the description adds rationale beyond the schema's bare 'Must be true.' for confirm — it explains that confirmation is required because connectivity to the server is severed, which helps an agent understand the parameter's intent.

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

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

States a specific verb+resource ('Unassign a primary IP from its server') that cleanly separates it from cloud_assign_primary_ip, cloud_delete_primary_ip, and cloud_unassign_floating_ip. An agent can route to it without opening a 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?

Gives a concrete precondition ('The server must be off') and a hard requirement ('Requires confirm true'), which tells the agent when the call can succeed. It does not name alternative tools (e.g. delete vs unassign) or state what to do if the server is running.

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?

With no annotations, the description carries the burden. It describes the output (a link and steps) without mentioning side effects, implying a safe read-only operation. Could be more explicit about not modifying state, but is clear enough.

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 front-loaded sentences with no fluff. Each sentence adds value: first states trigger and output, second reinforces the value proposition.

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 adequately describes the return value and purpose. It covers the main use case of reporting gaps, though could mention whether the link is generated locally or requires an API call.

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

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

Input schema covers all parameters with descriptions (100% coverage), so the description adds little extra. It reinforces the purpose but doesn't elaborate on parameter usage beyond the schema.

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

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

The description clearly states the tool reports missing or misbehaving Hetzner capabilities and returns a prefilled GitHub issue link and pull request steps. It distinguishes from sibling tools that list or manipulate resources.

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

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

It explicitly says 'When a Hetzner capability is missing or misbehaving', providing a clear trigger. No exclusions are given, but the context makes it obvious when to use.

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

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

With no annotations, the description carries the full behavioral burden and rises to it by declaring 'Read-only, free' and disclosing the ordering and included fields. It does not state auth requirements or pagination behavior, but for a safe read-only listing the safety and cost profile is well covered.

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

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

Front-loads the key behavioral facts ('Read-only, free') then the result shape, then the usage guidance. Every sentence earns its place with 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?

There is no output schema, and the description compensates by enumerating returned fields (monthly price, recommendation flag, retirement dates). Purpose, usage, and return content are covered; only minor behavioral detail like auth and pagination is absent, leaving it near but not fully complete.

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

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

Schema description coverage is 100%, so the schema already documents all 7 parameters (limit, location, min_cores, server_type, architecture, min_memory_gb, include_retiring). The description adds only marginal framing ('where', retirement dates) 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+resource with precise scope: 'Lists which server types can be ordered right now and where.' It clearly differentiates from siblings like cloud_list_server_types and cloud_list_locations by emphasizing live availability and ordering logic (recommended first, then cheapest), so an agent can tell them 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?

Gives a concrete when-to-use trigger: 'Use it before creating a server to avoid resource_unavailable errors and to pick a fallback location,' naming the scenario and the payoff. It does not explicitly name a competing sibling or a when-not-to-use condition, so it stops short of a 5.

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?

No annotations are provided, so the description carries the full burden. It does disclose the safety-critical 'Read-only' property and sketches the return shape (score, counts, top findings). It says nothing about permissions required, cost/rate of running a full estate audit, or whether the report is cached versus freshly computed.

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 read-only guarantee and the core purpose, then the outputs, then the mode flags. Zero filler, though the mode sentence compresses two distinct invocation paths into one line.

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

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

With no output schema and no annotations, the description does cover what the tool returns (score, counts, top findings) and the principal invocation modes. It leaves refresh and demo semantics undocumented, but an agent could still call the tool correctly in its default form.

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 83%, so the schema already documents most parameters, and the description largely restates finding=N and full=true. It does add the useful interplay between the summary, full-report and single-finding modes, but notably omits top, page, demo and refresh.

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 ('Audits every configured Hetzner project') plus the audit domains (security, cost, reliability, hygiene). It is clearly distinguishable from the sibling list/create/delete tools, none of which perform portfolio-wide auditing.

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

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

It explains mode selection within the tool (finding=N for one fix, full=true for the whole report), which helps invocation. However, it gives no guidance on when to reach for this audit versus related siblings like spend_history, find_capacity or infra_map.

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?

With no annotations, the description carries the full burden and does well: it declares 'Read-only', discloses that it starts a local server at http://127.0.0.1:43390 and returns its URL (a side effect worth knowing), and notes the token scoping. It stops short of stating auth prerequisites or whether the local server persists after the 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?

Four short sentences, front-loaded with the safety hint ('Read-only') and ending with the token caveat. Each sentence carries a distinct fact; only the URL/serve sentence could be marginally tighter.

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 and no annotations, so the description must cover return behavior — it does by naming the returned URL and the report contents. It is adequate for a 5-param, 0-required read tool, though it omits any auth/permission detail.

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

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

Schema description coverage is 80%, so the schema already documents demo, serve, target, and mermaid. The description adds the practical scoping semantics for target ('one workspace or project') but says nothing about demo, mermaid, or refresh, matching the baseline 3 for high coverage.

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

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

States a specific verb and resource ('Maps every configured Hetzner project and account') and enumerates the outputs (cost per project/resource, top cost drivers, idle billed resources), which clearly separates it from the cloud_list_*/robot_list_* siblings and from pricing lookups.

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?

'Pass target to map one workspace or project' gives a usage cue for scoping, but does not distinguish this tool from adjacent cost/audit siblings such as infra_audit, spend_history, find_capacity, or cloud_get_pricing. No explicit when-not 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?

No annotations are provided, so the description carries the full behavioral burden. It does disclose the key safety trait ('Read only'), which tells the agent this is a non-mutating operation, but it says nothing about pagination, result limits, auth requirements, or return shape.

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

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

Two short sentences with no filler, and the core purpose is front-loaded before the read-only qualifier. It is arguably under-specified rather than wasteful, but nothing needs trimming.

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

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

For a simple list tool with a fully documented schema and no output schema, the definition is minimally adequate. It leaves the relationship to the sibling robot_list_ips and any pagination behavior unexplained, which an agent would need in a crowded listing-tool namespace.

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

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

Schema description coverage is 100%, so the schema already documents id, query, and verbose, including the nested filter object. The description adds no parameter meaning beyond that, 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 and resource ('List failover IPs'), so an agent knows exactly what the tool returns. However, it does not distinguish itself from the closely-named sibling robot_list_ips, so the boundary between the two must be inferred from the name 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 only guidance is the trailing 'Read only' note; there is no statement of when to prefer this tool over robot_list_ips or other listing tools, and no prerequisites or exclusions are given.

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

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

With no annotations provided, the description carries the full burden, and it does state the most decision-relevant trait for an agent: that this is a read-only operation with no side effects. It omits everything else, though – pagination behavior, whether results are truncated, and any filter-time constraints are unstated.

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 fragments with zero filler, and the core purpose is front-loaded ahead of the read-only note. It is efficient, though the extreme brevity is under-specification rather than the only possible concision.

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

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

This is a simple list tool with a fully documented schema, so not much prose is required. But with no annotations and no output schema, the description should at least indicate what a listed IP contains or how results are bounded, and it does not.

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

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

Schema description coverage is 100%, so the schema already documents all three parameters (id, query, verbose) and the baseline is 3. The description adds nothing beyond that, and notably never mentions the single-record fetch path implied by the id parameter.

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

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

"List single IPs" names a verb and a resource, so the purpose is not a tautology. However, the term "single IPs" is jargon that does not clearly distinguish this tool from sibling listings such as robot_list_failover, cloud_list_primary_ips, or cloud_list_floating_ips, leaving the agent to infer the scope.

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

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

The description gives no when-to-use context, no prerequisites, and no routing to alternatives despite a large sibling set of IP- and network-listing tools. "Read only" is a safety note, not usage guidance.

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

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

No annotations are provided, so the description carries the full behavioral burden, and it discloses only that the operation is read-only. It says nothing about pagination, result limits, authentication needs, or what the verbose/filter behavior actually yields, which is a substantial gap for a list tool.

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 being listed and zero wasted wording. It is appropriately sized, though the 'Read only' fragment is the only thing keeping it from being purely a restatement of the name.

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

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

For a tool with a nested filter object, no required parameters, and no output schema or annotations, the description is too thin. It never explains what a reverse DNS entry contains, how filtering by label_selector works, or what 'verbose' changes, leaving the agent under-informed.

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 three parameters documented in the schema (id, query filters, verbose). The description adds no parameter 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 and resource ('List reverse DNS entries'), which is clear enough for an agent to know what the tool returns. However, it does nothing to distinguish itself from the many sibling list tools such as robot_list_ips or robot_list_servers, so the sibling differentiation that a 5 requires is absent.

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 tool versus alternatives, nor any prerequisites or exclusions. 'Read only' hints at the operation class but is not a usage guideline, leaving the agent to infer everything 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?

No annotations are provided, so the description carries the full behavioral burden, and it offers only 'Read only'. It says nothing about pagination, result limits, permissions, or how the id/query/verbose modes differ in 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, front-loaded sentences with no filler; the resource comes first and the safety note second. It is efficiently structured, though extremely terse.

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-param, no-required-arg list tool with full schema coverage and no output schema, the description is minimally adequate. It omits any hint of return shape or how verbose changes the payload size, which an agent would want when deciding between modes.

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

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

Schema description coverage is 100% – id ('Fetch one by id'), query (filters), and verbose ('Full payload') are all documented in the schema. The description adds no syntax or format detail 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 and resource ('List dedicated servers'), and the word 'dedicated' implicitly separates it from the cloud_* siblings. It never explicitly names cloud_list_servers as the alternative, so an agent must infer the robot-vs-cloud distinction from the prefix.

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

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

There is no when-to-use guidance, no mention of prerequisites, and no routing to or away from siblings such as cloud_list_servers or robot_list_ips. 'Read only' describes the operation type, not when to choose it.

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

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

No annotations are supplied, so the description carries the full behavioral burden; 'Read only' is a genuinely useful safety disclosure that would otherwise be absent. Beyond that it says nothing about authentication requirements, result limits, or whether pagination applies for a listing tool.

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 zero filler. The second sentence earns its place because it supplies the read-only trait that no annotation provides.

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 fully documented optional params and no required ones, the description is minimally adequate. But with no output schema and no annotation coverage, it omits any sense of the returned payload or handling of the nested query filter object, leaving gaps an agent would notice.

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

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

Schema description coverage is 100%, so the schema already documents id, query filters, and verbose. The description adds no interpretation of these parameters, so the baseline of 3 applies.

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

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

States a specific verb and resource ('List Robot SSH keys'), which is enough to distinguish from the many create/delete siblings. However, it never contrasts itself with the near-identical sibling cloud_list_ssh_keys, so the robot-vs-cloud distinction rests entirely on the reader inferring it from the name.

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

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

There is no statement of when to use this tool versus the sibling cloud_list_ssh_keys, nor any prerequisite or context about Robot accounts. The agent must guess which of the two SSH-key listers applies.

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?

No annotations are provided, so the description carries the full behavioral burden, and 'Read only' merely restates what 'List' already implies. It says nothing about auth requirements, whether query filters on nested objects are combinable, pagination, or result 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 no wasted prose, and the operation is front-loaded. But the second sentence ('Read only.') is redundant with the first and the overall brevity stems from under-specification rather than tight writing.

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 tool with three parameters including a nested filter object, no output schema, and no annotations, the description is too thin. It does not explain how the id path differs from the query path, nor what verbose changes about the response.

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

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

Schema description coverage is 100%, so the schema already documents id, query, and verbose (including 'name, label_selector' examples). The description adds no syntax, format, or interaction detail beyond that, warranting the baseline 3 rather than more.

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+resource ('List subnets'), so the core operation is identifiable. However, it gives no scope, return shape, or relation to near-neighbors like robot_list_vswitches or robot_list_ips, so an agent cannot tell from the description alone how this differs from the other robot_list_* 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?

'Read only' is a property, not guidance on when to use this tool versus alternatives such as robot_list_vswitches (whose subnets these may be). There is no context, no prerequisite, and no pointer to a sibling tool.

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

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

No annotations are provided, so the description carries the full behavioral burden. 'Read only' is the sole behavioral claim and it is thin: nothing is said about pagination, filtering semantics, auth requirements, or result size even though the 'query' and 'verbose' params imply variable output.

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 fragments with zero filler, front-loading the core action. It is efficient, though bordering on under-specification rather than true conciseness.

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 three parameters, one a nested filter object, and no output schema, the description should at least hint at filtering/return shape. Instead it leaves all of that to the schema, which is thin given the nested 'query' object.

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

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

Schema description coverage is 100%, so the schema already documents id, query, and verbose; the baseline of 3 applies. The description adds nothing about how 'query' filters interact or what 'verbose' expands, so it does not exceed the schema.

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

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

The description names a specific verb and resource ('List vSwitches'), so an agent knows exactly what is returned. There are no sibling vSwitch tools to differentiate from, but it is otherwise crisp and unambiguous.

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

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

There is no when-to-use guidance, no mention of alternatives (e.g. other robot_list_* tools), and no prerequisites. 'Read only' restates safety rather than telling the agent when this tool is the right 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?

No annotations are provided, so the description carries the full burden. It does disclose meaningful behavior beyond the schema: reads are free and writes are subject to read-only/cost guards. It stops short of describing auth requirements, rate limits, or what the guards actually do when they trigger.

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?

Four compact sentences, front-loaded with what the tool does, followed by the path convention, guard behavior, and the escalation route. Little waste, though the contribute_or_report sentence is somewhat tangential to invoking the tool.

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