Skip to main content
Glama

generate_animation_set

Generate several animations in one job, one clip per animation, all run in parallel. For several facings of one character (its rotation views) use this, not one animate_sprite call per facing: the set decides room and size once for every facing, so they come out one size. Ways to use it:

  1. A PRESET on one or more sprites: platformer-character (idle, walk, run, jump, attack-1, death, hurt) or a top-down set (topdown-walk/run/dash/attack: 8 directions; topdown-idle: 4). Every sprite gets EVERY action of the preset: topdown-run on one image makes all 8 runs (8 clips), not one. For one clip, pass no preset and type the action (way 3).

  2. A PRESET across an 8-way rotation set: one item per facing, {assetId, frameIndex:, imageIndex:i} where i is the facing's position in the frame's facings list, and every facing gets its own directional clip (walk-left from the left-facing image, …). If the facings list has no 'down' (the sprite was drawn facing the camera), add {assetId, base:true} as 'down'. If it already has 'down' (a side-view sprite), use only the rotation's own images: the base is the side view, not the front. For topdown-idle pick only the 4 cardinals (down, right, up, left). The left, up-left and down-left clips are mirrored from their right-side twins in the same rotation set, for free; set flipFacings false to animate them too.

  3. No preset, a typed action: one clip per image. A list of actions makes one clip per action (up to 6): 'name: description' separated by semicolons names each clip (e.g. 'attack-2: an overhead slash; block: raise the sword to guard'); for one image a plain 'idle, run, jump' also works. Several actions on several images: every image gets every action. Cost: 15 credits per clip, 25 per clip of a 1024 HD image (drawn at 1080P), 30 per looping walk/run clip (walk, stroll, march, sneak, tiptoe, patrol, run, jog, sprint, dash, a charge forward) of a 1024 HD image; mirrored clips are free and clips that fail are refunded. Clips that come back to their start (idle, walk, run, attack, jump, hurt, dash) end on their own first frame, so they loop; one-off clips such as a death do not. Clips are added to their source asset as frames named after the action. Price check: without expectedCost this only shows the plan (the clips it would make and the total) and charges nothing; show it to the user, then call again with expectedCost set to that total. A plan that would charge anything else is refused, with nothing charged.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "items": "<items>"
    },
    "name": "generate_animation_set"
  }
}

Input Schema

NameRequiredDescriptionDefault
roomNoRoom for big moves, decided once per sprite for the whole set so it is one size in every clip. auto: if any clip is a big move (kick, special, fall, jump) and the character fills its frame, every clip of that sprite draws it a little smaller. on: always. off: neverauto
itemsYesImages to animate, in order
presetNoNamed set of actions (see get_animation_presets)
promptNoWithout a preset: the actions to make, as 'name: description' separated by semicolons. With one: optional extra direction for every clip
autoFlipNoAfter the run, mirror every right-side clip on the asset that has no left twin (animate only the right-facing turns, get all eight). Free
holdFacingNoEnd every clip on the frame it started from, even one-off clips such as a death (by default loops end on their start and one-offs don't)
flipFacingsNoOn an 8-way rotation set, mirror the left-side clips from the right-side ones instead of animating them (mirrored clips are free). One-sided details swap sides, as on the rotation images
expectedCostNoThe total in credits the user confirmed from the plan. Omit to get the plan first (free)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / expectedCost
      Added value: +{
      +  "description": "The total in credits the user confirmed from the plan. Omit to get the plan first (free)",
      +  "maximum": 9007199254740991,
      +  "minimum": 0,
      +  "type": "integer"
      +}
  2. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Beyond the annotations, it discloses cost per clip, HD and looping surcharges, free mirrored clips, failure refunds, looping versus one-off clip behavior, and that generated clips are appended to the source asset as named frames. It also explains that omitting expectedCost only produces a free plan and charges nothing, which is critical behavior for a mutating tool.

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 front-loads the core purpose and organizes the usage modes into numbered sections followed by cost and price-check details. A few points, such as the repeated emphasis that every sprite gets every action of a preset, could be tightened without losing meaning.

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 an eight-parameter, cost-incurring animation generator with no output schema, the definition covers the necessary inputs, preset behavior, rotation-set handling, looping semantics, cost model, and confirmation workflow. An agent has enough information to call it correctly and avoid accidental charges.

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% and each parameter already has a detailed description, so the baseline is 3. The description adds meaningful operational semantics—how preset selection interacts with items, how base:true supplies a missing 'down' facing, and how imageIndex maps to facing order—though some of this repeats the schema-level descriptions.

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 names the exact operation: generating several animations in one parallel job, one clip per animation. It explicitly distinguishes itself from animate_sprite for multi-facing rotation sets, so an agent can tell when this tool is the right choice without reading the sibling 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?

The description lays out three concrete usage modes—preset on sprites, preset across a rotation set, and typed actions without a preset—and says which to choose for single clips versus full sets. It also names animate_sprite as the wrong alternative for multi-facing work and explains expectedCost as a two-step confirmation flow.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources