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

Annotations already declare write/destructive/non-idempotent, but the description adds real context beyond them: the work is queued for a background worker, it must be polled, it is priced, and it returns image_id and image_uuid. The '[write, queued, priced]' tags front-load the cost and async nature, which annotations cannot express.

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?

The lead clause states the action, scope, and output before any parameter detail, so it is well front-loaded. The optional-parameter block is a dense semicolon-chained run-on that is harder to scan than it needs to be, but each clause carries distinct information.

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?

A 9-parameter, high-complexity mutation with no output schema still gets everything an agent needs: required inputs, enums, nested object shapes, default AI-account resolution, the async polling successor to call, and the identifiers returned. Nothing material is missing for calling it correctly.

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?

With 0% schema coverage the description carries the full burden, and it delivers: image_prompt's 1500-character cap and placeholder syntax, image_aspect's complete enum, and the shape of every opaque nested object (character_assets, image_environment, image_product, image_ai), including the default fallback for image_ai. Only image_title and character_uuids go unremarked, and their meaning is self-evident from the surrounding prose.

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 names a concrete verb+resource ("One picture of 1-3 READY characters") and scopes it tightly by subject matter, source material ("drawn from their main pictures"), naming conventions in the prompt, and allowed aspect ratios. That makes it distinguishable from generic image siblings like create_image or create_promo_image, though no sibling is explicitly named as an alternative.

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 states prerequisites ("1-3 READY characters"), what to do after the call ("poll get_character_image"), and how to override defaults via character_assets or image_ai. It does not state when to use a different creation tool instead, so the routing guidance is implicit rather than explicit.

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