Skip to main content
Glama
Sign In
aseprite-mcp

aseprite-mcp

by MJSchut
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Local

animate

Converts static Aseprite art into tagged animations and optional sprite sheets without modifying the source, using presets and layer tracks for game-ready output.

Instructions

Static art -> animations. Reads source (never modified), writes output .aseprite with one tag per animation, optionally exports a sheet. Each animation: {name, preset?, frames?, durationMs?, loop?, pivot?:bottom|center|top|[x,y], sourceFrames?|sourceTag?, tracks?}. preset: name | {name, amount?, layers?, lag?:{layer:0.1}, color?, colors?, parts?:{head:"skull"}} | list (combined). Presets: bob: idle up/down bob (amount px, 1); breathe: squash/stretch breathing, feet planted (amount px, 1); float: smooth hover (amount px, 2); hop: squash, jump, land (amount = height px, 6); walk: two-step bounce + tilt for walking without leg frames (amount px, 1); hit: knockback shake + white flash, one-shot (amount px, 2); flash: alternate flash color (color, #fff); blink: invincibility blink; shake: fast horizontal jitter (amount px, 1); sway: plants/hair/flames bend, base fixed (amount = shear, 0.15); wobble: jelly wobble (amount px, 1); pulse: grow/shrink from center (amount px, 1); spin: full rotation, RotSprite-smoothed; swing: pendulum from the top (amount degrees, 15); spawn: pop in with overshoot, one-shot; death: flash, sink and dither-dissolve, one-shot (amount = sink px, 2); fade_out: fade (alpha in RGB, dither otherwise), one-shot; fade_in: reverse of fade_out, one-shot; wave: horizontal ripple: flags, water, heat (amount px, 1); cycle: palette cycling: colors rotate each frame (colors, required); idle_rig: rigged idle: torso breathes, head and arms follow 1-2 frames later (amount px, 1); walk_front: rigged front-facing walk: alternating leg lifts, body bob + weight shift, opposite arm swing (amount = lift px, 2). tracks: [{layer?:"*"|name, x,y,sxPx,syPx,sx,sy,rot,shear,waveAmp,alpha,flash,dissolve,visible,pose: curve}] (pose = source frame whose drawing the layer shows: draw alternate part poses on extra source frames, swap them per frame). curve = number | {seq:[per frame]} | {keys:[[t,v,ease?]]} (ease in|out|inout|step|back) | {wave:sine|triangle|square|saw,amp,base?,phase?,cycles?}. Use padding when motion leaves the canvas. saveRecipe writes a re-runnable recipe (CLI: aseprite-mcp build recipe.json).

Input Schema

NameRequiredDescriptionDefault
exportNo{sheet, ...export sheet options, scale?}
outputNo
recipeNoload recipe JSON file instead of inline fields
sourceNo
paddingNopx or [left,top,right,bottom]
previewNodefault true
animationsNo
saveRecipeNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv2.3.0

TDQS

A4.3/5.0
Behavior4/5

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

With no annotations, the description carries the burden and does well: it states that source is never modified, output is written as .aseprite with one tag per animation, and sheet export is optional. It leaves some gaps around overwrite behavior and error conditions, preventing a 5.

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 long but justified by a complex animation API, and it is front-loaded with the core read/write behavior before detailing presets and tracks. The dense semicolon-separated reference lists are useful but make it harder to scan than an ideal description.

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 tool with eight parameters, nested objects, no annotations, and no output schema, the description supplies enough behavioral and structural context to call it correctly. It still omits return value details and some top-level parameter semantics, which keeps it from being fully complete.

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?

The description compensates substantially for 50% schema coverage by explaining source, output, padding, export, saveRecipe, and especially the nested animation structure, presets, tracks, and curves. It does not explain the top-level recipe or preview parameters, so it is strong but not complete.

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 'Static art -> animations' states a specific transformation verb/resource, and the description immediately names source, output .aseprite, tags, and optional sheet export. It is clearly distinguishable from sibling drawing, editing, or generation tools.

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?

The description gives clear context for use: it reads an existing source and produces animations, and it notes 'Use padding when motion leaves the canvas.' It does not explicitly name when to choose it over siblings like generate or character, but the operating context is clear.

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

Deploy Server

Other Tools