Skip to main content
Glama

scaffold_cycle

Generate a complete walk, run, idle, attack, hurt, or death animation cycle with proper frame counts, phase tags, timing curves, and loop settings.

Instructions

Scaffold one animation cycle: its frames, a tag per phase, and a shaped timing curve.

`kind` is `walk`, `run`, `idle`, `attack`, `hurt` or `death`, and it settles the four
things a scaffolded animation otherwise gets wrong:

* **The frame count.** walk 8 (6 is the budget option, and 4 only reads as a walk
  mirrored on a side view), run 6, idle 4, attack 5, hurt 2, death 6. A count outside
  the kind's conventional range is accepted with a warning rather than refused.
* **A tag per phase, named for the pose rather than numbered.** An 8-frame walk gets
  `walk_contactL`, `walk_downL`, `walk_passL`, `walk_upL` and the same four for the
  right step, plus a `walk` tag over the whole cycle, so the frame you are drawing on
  says what it is meant to be.
* **Non-uniform durations from the start**, via `apply_timing_curve`: a cycle holds
  its extremes, an attack snaps through the strike, a hurt flashes and then holds the
  recovery, a death slows to a stop on a held last pose. Uniform timing is the
  placeholder every animation starts with and almost none should keep.
* **Loop versus one-shot.** An attack, a hurt and a death do not wrap, so every tag
  they get is written with `repeats=1` instead of being left at 0 ("play forever").
  That field is what `validate_loop` reads, so a one-shot tagged as a loop makes the
  checker report a duplicated seam frame on an animation that has no seam.

Frames are copies of frame 1, there to draw over. Nothing already in the sprite is
deleted, but Aseprite inserts a copied frame rather than appending it, so on a sprite
that already has several frames the new ones land at the front and the existing ones
end up at the end of the cycle; the manifest warns when that happens. Frames past the
cycle are left untagged and untimed, with a warning saying which.

Args:
    kind: walk | run | idle | attack | hurt | death.
    frames: Override the kind's default frame count.
    base_ms: The duration of a passing frame; every other duration is a multiple of
        it. Defaults per kind, because a run passes through its poses faster than an
        idle breathes.

Returns a ``workflow_manifest.v1`` manifest (kind ``animation_cycle``) whose
`animation` section lists every phase with the frame, tag, duration, timing role and
repeat count it ended up with, read back off the saved sprite rather than restated
from what was asked for.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
kindYes
framesNo
base_msNo
filenameYes

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?

Annotations only declare mutation (readOnlyHint=false) and openWorldHint=false; the description adds substantial behavior: frames are copies of frame 1, nothing existing is deleted, Aseprite inserts copies at the front so existing frames shift to the end, warnings are emitted for odd frame counts and untagged tail frames, and out-of-range counts are accepted with a warning rather than refused.

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 one-line summary followed by four tight bullets that each cover a distinct behavioral dimension, with args and returns clearly demarcated. It is long, but for a tool that mints frames, tags, timing and loop flags in one call, nearly every sentence carries information an agent needs.

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?

No output schema exists, so the description explains the return value (a workflow_manifest.v1 with kind animation_cycle, listing phase, frame, tag, duration, timing role and repeat count read back off the saved sprite). Combined with the mutation behavior and warning disclosures, an agent has everything needed to invoke and interpret it.

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%, so the description must carry parameter meaning. It does: enumerates the six valid kind values, explains frames as an override of the kind's default count, and explains base_ms as the duration of a passing frame with per-kind defaults. Only filename is undocumented, which is self-evident.

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?

Opens with a specific verb and resource: 'Scaffold one animation cycle: its frames, a tag per phase, and a shaped timing curve.' This distinguishes it clearly from narrow siblings like add_frame, add_tag, and apply_timing_curve, which each do only one of the three things this tool bundles.

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?

Gives strong context on when each kind applies and which defaults are conventional, and explains the interaction with validate_loop (tagging one-shots with repeats=1 so the checker doesn't report a duplicated seam). It doesn't explicitly say when to prefer this over manually calling add_frame/add_tag/apply_timing_curve, so it stops short of full when-not guidance.

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