Skip to main content
Glama
EL4CTEO

Roblox Studio MCP

Read and build animations

animation

Read, build, and preview keyframes inside Roblox Studio: inspect existing assets, create playable sequences, and pose rigs for screenshots without leaving the editor.

Instructions

Reads an animation's actual keyframes, and builds new ones that play immediately in the open Studio.

Animations are the one part of a place no other tool can see. inspect on an Animation instance returns an asset id and stops there — the poses live on Roblox's servers. read downloads them, so you can answer 'how long is it', 'which joints does it move', and 'does it end where it started' without opening the Animation Editor and scrubbing.

read takes an asset id, an rbxassetid:// string, or the path of an Animation instance in the place — whichever you already have. It reports which RIG the animation was made for, which is the thing most worth knowing: an R15 animation on an R6 character does nothing at all — no error, no movement — and the asset id gives no hint either way.

build goes the other way: give it keyframes and it returns a content id you can put straight into an Animation's AnimationId. Nothing is uploaded and nothing is moderated — the id works in this Studio session and nowhere else, which makes it the right way to try an idea and the wrong way to ship one.

preview puts an animation ONTO a rig in the open place and freezes it at a chosen moment, so screenshot can show you the pose. It works in edit mode — no playtest. Ask for several moments in turn to compare poses across the animation; the rig stays posed until stop.

Poses are written the way a CFrame property is: "0, 1, 0" for a position, "0, 1, 0 | 0, 45, 0" to rotate as well.

The id build returns is a bare hash, not an rbxassetid:// URL. Use it exactly as given — prefixing it stops it working.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
atNopreview only: the moment to freeze on, in seconds. Ask for several in turn to compare poses across the animation.
opNo'read' downloads an existing animation, 'preview' poses a rig at one moment of it so you can screenshot it, 'build' makes a new one playable here, 'stop' clears a preview.read
rigNoThe model, e.g. "Workspace.Dummy". For preview/stop it is the rig to pose, and needs a Humanoid or an AnimationController inside it. For `build` it is optional and is read for its joint layout — pass it for anything that is not a standard R6 or R15 character (a custom rig, a weapon, a door, a Blender import), or the poses may be attached in the wrong order and the animation will move nothing.
holdNopreview only: freeze on that frame. Turn off to let it play, but then a screenshot catches whatever pose it happens to be in.
loopNobuild only: whether it repeats.
nameNobuild only: name for the sequence.
rootNobuild only: the rig part every pose hangs from. Defaults to "HumanoidRootPart", which is right for an R15 or R6 character.
assetIdNoread only: animation asset id (12345), "rbxassetid://12345", or the path of an Animation instance ("Workspace.Rig.Animate.run").
priorityNobuild only: which animations this one plays over.
studioIdNoTarget Studio; omit for the active one.
keyframesNobuild only: the keyframes, in any order — they are sorted by time.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.6.5

TDQS

A4.7/5.0
Behavior5/5

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

Goes well beyond the annotations (readOnlyHint=false, openWorldHint=true). It discloses non-obvious behavior: built ids are session-local, unuploaded, unmoderated; rig mismatch fails silently with no error; the returned id is a bare hash that breaks if prefixed; preview freezes the rig until `stop`. This is exactly the context an agent needs to avoid failure modes.

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?

Five paragraphs, each carrying distinct operational info (read rationale, rig/R15-vs-R6 gotcha, build session-locality, preview mechanics, pose syntax, id format), so nothing is pure filler. Slightly long for a tool definition, but it is front-loaded with the core verb+resource statement and each later paragraph earns its place.

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 an 11-param, no-output-schema, multi-op tool, the description covers op selection, the session-local id behavior, rig requirements, and pose formatting. Minor gaps remain: multi-studio targeting (`studioId`) and the `hold`/`loop`/`priority` interactions are left to the schema, but nothing critical to calling it correctly is missing.

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

Parameters4/5

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

Schema coverage is 100%, so baseline is 3, but the description adds real meaning: the pose string syntax ('0, 1, 0 | 0, 45, 0'), why `rig` matters for `build` (custom rigs, weapons, Blender imports may attach poses in the wrong order), and the accepted forms of `assetId`. It doesn't add much on `studioId` or the `keyframes` array beyond the schema.

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?

The description opens with a precise verb+resource statement ('Reads an animation's actual keyframes, and builds new ones') and explicitly carves out its territory against a named sibling: '`inspect` on an Animation instance returns an asset id and stops there'. An agent can distinguish this from inspect, generate, or assets without opening a schema.

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

Usage Guidelines5/5

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

It routes each op by intent: `read` for answering questions without scrubbing the editor, `preview` for posing a rig for `screenshot` in edit mode (no playtest), `build` to try an idea but explicitly 'the wrong way to ship one'. It names the alternative (`inspect`) and its limitation, and states the op-ordering (`preview` persists until `stop`).

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