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

Discloses credit spend (18–26), async semantics and minimum ~2–3 min latency, automatic credit refund on failure, and the render outcome split. Annotations (destructiveHint, openWorldHint, idempotentHint=false) are all consistent and reinforced by the description.

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?

Dense but every sentence carries a distinct operational fact (cost, prerequisite, async timing, render flag, refund policy). Front-loads the async + credit cost before details.

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 7 params, a rich output schema, mutation annotations, and a crowded sibling set, the description covers the full lifecycle: cost estimate → prerequisite resolution → async submission → polling workflow → render option → refund safety net. Nothing material is missing.

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 86%, so the baseline is 3, but the description adds non-obvious cross-parameter interactions: render adds viewable assets inline, without render it's a manifest, and excluding 'ai-ugc' saves 5 credits — costs the schema itself doesn't communicate.

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?

Specific verb+resource+scope: 'Kick off an ASYNC snack generation job for a brand.' Distinguishes itself from siblings by naming estimate_snack_cost, list_brands, create_brand, get_job, and the dashboard viewUrl 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?

Explicit prerequisites ('call estimate_snack_cost first', 'call list_brands first, or create_brand'), the alternative for rendering (render=true vs manifest), and the follow-up tool (poll get_job). No other tool in this namespace does this.

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