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

Annotations already declare this is a non-read-only, open-world, non-destructive mutation, and the description usefully adds that the rental is paid, that only a public SSH key is accepted, and that user confirmation is required. It does not explain the cost/commitment consequences, provisioning duration, or cancellation path. It also does not reconcile the required idempotency_key with idempotentHint=false, leaving a semantic ambiguity for a money-spending 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?

Three short, front-loaded sentences with no filler, and the paid nature is stated before the constraints. 'Fabric limits' is an internal term that costs a little clarity in an otherwise tight definition.

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 a paid, irreversible-ish provisioning mutation with five required params, 0% schema coverage, and no output schema, the description should say what is created and returned (cluster identifier) and how the quote ties in. The safety-relevant prerequisites are covered, but the parameter surface and result shape are 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 0% across six parameters, so the description carries the full burden and adds meaning only for ssh ('public SSH key only'). The quote UUID, name, confirm_paid_rental, idempotency_key format, and especially the optional acknowledgeSlowNetwork const-true flag are entirely unexplained anywhere.

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: 'Start a PAID whole-node cluster rental', with the PAID emphasis signalling the cost-bearing variant. It is distinguishable from quote/catalog siblings by the verb, but it never names those siblings or explains how it differs from the generic rent tools in the list.

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 real prerequisite-lite workflow cue ('Confirm cost and fabric limits with the user first'), which implies a prior quote step and human confirmation. It does not name emt_cluster_quote as the prerequisite or state when to prefer this over emt_rent, so the routing guidance remains implicit.

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