hcloud_primary_ip_assign_action

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

Goes well beyond the destructive/openWorld annotations by disclosing the powered-off requirement, the one-ipv4/one-ipv6 limit, and a table of four 422 failure codes (server_not_stopped, primary_ip_already_assigned, server_has_ipv4/ipv6). It stops short of stating side effects on the previously assigned IP or required permissions.

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

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

The operative constraints are front-loaded in the first few lines and the error table is genuinely useful, but the opening sentence is duplicated and cross-reference anchor-link noise ('[Primary IP](#tag/primary-ips)') bloats the text.

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

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

For a mutation tool with no output schema and no output documentation, the description supplies the key preconditions and failure modes an agent needs to avoid a doomed call. Only the async action/`wait` behavior is left to the schema.

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

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

Schema coverage is 67% and the description adds nothing about `id`, `assignee_id`/`assignee_type`, or the `wait` polling flag beyond what the schema already documents. 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 ('Assign a Primary IP to a resource') and immediately clarifies the cardinality rule (one ipv4 and one ipv6 per server), which distinguishes it from the Floating IP and unassign siblings by 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?

Gives an explicit precondition (server must be powered off/status off) and routes agents wanting more addresses to Floating IPs instead. It doesn't explicitly contrast with hcloud_floating_ip_assign_action or hcloud_primary_ip_unassign_action, but the usage context is clear.

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