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

No annotations exist, so the description carries the full burden and does so: it enumerates the terminal statuses, defines the non-obvious `partial` semantics ('at least one item completed and at least one failed'), and states that failed items carry refund details. It also discloses the response shape (`batchStatus`, ordered `items[]`) and the `markdownEmbed` payload.

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?

Purpose and scope are front-loaded, and the polling cadence is separated into its own labeled sentence. The imperative INLINE RENDERING block is long and is really agent-behavior instruction rather than tool semantics, which dilutes the tool contract somewhat, but nothing is pure 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?

There is no output schema, yet the description fully accounts for the return value: status vocabulary, item ordering, per-item fields (status, prompt, model, media), terminal-state rules, and the embed string. An agent can call and interpret results correctly from the description alone.

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?

Only one parameter and the schema gives it 0% description coverage, but `batchId` is self-evident from the name and the description only says 'by `batchId`'. No format or sourcing detail (e.g. where the id comes from) is added beyond the property name.

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?

Opens with a specific verb and resource: 'Poll every generation in an image batch or multi-video request in ONE call, by `batchId`'. This clearly separates it from the single-task sibling `antix_check_task`, which is named explicitly later. An agent knows exactly what it does without opening the schema.

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 protocol: wait ~15s after submission, then every ~10s while status is `queued`/`processing`, stop on `completed`/`partial`/`failed`, plus a note on expected wall time. It also routes to the sibling relationship by binding the inline-rendering rule to 'same rule as antix_check_task'.

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