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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is supplied. The description nonetheless adds genuinely non-obvious behavior: no credentials required, no usage tokens spent, up to 60s blocking wait, fresh 15-minute signed links per call, 7-day file retention, and that it does not advance an unfinished pack. Remaining gaps are minor (result payload shape), which keeps this at a solid but not exceptional level given the strong annotation coverage.

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-loaded with the essential 'reads an existing result, starts nothing' framing, then usage, then edge cases. It is long and the receipt paragraph repeats schema text almost word-for-word, but nearly every sentence carries operational information an agent would otherwise have to infer.

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?

Covers the full decision surface for a 3-parameter, oneOf-constrained retry tool: inputs, timeout/expiry triggers, waiting behavior, pack variant, anonymous access and retention limits. With no output schema the description still sketches what comes back (artifacts[], download_url, receipt) well enough to plan around.

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 100%, so the baseline is 3, but the description adds provenance the schema does not: where job_id comes from (data.job_id of a timeout error, or a result carrying artifacts[]), and how pack_run_id relates to a pack result. The recovery_receipt paragraph largely duplicates its schema description verbatim, which caps this below 5.

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+resource: re-reads the result of a job this connection already started, keyed by job_id or pack_run_id. It explicitly negates what it is not ('Starts no new job, sends nothing to any institution and spends no usage tokens'), which separates it from every generation/query sibling in the list.

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 concrete trigger conditions: a call timed out and the error's data carries job_id and a ready result_tool_call, or a download_url in artifacts[] expired. It also names the alternative input (pack_run_id instead of job_id), states the still-running case with a 60-second wait and retry advice, and covers the anonymous/receipt path.

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