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

Annotations declare write, open-world, non-destructive, but the description adds the crucial external consequence: the server lands in the caller's own Hetzner account and Hetzner bills them. That cost/ownership disclosure is real value beyond the annotations. Remaining gaps are timing and what a redeploy replaces.

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 dense sentence plus a bracketed scope tag; the ownership/billing warning is front-loaded inside the parenthetical and nothing is padded.

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

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

There is no output schema, so the description could reasonably say what a successful deploy returns or how long it takes, and it does not distinguish create from redeploy behavior. It covers the essentials for calling it safely (confirm, billing, account ownership) but not the outcome.

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 both confirm and project_id are already documented, including that project_id comes from cloudhosting_list_projects. The description only echoes the confirm=true requirement, 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 (deploy) and resource (the server for a project), and clarifies that this both creates and redeploys. It is clear what the tool does, though it does not name the sibling preview_deploy to sharpen the boundary.

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

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

Gives a concrete precondition (confirm=true) and warns about billing, which implies deliberate use. It does not say when to pick this over cloudhosting_preview_deploy or what happens on a redeploy of an already-running server.

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