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

Annotations already declare readOnlyHint=false, destructiveHint=true, idempotentHint=true, so the agent knows this is a mutating, non-reversible operation. The description adds only the retry sequencing note and says nothing about cost implications, permission/auth needs, rate limits, or what preview versus run actually does. Against a 12-parameter generation tool with no output schema, that is thin.

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?

Two telegraphic fragments that read like internal notes rather than a front-loaded description of the tool. There is little waste, but the terseness is under-specification rather than conciseness – the retry rule is buried in a clause with no framing sentence.

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 12-parameter, four-enum, mutating generation tool with no output schema, the description is far from complete: it omits the main generation path, delivery modes, reference images, and output format. Only the retry sub-flow is covered, leaving most of the invocation surface unexplained.

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 only 25% across 12 parameters, so the description must compensate and largely fails to. It clarifies the pairing of retryTaskId with 'preview' and requestId with 'auto', which is real added meaning, but size, count, model, prompt, quality, deliveryMode, outputFormat, thinkingLevel, and referenceImages remain undocumented in both places.

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 never states the core action; it only implies generation via the tool name and adds routing notes ('Multiple images: batch_generate'). The retry fragment hints at the preview/auto action workflow but doesn't say what a successful call produces. An agent can infer the purpose from the name, but the description itself is vague rather than a clear verb+resource statement.

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?

It does give one concrete decision rule – for retries, use 'preview' with retryTaskId only, then 'auto' with requestId – which is genuinely useful routing. However, it provides nothing about when to use each action for a fresh generation (preview vs auto vs run), no prerequisites, and no guidance against misuse. Partial, implied guidance only.

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