Loading ToolBench
MCP server for Cadence Animator. Runs as a separate process and drives the already-running Cadence Animator app over a local HTTP channel to enable animation control via Claude.
Cadence Animator MCP exposes 20 animation-domain tools with clear verb-noun naming (get_state, set_keyframe, add_rig, etc.). Most tools have substantive descriptions (100-300 chars) explaining WHAT they do and WHEN to use them. However, input schemas are inconsistently detailed: some parameters lack type definitions or descriptions (e.g., 'wiggle' in fill_frames is described as 'Optional randomization parameters' with no nested schema), and output schemas are entirely undocumented. Error handling is minimal, no recovery guidance or actionable error messages visible. Parameter descriptions often omit constraints (e.g., 'step' in fill_frames has no min/max). The server demonstrates domain expertise but falls short of production-grade tool definition rigor.
Add an animatable camera to the scene.
Place a VFX Studio effect document as a new item on the animator's timeline. Pass the full document (e.g. from vfx_get_effect, or vfx_apply_preset's effect field via a follow-up vfx_get_effect). effectStart (project frame where the document's own frame 0 lands) defaults to the current playhead if omitted.
Add a built-in rig (R6, R15, Rthro, or Rthro Slender) to the scene. Returns its itemId and the exact joint names you can key — use these joint names verbatim in set_keyframe, they will not match Blender/other tools' bone names.
Delete a list of keyframes.
Bake an explicit keyframe every `step` frames across [tStart, tEnd] on one track, turning an interpolated curve into explicit per-frame keys you can then hand-tune.
Get an effect item's complete document plus its placement (effectStart/effectLoop) on the animator timeline.
Output schemas completely undocumented. No tool describes what fields it returns, forcing LLMs to guess structure and plan downstream calls blindly.
Complex parameter types lack nested schema definitions. 'wiggle' in fill_frames and 'effect' in add_effect_item are described as objects but have no documented structure, leaving LLMs unable to construct valid payloads.
Numeric parameters lack min/max constraints. 'step' in fill_frames, 't' in set_keyframe, and 'dt' in move_keyframes have no documented bounds, inviting invalid values.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 60 | 2026-07-28+ | v2 |
Get the full current project: every item, every track, every keyframe, groups, fps, length, priority, loop, audio. The ground-truth source of what exists — read this before assuming anything about the current animation.
Get every keyframe on one track, in order, with their exact values and easing.
Group 2+ keyframes so they always move together in time from now on.
List the rig presets available to add_rig (r6, r15, rthro, rthroSlender).
List every item (rig or camera) in the scene with its id, name, kind, and joint/track names.
Reflect a rig's entire animation left-right (swaps Left*/Right* joint tracks and mirrors the CFrames).
Shift a list of keyframes in time by dt frames (grouped keys move together automatically).
Delete an item (rig or camera) and all its keyframes.
Select an item and optionally a specific joint/part in the app UI (also affects what the gizmo/inspector show in a render_frame screenshot).
Replace an effect item's document and/or its timeline placement. Omit `effect` to only change effectStart/effectLoop.
Set an exact keyframe on a joint track (or "@origin" for the rig's root position, or "@fov" for a camera). Use exact numeric CFrame values — never approximate. Get joint names from add_rig or list_items.
Remove the group link for the given keyframes.
Run the diagnostics pipeline on one effect item already placed in the animation (same structured output as vfx_validate).
Whole-project sweep: every rig's animation quality heuristics (the same checks validate_animation runs, one per rig) PLUS every effect item's validation, merged into one uniform structured report — the fastest way to check "is anything wrong anywhere" before calling a task done.
No error recovery guidance. Tools like remove_item and delete_keyframes are destructive but provide no error messages, retry logic, or confirmation patterns to prevent accidental data loss.
add_camera and validate_effect_item have minimal descriptions (<70 chars). Insufficient context for LLM tool selection and reasoning about when to invoke them.