supportpages_retry_article

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the mutation profile is covered. The description adds genuine behavioral context beyond that: it discloses a multi-step recovery workflow and a mandatory UX step (exposing editor_url before retry), which the agent could not infer from annotations alone.

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?

The purpose is front-loaded in the opening sentence, and each subsequent sentence adds a distinct procedural or safety requirement with no filler. It is compact and well-ordered, though the phrase 'returned recovery task' is fairly cryptic without further context.

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 explained, and annotations cover the safety profile. The workflow and exclusion rules are present, but the near-total absence of parameter meaning for a three-parameter mutation leaves the definition incomplete for correct invocation.

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, yet it never explains run_id or workspace. Only 'stopped' is obliquely implied by 'after stopping the previous writer'. This leaves two of three parameters effectively undefined, a significant gap at this coverage level.

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 first sentence gives a specific verb and resource: 'Resume the same partial article after stopping the previous writer.' This clearly distinguishes the resume-after-stop scenario. However, it does not differentiate itself from the sibling supportpages_retry_operation, which sounds highly related, so 4 rather than 5.

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?

The description supplies a clear precondition ('after stopping the previous writer') and an explicit exclusion ('Never retry a draft the user kept for editing'). It also enforces a procedural step ('Always show its returned editor_url before retrying'). It stops short of naming sibling alternatives like retry_operation, so 4 not 5.

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