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

Annotations already declare a non-read-only, idempotent, non-destructive, closed-world mutation, so the safety profile is covered. The description adds genuinely new behavioral facts on top: the extension is capped at two hours, it is allowed only once, and an expired lease is unrecoverable. The 'once' cap is consistent with idempotentHint=true rather than contradictory.

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 sentences, no filler, and the most decision-relevant fact (private mutation, still-valid lease) is front-loaded. Every clause constrains agent behavior.

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?

An output schema exists, so return values need not be described, and the mutation's constraints are well covered. The remaining gap is parameter meaning — for a two-parameter mutation with zero schema coverage, the description should say what operation_id does and what qualifies as the 'own' lease.

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%, so the description carries the full burden for both parameters and adds nothing about them. Neither job_id nor the length-bounded operation_id is explained, leaving the agent to guess that operation_id is an idempotency/deduplication key — a significant omission for a mutation tool.

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?

The description names a specific verb and resource ('extend a still-valid lease') and pins down the operation as a one-shot renewal, which separates it from the sibling claim_research_job (new lease) and submit_research_job_result. It never names those siblings explicitly, so differentiation is inferable rather than stated.

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?

'Extend a still-valid lease once' plus 'Cannot revive an expired lease' gives a clear positive condition and a clear exclusion, which is more than most definitions offer. What is missing is the alternative path: nothing tells the agent to fall back to claim_research_job when the lease has already expired.

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