Fix hand roll in an FBX clip by rotating the hand about its forearm, distributing twist across twist bones, and exporting a corrected FBX.
One clip's hand turned about its forearm, the twist bones sharing it.
| Name | Required | Description | Default |
|---|---|---|---|
| side | No | r | |
| degrees | No | a number, or auto: the clip starts thumb up | auto |
| out_fbx | Yes | ||
| src_fbx | Yes |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden, yet it only hints that twist bones 'share' the rotation. It does not disclose that this writes an output FBX, whether source files are modified, or how the auto degrees behavior affects results.
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?
A single short sentence, so there is no bloat, but for a 4-parameter file-producing tool with no annotations it is under-specified rather than appropriately sized. The one sentence does not earn its place as sufficient guidance.
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 mutation-style tool that produces an output FBX, with no annotations, no output schema, and only 25% parameter coverage, the description is far too thin. Nothing about side, source/output paths, or the auto-degrees behavior is resolved.
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 only 25%: degrees has a description but side, src_fbx, and out_fbx do not, and the description adds nothing about them (e.g., what 'r'/'l' mean or that out_fbx is the generated file). The description fails to compensate for the coverage gap.
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 gestures at a specific operation ('hand turned about its forearm, the twist bones sharing it'), so it is more than a tautology, but it is phrased as imagery rather than a machine-actionable statement of what the tool does. It never says it applies a roll rotation to a hand in a clip or distinguishes itself from siblings like motion_roll_set or motion_roll_profile.
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?
There is no when-to-use guidance, no prerequisites, and no mention of the closely related motion_roll_set and motion_roll_profile siblings. The agent is left to infer that this is the roll-application step and not one of the other motion_roll tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.