tripo_rig

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

With no annotations, the description carries the full behavioral burden and does disclose useful facts: the pre-check is free, the face-count ceiling, and that non-humanoids are bound per the pre-check's rig_type. However, it never states whether rigging consumes credits, whether it blocks or must be polled via tripo_status, whether it overwrites the source model or creates a new version, and what the success response looks like. Cost, limits, and prerequisites are covered; execution and mutation semantics are not.

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?

Three dense sentences, front-loaded with the pipeline order before the branching rules, and no filler. The internal operation names ("operation/pre_rig_check", "operation/rigging_model") are the least valuable content and slightly dilute the lead.

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 7-parameter, no-annotation, no-output-schema mutation tool, it covers prerequisites, the poly-count gate, and rig-type sourcing, which is the core decision path. It remains silent on credit cost, async/polling behavior implied by wait_seconds, and whether the rig replaces or versions the model — gaps an agent would hit on first invocation.

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% and the schema already enumerates spec and rig_type with defaults, so the baseline is 3. The description adds context by tying spec to humanoid rigs (listing Mixamo/UE5/Unity/ActorCore/VRM) and tying rig_type to the pre-check result, but says nothing about force, check_only, wait_seconds, or model_version beyond what the schema text already provides.

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?

Opens with a specific verb+resource ("自动骨骼绑定") and names the exact two-step pipeline behind it (pre_rig_check then rigging_model), so an agent knows this tool produces a rigged model rather than a mesh or texture. It also differentiates itself by branching humanoid vs non-humanoid. Minor deduction: it refers to "operation/pre_rig_check" and "operation/rigging_model", which are not sibling tools and could be mistaken for separate callable endpoints.

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?

Gives an explicit prerequisite chain (pre-check first), an explicit gate (mesh must be ≤100k faces), and an explicit alternative action ("否则先 tripo_remesh"), naming the sibling to use instead. It also says which spec to pick for humanoids vs. to take rig_type from the pre-check. It does not mention tripo_animate or whether animation requires this step first, leaving the rig→animate relationship implicit.

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