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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=false, so the read-only/idempotent safety profile is covered by structured data. The description adds a modest amount: it clarifies this is 'single-shot' (vs. wait_for_* polling tools), which is useful behavioral context. It does not describe what the status values are, whether the id can be reused, or what a missing/failed generation returns.

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?

One compact sentence with a clear front-loaded purpose statement. Nothing is wasted. It would have earned a 5 with slightly richer content, but as a fragment the sentence is well-formed and easy to parse.

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?

Two required parameters with 0% schema coverage, no output schema, and no annotations explaining status semantics. The description does not tell the agent what a status response contains or how to interpret different states, which for a tool literally named 'status' leaves a significant operational 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 description coverage is 0% — neither 'id' nor 'tool' has a description in the schema, and the description text provides no semantic detail at all. The enum on 'tool' is self-explanatory (image, influencer, video, etc.), but whether 'id' refers to a generation id, a job id, or a preview id is unspecified, which matters because there are separate generation-list tools.

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 combination: it checks generation status. It even notes the scope ('single-shot generation status check') and its intended caller ('used by the preview UI'). It does not, however, name the sibling it complements (e.g. audio_status, video_status, wait_for_image) which would help an agent distinguish between status variants.

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 parenthetical 'used by the preview UI' is the only usage hint, and it's a weak one — it tells the human-in-the-loop use-case, not when an agent should choose this over wait_for_image, video_status, audio_status, or the polling tools. No when-not or alternative guidance is included.

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