Skip to main content
Glama

ae_fx_to_spine

Render After Effects comps into Spine frame sequences with matched timing, blending, hit sync, scaling, and loop controls for game animations.

Instructions

Render an After Effects comp and play it in Spine as a frame sequence, timing matched to the comp.

Source: aep + comp (rendered headless with aerender from the SAVED .aep, over the work area, never touching the project open in the AE window), or frames_dir + fps (frames already rendered: .tif premultiplied, or .png). mode: "alpha" (the comp's own transparency; normal blend) or "additive" (light on black: alpha from brightness; additive blend). blend overrides the slot blend. Timing: playback speed equals the comp's (delay = 1/comp fps). Place it with start= (seconds into the Spine animation) or, to land an AE moment on a Spine one, hit_ae= (seconds in the comp, e.g. the impact) + hit_at= (Spine time it should coincide with). fit_duration= stretches the sequence to span that many seconds (loops that must divide the symbol's loop). seq_mode: once | loop | pingpong; a loop runs to until= (default: the end of the animation it is merged into). max_frames/max_size shrink it (every Nth frame; longest side in px), scale = game units per comp pixel, fade = fade-out seconds. animation= merges into an existing animation, otherwise ae_ is created. Leading and trailing empty frames are trimmed. Frames land in images/ae/NN.png; an event ae fires at the start.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
xNo
yNo
aepNo
fpsNo
compNo
fadeNo
modeNoalpha
nameYes
blendNo
colorNoFFFFFFFF
scaleNo
startNo
untilNo
behindNo
hit_aeNo
hit_atNo
parentNoroot
projectYes
front_ofNo
max_sizeNo
seq_modeNoonce
animationNo
end_frameNo
frames_dirNo
max_framesNo
keep_framesNo
start_frameNo
fit_durationNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.0

TDQS

A4.5/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and does so well: it discloses the headless aerender path over the work area that never touches the open project, the mode/blend behavior, trimming of empty frames, output location (images/ae/<name>_NN.png), and the ae_<name> event fired at the start. Side effects are explicit.

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 prose is dense and front-loaded, organized loosely by Source/mode/Timing/seq_mode, and largely free of filler. It is long, but the length is justified by 28 parameters; a few clauses are compressed to the point of terseness.

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 complex mutation tool with no annotations and no output schema, the description covers behavior, inputs, and outputs (files and events) thoroughly. The remaining gap is the handful of undocumented placement/frame-range parameters, which an agent would have to infer.

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 0% and there are 28 params, so the description must compensate, which it does for the non-obvious timing params (start, hit_ae/hit_at, fit_duration, until, seq_mode, max_frames/max_size, scale, fade). However, several params (x, y, color, parent, front_of, behind, start_frame, end_frame, keep_frames) are left entirely undocumented, so the compensation is substantial but incomplete.

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 opening sentence states a specific verb and resource: render an AE comp and play it in Spine as a frame sequence with timing matched. This clearly distinguishes it from sibling render/asset tools like ae_template, fx_generate, and fx_recipe without needing to open 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 Guidelines4/5

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

It gives two mutually-exclusive source paths and the condition for each (aep+comp vs frames_dir+fps), plus mode/blend and seq_mode alternatives. It stops short of naming sibling tools to route against, but the when-to-use context is clear.

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