get_task

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

No annotations are provided, so the description carries the full burden of disclosure. It clearly states this is a read operation ('Fetch') and specifies what it returns: current status and latest result payload. For a read tool, this is reasonably transparent about its purpose, though it doesn't mention whether it blocks until completion, whether it can be polled repeatedly, error behavior for invalid task IDs, or how 'status' values correspond to states. It's adequate but not rich in behavioral detail.

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?

A single, efficient sentence that covers what is fetched and for what resource type. No wasted words, no redundancy. Appropriate length for a simple read tool.

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?

This is a read/retrieval tool with no output schema and no annotations. Given that context, the description explains it returns 'status' and 'latest result payload', which is the essential expected return. However, without an output schema or annotations, it would benefit from clarifying the relationship to sibling tools (it's the async counterpart to edit_image/remix_image/text_to_image) and whether the result payload structure varies by action. It's mostly complete for a simple polling-style tool but lacks some useful context about the task lifecycle.

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 100%, so both task_id and action are already documented in the schema. The description adds the context that this relates to a 'qwen-image task' and that the result is 'latest', but it doesn't add meaning beyond the schema for the parameters themselves. Since schema coverage is complete, baseline 3 is appropriate.

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 uses a specific verb ('Fetch') plus a clear resource ('status and latest result payload for a qwen-image task'). It's clear what the tool does. However, it doesn't explicitly distinguish from siblings — though the read-only nature versus the create/edit siblings is fairly evident from the name and phrasing. It's clear and specific, just not explicitly differentiated from siblings.

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?

There is no explicit guidance on when to use this tool versus alternatives. It's implied that this is the retrieval/polling counterpart to the creation tools (edit_image, remix_image, text_to_image) given the action enum, but the description never states 'use this after creating a task to check progress' or mentions polling semantics. The context must be inferred from sibling names rather than stated directly.

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