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

Adds materially to the annotations: 'queued' reveals asynchronous execution, 'priced' reveals a credit cost, and the description names the poll target and the returned identifiers. It stops short of explaining what destructiveHint=true means here (e.g. whether image_output_path gets overwritten) or what authorization/account context is required.

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?

Front-loaded with the operation profile tags, then the core input semantics, then side effects and intros. Dense but wastes little; only the deferred-parameter clause reads as compression rather than 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?

Given 9 parameters including a nested passthrough object and no output schema, the description covers the workflow, async model, and return values adequately. It is still incomplete for correct invocation: the required image_title has no semantics, the image_ai object shape is entirely deferred, and cost/overwrite behavior is only a tag.

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 0%, and the description compensates well for topic, layout, language, image_aspect and image_source_url (including enum values the schema itself omits). But it leaves the required `image_title` unexplained and disposes of image_ai, storages_account_id and image_output_path with a bare 'as in create_promo_image', forcing a lookup in another tool's definition.

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?

States a specific verb+resource (create an infographic) and immediately scopes it: 'An infographic about `topic`... The picture at `image_source_url` is the subject it is about.' This distinguishes it from the many sibling image tools (create_image, create_promo_image, render_image) by defining the two inputs that shape the output.

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 bracketed tags [write, queued, priced] plus 'Poll with get_character_image' give an explicit async workflow and point at the companion polling tool. It does not, however, say when to pick this over create_promo_image or create_image, so the routing decision is left partly to inference.

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