Skip to main content
Glama
Sign In
Daz3D-MCP

Daz3D-MCP

by MictlanLabs
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

anim_import

Imports BVH or FBX motion onto a Genesis figure by mapping bones, adapting rest pose and body size, and keying every frame for animation.

Instructions

Imports a BVH or FBX motion (Mixamo, mocap) onto a Genesis figure: reads the file, maps its bones to the figure's (built-in maps for Mixamo, CMU, Unreal, Biped, Genesis; bone_map to fix), adapts the rest pose (T pose vs Genesis A pose) and the body size, and keys every frame. No importer dialog. Then check it with anim_preview and anim_foot_contact.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "path": "<path>",
      "figure": "<figure>"
    },
    "name": "anim_import"
  }
}

Input Schema

NameRequiredDescriptionDefault
rigNoNaming of the file's skeleton; auto detects it.auto
pathYesAbsolute path of a .bvh or .fbx animation (Mixamo 'FBX Binary', CMU or other mocap BVH, Daz-exported BVH).
takeNoFBX: animation take (default the first).
speedNo
figureYesGenesis figure to animate.
replaceNoDelete the figure's old keys over the imported frames.
bone_mapNo{file bone: figure bone} to add or fix pairs; null drops a bone.
in_placeNoKeep the hips over the same spot (for cycles).
match_fpsNoSet the scene to the file's frame rate first.
source_endNoLast frame of the file to use.
root_motionNoMove the hip up/down and along the path.
start_frameNoScene frame where the motion starts.
source_startNoFirst frame of the file to use.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.4.0

TDQS

A4.1/5.0
Behavior4/5

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

Annotations declare readOnlyHint=false with destructiveHint=false, which the description is consistent with, and the text adds real behavioral context beyond them: automatic bone-map tables per rig family, rest-pose (T vs A pose) and body-size adaptation, and that every frame is keyed with no importer dialog. It stops short of describing failure modes (missing bones, mismatched fps) or the result returned, and never mentions in the description that the default replace=true wipes existing keys over the imported range.

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

Conciseness4/5

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

Front-loads the verb and resource, then walks the pipeline steps in a single dense sentence, closing with two actionable short clauses. Every sentence carries information; the only slight friction is the terse "No importer dialog" and "bone_map to fix", which read as shorthand.

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

Completeness4/5

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

For a 13-parameter mutation tool with no output schema, the description covers the whole import pipeline and the verification workflow an agent needs to sequence correctly. Gaps are the return value/failure behavior and the destructive effect of the default replace, though the latter is documented in the schema.

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 92%, so the schema already explains path, take, source_start/end, in_place and replace; the description only adds the general point that built-in maps cover Mixamo/CMU/Unreal/Biped/Genesis and that bone_map exists to fix pairs. That is marginal added meaning over the structured fields, 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 and resource (imports BVH/FBX motion onto a Genesis figure) and enumerates the pipeline steps: file read, bone mapping, rest-pose and body-size adaptation, per-frame keying. It is clearly distinguished from siblings like anim_preview and anim_file_inspect, which it names as follow-ups rather than substitutes.

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 explicit downstream guidance ("Then check it with anim_preview and anim_foot_contact") and implicitly scopes the tool to the import step of the animation workflow, plus "No importer dialog" signals it is the headless path instead of an interactive Daz dialog. It does not state when NOT to use it, e.g. when motion already exists and anim_offset or anim_retime would be the right tool.

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

Deploy Server

Other Tools