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

Annotations already establish readOnly/non-destructive/non-open-world, and the description adds materially beyond them: conditional fields (`figures` only for runs of a year or longer, `candidates` only for scans), the full verdict enum, and the fact that `report_url` opens without a login. That is exactly the behavioral context an agent cannot get from structured fields.

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?

Given there is no output schema, the Returns block is justified and the conditional-field notes earn their space. Structure is a bit inverted — the tool's own action is in the last paragraph and the return inventory leads — but there is little 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?

With no output schema, the description carries the full return-shape burden and discharges it: enumerated keys, which are conditional, the verdict vocabulary, and the access properties of `report_url`. An agent can call this and interpret the response without opening anything else.

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?

With 0% schema description coverage, the description must carry the parameter, and it does: 'task_id: A task id from any earlier `start_*` call' tells the agent where the value comes from and links it to the sibling tools that produce it. It does not say what happens with an unknown or stale id, which prevents a 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?

The first line describes the artifact ('the summary of a run: a verdict, a headline, a short narrative and next steps') and the closing line states the action implicitly: 'this tool reads a run again later.' It distinguishes itself from the family of progress tools by positioning itself as the post-hoc read, though the verb is buried at the end rather than front-loaded.

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 progress tools give the same summary as `result` when a run finishes, so this tool reads a run again later' clearly establishes the when: after completion, to re-fetch. It names the alternative category explicitly. It stops short of an explicit 'do not use while running' rule, though that is strongly implied.

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