trident-mcp

Overview Schema Source Related Servers Discussions Admin

rig_model

Destructive

Auto-rig a 3D mesh for animation by creating a Tripo task (spends credits) and returning a task_id; run rig_check first, then call wait_for_task.

Instructions

Auto-rig a mesh for animation. 25 credits. Run rig_check first. Creates a Tripo task (spends credits) and returns its task_id immediately; then call wait_for_task.

Input Schema

TableJSON Schema

Name	Required	Description
`spec`	No	Bone naming for bipeds (default tripo); unity, unreal, vrm and actorcore need v2.5 or v3.0
`input`	Yes	Task ID of the mesh to rig
`model`	No	Rig version: v1.0-20240301 (default, biped only), v2.5-20260210 (all creature types), v3.0-20260909 (best humanoids, adds others)
`rig_type`	No	Skeleton type (default biped); use rig_check's rig_type
`out_format`	No	Output format (default glb)

Output Schema

TableJSON Schema

Name	Required	Description	Default
`model`	No
`task_id`	Yes
`produces`	Yes
`warnings`	No
`operation`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed16 schema fields changedv0.4.0Oct 19, 2026

changedInput schema / properties / input / description

Previous value: -"Task ID, model URL, or file token to rig"New value: +"Task ID of the mesh to rig"

changedInput schema / properties / model / description

Previous value: -"Rigging model: rig-v2.0 or rig-v1.0"New value: +"Rig version: v1.0-20240301 (default, biped only), v2.5-20260210 (all creature types), v3.0-20260909 (best humanoids, adds others)"

removedInput schema / properties / outFormat

Removed value: -{
-  "description": "Output format: glb or fbx",
-  "type": "string"
-}

addedInput schema / properties / out_format

Added value: +{
+  "description": "Output format (default glb)",
+  "enum": [
+    "glb",
+    "fbx"
+  ],
+  "type": "string"
+}

removedInput schema / properties / rigType

Removed value: -{
-  "description": "Rig type such as biped, quadruped, hexapod, octopod, avian, serpentine, or aquatic",
-  "type": "string"
-}

addedInput schema / properties / rig_type

Added value: +{
+  "description": "Skeleton type (default biped); use rig_check's rig_type",
+  "enum": [
+    "biped",
+    "quadruped",
+    "hexapod",
+    "octopod",
+    "avian",
+    "serpentine",
+    "aquatic",
+    "others"
+  ],
+  "type": "string"
+}

changedInput schema / properties / spec / description

Previous value: -"Skeleton specification: tripo or mixamo"New value: +"Bone naming for bipeds (default tripo); unity, unreal, vrm and actorcore need v2.5 or v3.0"

addedInput schema / properties / spec / enum

Added value: +[
+  "tripo",
+  "mixamo",
+  "actorcore",
+  "unity",
+  "unreal",
+  "vrm"
+]

addedOutput schema / properties / model
```
Added value: +{
+  "type": "string"
+}
```
addedOutput schema / properties / operation
```
Added value: +{
+  "type": "string"
+}
```
addedOutput schema / properties / produces
```
Added value: +{
+  "type": "string"
+}
```

removedOutput schema / properties / status

Removed value: -{
-  "type": "string"
-}

removedOutput schema / properties / taskId

Removed value: -{
-  "type": "string"
-}

addedOutput schema / properties / task_id
```
Added value: +{
+  "type": "string"
+}
```

addedOutput schema / properties / warnings

Added value: +{
+  "items": {
+    "type": "string"
+  },
+  "type": [
+    "null",
+    "array"
+  ]
+}

changedOutput schema / required

Previous value: -[
-  "taskId",
-  "status"
-]New value: +[
+  "task_id",
+  "operation",
+  "produces"
+]

Addedv0.3.0Jul 11, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Adds materially beyond the annotations: explicit cost (25 credits), the fact that it creates a Tripo task and returns a task_id immediately (async, non-blocking), and the required follow-up call. Annotations only cover the safety profile, so this operational detail is real added value.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Four short clauses, zero filler, and the highest-value facts (what it does, cost, prerequisite, async flow) are front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return-value detail is unnecessary; the description still adds the key async return (task_id) and the next call. Cost, prerequisite and sequencing make this complete for an expensive, non-idempotent task-creation tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% with enums documented for spec, model, rig_type and out_format, so the schema carries the parameter burden. The description adds no parameter-level guidance (e.g., which rig_type/model pairing to pick), so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource+goal: 'Auto-rig a mesh for animation.' An agent can distinguish it from siblings like rig_check (validation), retarget_animation (animation transfer), and retopologize without opening any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives an explicit prerequisite ('Run rig_check first') and a downstream step ('then call wait_for_task'), naming two sibling tools with the conditions that select them. There is no explicit when-not-to-use or cost-vs-alternative tradeoff, which keeps it below a 5.

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