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 the point charge, the 10-year ceiling from now, the grace-period revival behavior, and precise idempotency semantics ('the same requestId never double-charges or double-extends'). It omits what happens on insufficient points or failure, and does not restate the caller-ownership requirement beyond the word 'caller's'.

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 dense sentences, front-loaded with the action and its cost, then the constraints and idempotency contract. No filler, no restatement of the tool 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 mutation tool with no annotations and no output schema, the description covers cost, term limits, grace-period effects, and retry safety — the essentials for invoking it correctly. The gap is failure semantics (insufficient point balance, invalid/non-owned domain id), which an agent would otherwise have to discover at runtime.

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 undocumented 'id' parameter is compensated by the description framing it as 'one of the caller's domains'. The requestId parameter's purpose is expanded well beyond the schema's terse 'idempotency key for retries' by explaining the never-double-charge guarantee. The years parameter's 1-3 range is only in the schema, but the description adds the overall deadline context.

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 with explicit scope: 'Renew one of the caller's domains by N years'. An agent can immediately tell this apart from domain_register (creation) and domain_update_ns (nameserver edits) among the siblings. The billing side-effect (charge points) is stated up front, so the action's identity 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?

Gives real operational guidance: renewal limits, grace-period revival of expired domains, and when/how to pass requestId for retries. It does not contrast against any sibling (e.g., domain_register or domain_transfer_confirm) or state prerequisites such as sufficient point balance or ownership, so it stops short of explicit when/when-not routing.

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