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

Goes well beyond the annotations: it discloses that a fresh run is created and resumes from the failed step, that the failed run is retained as evidence, that only failed runs qualify, and that runs.operate plus backups.operate permissions are required. The non-idempotent write nature is made concrete (a new run each time) rather than left to the idempotentHint flag.

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?

Front-loads the action and its scope, then adds consequence and precondition in three tight, non-redundant sentences. Every clause earns its place with no filler.

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 one-parameter, no-output-schema operation, the description supplies everything needed: the precondition for retrying, the effect on state, and the required permissions. Nothing an agent needs to invoke it correctly is missing.

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% and the single run_id parameter is already fully documented as a UUID sourced from list_data_runs. The description reinforces that the id must reference a failed run but adds no syntax or format detail beyond the schema, so the 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 (retry) applied to a specific resource (backup, restore or clone data runs), and scopes it to FAILED runs only. The mention of the CLI twin (`ankra runs retry`) and the failed-run qualifier distinguish it from the many other retry_* siblings like retry_application and retry_execution.

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 clear precondition ('Only a failed run can be retried') and explains the resulting behavior, so the agent knows when not to call it. It does not name an alternative tool or route the agent to list_data_runs for finding a run, but the schema fills that gap.

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