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

Annotations only say the tool is not read-only and not destructive, but the description adds substantial behavioral detail: paid operation, dry-run behavior with confirm=false, side effects of attaching sheets to the scenario, idempotency_key retry semantics, and specific error handling for insufficient_tokens and no_active_plan. No contradiction with annotations.

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 description is dense but front-loaded with 'PAID' so the cost-sensitive nature is the first word, and every sentence carries operative guidance: cost formula, confirmation flow, attachment behavior, retry key, and error handling. There is no filler or repetition.

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?

The description fully compensates for the sparse schema by covering pricing, the mandatory confirmation workflow, integration with tegas_start_video, idempotent retry behavior, and the two expected error states. Since an output schema exists, further return-value documentation is unnecessary.

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 description coverage, the prose explains all parameters: items are brief indexes from tegas_find_heroes, price_each_tokens should come from the prior call, confirm controls whether anything is drawn, scenario_id links to the scenario, and idempotency_key is for retries. Minor ambiguity remains: the description says 'chosen by `index`' while the schema parameter is the array `items`.

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 and resource ('Draw hero sheets') and ties it to a concrete input source (brief items from tegas_find_heroes, up to 3). This clearly distinguishes it from sibling tools by positioning it as the paid drawing step that feeds tegas_start_video.

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?

Spells out a complete invocation protocol: call first with confirm=false, show the price, ask for consent, then call with confirm=true after explicit approval. It also names the sibling functions it coordinates with and explains when not to proceed (before confirmation), so usage is fully explicit.

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