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

Beyond the minimal annotations, the description discloses that the operation costs credits, that dry_run quotes without charging, that the tool enforces grid/cut-clean guarantees and omits lines/labels, and what the return payload contains (generation, plan, sequences, prompt). This is substantial behavioral context for an agent deciding whether invocation is safe and appropriate.

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 long but densely packed with non-redundant guidance: a front-loaded outcome statement, clearly separated sections for costs, job routing, and returns, and bullet lists that are scannable. No sentence is filler; each contributes either semantics, guardrails, or workflow direction.

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 complex 15-parameter tool with no output schema, the description covers the core workflow, parameter selection by job, cost behavior, and follow-up with get_sheet_atlas. It does not explicitly route the agent to plan_sheet as the planning alternative, so an agent might be unsure whether planning belongs here or elsewhere, but this is a minor gap given the overall richness.

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 93%, so the schema already documents most parameters; the description adds extra value by clarifying which parameters belong to which kind (e.g., art_style for frames only, no art_style for sprites, items for icons/stickers/props), explaining the default for sequences (smooth = in-between after every drawing), and warning that subject is required to prevent invented subjects.

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 opens with a precise specification — "Makes ONE image holding several separate elements laid out so each can be cut out" — and enumerates concrete outputs (animation cycle, sprite sheet, icon set, stickers, props). It explicitly distinguishes itself from generate_image by saying to never call generate_image for a sheet, which removes ambiguity among siblings.

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 provides explicit routing by job type: animation uses kind frames + sequences + subject + art_style, pixel-art uses kind sprites + sequences with no art_style, and icon sets use kind + items. It also tells the agent to quote with dry_run:true first and to use get_sheet_atlas afterward, giving clear when-to-use and when-not-to-use guidance.

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