Skip to main content
Glama

offset_cels

Move a layer's cel across multiple animation frames along a straight or arced path, applying linear or eased spacing in one Aseprite launch.

Instructions

Move one layer's drawn cel along a path across frames, in one Aseprite launch.

The cel on the first listed frame stays where it is; every later frame is placed
along the way to `(dx, dy)` from it, and the last frame lands exactly there. This is
the same work as one `set_cel_position` per frame, minus the launches and minus
computing the intermediate positions by hand.

Args:
    frames: The frames to place, in the order the movement passes through them.
    dx, dy: The whole movement, in pixels, from the first frame to the last.
    ease: How the movement is *spaced*: `linear`, `ease_in` (starts slow),
        `ease_out` (arrives slow), `ease_in_out`, or `gravity` (horizontal speed
        stays even while the vertical accelerates, as a thrown object does).
    arc_height: Bend the path into an arc this many pixels high at its midpoint,
        perpendicular to the straight line between the ends. A jump or a thrown
        object needs this; a slide does not.

Easing belongs here, in the spacing, and not in the frame durations. Applying a curve
to both applies it twice, and the result reads as slow motion rather than as weight.

Positions are whole pixels, so it is the running position that gets rounded and not
each step: the leftover fraction carries forward instead of being reintroduced every
frame, which is the difference between spacing that reads as speed and spacing that
reads as a limp. The returned `deltas` are the spacing a viewer actually sees, and
`max_error_px` is how far the furthest frame sits from the ideal curve, which stays
below one pixel.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
dxNoDefault: 0.
dyNoDefault: 0.
easeNoDefault: "linear".linear
layerYes
framesYes
filenameYes
arc_heightNoDefault: 0.0.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.10.0

TDQS

A4.6/5.0
Behavior5/5

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

With annotations only declaring readOnlyHint=false and openWorldHint=false, the description carries real load: it discloses that the first frame is anchored, intermediate positions are rounded via carried-forward fractions, and it describes the returned `deltas` and `max_error_px` bound despite there being no output schema. This is genuine behavioral context beyond the annotations.

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?

Front-loaded with the core action first, then args, then two short craft notes; each paragraph does work. Slightly verbose in the explanatory asides, but nothing is truly wasted.

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

Completeness5/5

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

For a 7-param mutation tool with no output schema and partial schema coverage, the description covers the mechanics, the easing/rounding subtleties, and the return values. An agent has everything needed to invoke it correctly.

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 57% and the description compensates well, defining the frames ordering, the meaning of dx/dy as the total movement, the ease options (linear, ease_in, ease_out, ease_in_out, gravity) that the schema lacks an enum for, and arc_height's perpendicular-midpoint semantics. Only filename and layer are left unexplained in prose.

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 first sentence states a precise verb+resource+scope: moving one layer's cel along a path across frames, and pins it as a single-launch operation. It implicitly distinguishes itself from the sibling set_cel_position by describing itself as the batched equivalent, so an agent can tell them apart without opening schemas.

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 clear usage context ('the same work as one set_cel_position per frame, minus the launches') and a specific rule for where easing belongs (spacing, not frame durations). However it never explicitly names or excludes the closest siblings, tween_cels and apply_timing_curve, leaving the agent to infer which movement tool to pick.

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