Aseprite Studio

Overview Schema Source Related Servers Discussions Admin

animate_rig

Pose a rigged character across frames using motion presets or interpolated pose keys, then write the result to a new layer for tweened sprite animation.

Instructions

Pose a rigged character over several frames and write them to out_layer.

Motion comes from a preset (idle, walk_side, attack, hurt, death; strength scales it) or from keys: [{"frame": 1, "pose": {"arm_front": {"rotate": -30}, "torso": {"dy": 1}, "root": {"dx": 2, "rotate": 5, "pivot": [x,y]}}}, ...] interpolated over frames (ease: ease_in_out | linear | hold). Parts turn with RotSprite about their pivots, children follow parents, and joint gaps are filled from the source (rig "overlap"). feet [x,y] is the pivot for whole-body rotations (default bottom centre). clean removes specks and orphan pixels the rotation left. Frames are added if needed; the source layer is hidden. Returns a summary and a view with onion skin.

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>",
      "rig": "<rig>",
      "out_layer": "<out_layer>"
    },
    "name": "animate_rig"
  }
}

Input Schema

Name	Required	Default
`rig`	Yes
`ease`	No
`feet`	No
`keys`	No
`path`	Yes
`clean`	No
`frames`	No
`preset`	No
`strength`	No
`durations`	No
`out_layer`	Yes
`flash_color`	No	#ffffff
`hide_source`	No
`start_frame`	No
`source_frame`	No
`source_layer`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Oct 23, 2026

TDQS

A3.6/5.0

Behavior4/5

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

There are no annotations, so the description carries the full behavioral burden, and it does disclose important traits: frames are added if needed, the source layer is hidden, clean removes specks and orphan pixels, and it returns a summary plus an onion-skin view. It stops short of stating overwrite/error behavior or permission requirements, but it is substantially more transparent than typical.

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?

The description is dense and front-loads the core operation before moving into motion sources and mechanics. It is long but largely justified by the 16-parameter tool, with little obvious filler, though the single-paragraph structure could be easier to scan.

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

Completeness3/5

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

For a complex 16-parameter mutation tool with no annotations and no output schema, the description gives useful behavioral and return-value context. Still, the missing semantics for required parameters path and rig, plus several optional parameters, leave it only partially complete for correct invocation.

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 0%, so the description must explain all 16 parameters. It meaningfully covers preset values, strength, the keys structure, frames, ease options, feet pivot, clean, and out_layer, but it omits required path and rig structure as well as durations, flash_color, hide_source, start_frame, source_frame, and only alludes to source_layer.

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

Purpose4/5

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

It states a specific verb and resource ('Pose a rigged character over several frames') and names the output target ('write them to out_layer'). That makes the operation clear, but it never explicitly distinguishes itself from likely siblings such as tween_poses or rig_preview, so it falls short of the strongest clarity level.

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

Usage Guidelines3/5

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

The description explains the two motion sources (preset vs. keys) and the available easing modes, which implies usage. However, it does not say when to choose animate_rig over siblings like tween_poses, rig_preview, or check_animation, and it gives no explicit when-not-to-use guidance.

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