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

Annotations already declare readOnly, idempotent, and non-destructive, so the safety profile is covered. The description adds genuinely useful behavior: download links expire after 15 minutes, the call is free, and a shot may receive one automatic free retry when text did not match. That is real value beyond the annotations, though the shape of the returned payload (including where 'done' lives) is not described.

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 return contents, followed by the action guidance and the retry caveat; the sentence-length parenthetical status enumerations are dense but informative rather than filler. No sentence is pure boilerplate, though the run-on style makes it slightly harder to scan.

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 must carry return semantics, and it does a reasonable job listing statuses and check states. However, it references 'done is true' without establishing that a done boolean exists in the response, and gives no guidance on the size or lifecycle of previews, so an agent polling this tool has a small unresolved gap.

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 50%: the previews flag is documented in the schema itself, and image_set_id has no schema description. The description only obliquely reinforces the previews concept ('small previews of finished images') and says nothing about what image_set_id identifies or how to obtain it. Baseline 3 is appropriate since the schema does half the work and the description fills little of the remainder.

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 concrete verb and resource and enumerates what comes back: per-image status (queued, generating, done, failed), text-check state, previews, and time-limited download links. It is clearly a status/result retrieval tool, though it never contrasts itself with the near-identically named sibling check_image_set, leaving that ambiguity to be resolved elsewhere.

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 explicit polling guidance ('Call again until done is true') plus cost expectations ('Free'), which tells the agent this is the tool to re-poll during generation. It stops short of naming alternatives such as check_image_set or cancel_image_set, so the routing between similarly named status tools is still inferred.

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