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

With annotations already declaring non-read-only, non-idempotent, open-world behavior, the description still adds real value: the limited re-check budget surfaced in the answer, the retry-once behavior when nothing new is published, and the fact that results must be read back via get_check_result rather than returned here (confirmed by the absence of an output schema). It is not contradicted by the annotations — the retry semantics are consistent with idempotentHint=false — but it stops short of saying what a successful re-check response body looks like.

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 governing rule is front-loaded in the first clause and every sentence carries operational content, but the single run-on paragraph stacks an edge case, a follow-up instruction, and two agent-conduct directives, with some redundancy between 'This is the way to re-check an app that was already checked' and 'never start a new check_live_app for it.'

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?

No output schema exists, and the description compensates by explaining where results are read (get_check_result with the same check_id), what that response contains (each problem marked fixed or not), and what this tool's own answer contains (remaining re-checks). Nothing an agent needs to call 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%, so both parameters (check_id, problem_ids) are already documented in the schema, including the 'default: every problem' behavior. The description adds only the implicit constraint that check_id must match the id used with get_check_result. Baseline 3 applies when the schema does the heavy lifting.

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 ('re-runs exactly the problems get_check_result reported, on the live app') and explicitly distinguishes itself from the sibling check_live_app ('never start a new check_live_app for it'). An agent can tell it apart from the other check_* tools without opening any schema.

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 an explicit precondition ('only once the fix is done AND published'), an explicit exclusion ('never start a new check_live_app'), names the alternative follow-up tool with the exact argument to pass, and even handles the edge case of a setting-only fix with nothing to publish. When-to-use and when-not are both covered.

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