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

Annotations already cover readOnly/non-destructive, and the description adds real behavioral context: it is a blocking wait, it returns when status/progress moves on or after about 50 seconds, and the return shape matches get_drawing. It does not cover error/timeout return specifics, but the added context is substantive.

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?

It is a single sentence with dense, largely necessary information. The 'For the drawing card:' preamble is a slightly awkward framing and the phrasing is convoluted, reducing front-loaded clarity.

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?

For a wait/long-poll tool with annotations present and no output schema, the description covers the trigger condition, timeout, and that it returns a get_drawing result. Remaining gaps (format of status/progress, timeout return behavior) are modest given the structured fields already provided.

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 0%, so the description must compensate. It gives conceptual meaning to status and progress as the last-observed values used to detect change, but drawing_id's role is only implied and the accepted formats of status/progress are not specified, leaving the parameter contract thin.

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 description conveys that the tool blocks until the drawing's status or progress changes, or ~50 seconds elapse, essentially returning a get_drawing result. However, the phrasing 'answers get_drawing' and 'For the drawing card' is indirect and requires parsing; it doesn't cleanly state verb+resource up front.

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 'For the drawing card' framing and 'status and progress the card last showed' imply a polling/sync use case, so usage is inferable. But there is no explicit when/when-not guidance versus get_drawing or the sibling wait_render, leaving the agent to infer that it should use this only in card-rendering flows.

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