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

Annotations only declare it is a non-read-only, non-idempotent, non-destructive write; the description adds genuinely new behavior: billing occurs only after the sheet passes a check (one person, clear face, no text), and a failed check is redrawn once free. That charging and retry semantics are exactly what an agent needs before spending user credits. It omits timing/asynchrony and how the result is retrieved, which keeps it off a 5.

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?

It is short in word count but poorly structured: one run-on block with stacked parentheticals and an ungrammatical opening clause that obscures the main action. The valuable facts (billing rule, check criteria, outfit constraints) are buried mid-sentence rather than front-loaded, so density is achieved at the cost of comprehension.

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 paid, non-idempotent generation tool with no output schema, the description covers the essentials an agent needs: cost source, user consent, what gets drawn, how redraws differ, and the billing/validation outcome. The remaining gap is lifecycle detail (how long it takes, whether get_face_check must be polled afterward) rather than anything blocking a correct call.

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 coverage is 100%, so 3 is the floor, and the description earns more: credits is tied to price.credits from get_character_request (a value source, not just a type), outfit is pinned to "the base outfit line as the user left it" with explicit rendering constraints (one top, fitted trousers or skirt, solid colours, barefoot, no jewellery), and note is scoped to redraws with an example.

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 does convey that this generates a character sheet from a character request and can redraw it with a note, but the opening sentence is garbled ("Draws the sheet for the credits shown (again with a note to redraw) From photos, or an added sheet drawn again as a plain base sheet") and has to be re-read to parse. It never names siblings like start_character, keep_character, or get_face_check to delimit scope, so the agent must infer where this sits in the flow.

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?

"credits must be price.credits from get_character_request: tell the user first" gives a concrete prerequisite (call the sibling get_character_request) plus a consent step before charging. The note parameter is framed as the redraw path ("what to change when drawing again"). It stops short of explicit when-not guidance or stating what to do after a failed check, so it is strong but not complete.

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