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

With no annotations present, the description carries full disclosure responsibility and exceeds it. It reveals async 202 + job-id behavior, polling requirements, result shape (no mesh, glb_url + mp4 preview_url), variable quality, credit charging rules, concurrent-job limits, 429 error, API key scope, and idempotent request_id behavior.

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 every sentence earns its place—prerequisite, inputs, output format, async flow, quality caveat, credit cost, concurrency limit, and result extraction. It front-loads the core action and does not repeat schema boilerplate.

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?

Even without an output schema or annotations, the description tells an agent exactly how to invoke, poll, and read the result, as well as what to expect in terms of output artifacts, credits, auth, and failure limits. This is operationally complete for a complex async generation tool.

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?

The tool-level schema coverage is low, so the description compensates by explaining model as URL or base64, giving prompt examples, differentiating mode values (rot_trans vs rot_only), and connecting num_variants to standalone candidate GLBs. It leaves a couple of less central params like loop and augment_prompt to the nested schema, which already documents them.

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 names a specific operation—text-driven skeletal animation for an already-rigged 3D model—and specifies the key inputs (model, prompt), the output (candidate animation-only GLBs with previews), and the prerequisite of an existing skeleton. This clearly separates it from sprite animation, 3D model creation, and motion-retargeting 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?

The description gives concrete context: it only works on an already-rigged model, says to rig first otherwise, and explains the async polling flow via getApiJob with wait: 30. It does not explicitly name alternative sibling tools for comparison, but it provides enough directional guidance to select this tool correctly.

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