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

Adds substantial behavior beyond the annotations (which only declare openWorldHint and non-idempotence): it is a paid, per-minute-billed, non-reversible spend from a prepaid balance with a 15-minute minimum that accrues even if the server is stopped early. It also discloses the asynchronous contract (returns immediately with a server id, ready in 2-5 minutes, 8-15 for custom images) and the budget-refusal guard, which are the exact facts an agent needs before committing money.

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 tight sentences, front-loaded with what the tool does and immediately followed by the cost consequence, then the async return contract and the safety guard. No sentence repeats the title or the schema, 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?

With no output schema, the description correctly compensates by stating the return value (server id) and the readiness delay, and it fully covers the monetary risk of a 9-parameter provisioning call. Minor gaps remain around failure modes (what happens if the budget guard rejects or capacity is unavailable), but the agent has enough 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 every parameter already carries its own explanation, and the description only marginally extends this by describing enforcement of max_eur_per_hour ('refuses machines priced above'). It adds no guidance on how gpu, offer_id, image, or cmd interact, which is the main semantic gap the schema leaves.

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 pair ('Rents a GPU machine and starts a template or Docker image') with the scope made concrete by naming templates and images. It is clearly distinguishable from the lifecycle siblings (get_server, stop_server) and from the lookup siblings (list_gpu_types, list_offers) that it references for inputs.

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 clear context for when this tool is appropriate: it is the provisioning step that spends prepaid balance and refuses offers above max_eur_per_hour. It does not explicitly state when-not to use it or name alternatives such as list_offers for price shopping, but the cost and budget-refusal framing implicitly routes the agent to inspect offers first.

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