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

Beyond the annotations (readOnlyHint=false, destructiveHint=false), the description discloses the cost model (30 credits per new rig, repeat or failed rig free), the latency ('takes a few minutes'), the async return shape (may return a task_id for get_task), and that the original is preserved by saving a new rigged version. That is exactly the extra context annotations cannot carry.

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?

Four short sentences, each with a distinct job: what it does, the price/consent gate, the latency and async behavior, and the follow-up tools. Nothing is repeated and the highest-stakes fact (paid, needs user approval) is placed early.

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?

With no output schema, the description still covers the return path (new version in the viewer, possible task_id via get_task) and the downstream tools for inspecting and exporting the result. For a paid, multi-minute, mutating operation, an agent has everything needed to call it correctly and to inform the user.

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% and the schema already explains kind (auto/humanoid/generic with examples) and wait_seconds bounds, so the schema does the heavy lifting. The description only loosely gestures at these ('ready-made animation clips', 'one of the user's models') without adding syntax or constraints beyond the schema, so the baseline of 3 applies.

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 gives a concrete verb+resource ('Add a skeleton and ready-made animation clips to one of the user's models (auto-rig)') and states the output artifact: a new rigged version shown in the 3D viewer. That clearly separates it from generation siblings like generate_from_text and from post-processing siblings like export_model.

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 spells out the precondition (tell the user the 30-credit price and get their OK first) and the follow-on path (list_animations to see clips, export_model for FBX/GLB, get_task when a task_id is returned). It stops short of stating when not to use it, e.g. whether re-rigging an already-rigged model is appropriate, so it falls just short of a full routing statement.

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