Skip to main content
Glama

secondary_motion

Add secondary motion to a sprite's cape, hair, beard, scarf, tail or plume, like the Secondary Motion tool on voidless.dev/tools. Give the part as its hex colours (every pixel of those colours moves; its outer outline comes along). One image: the part sways in a gentle breeze that loops. Frames or a sheet (an animation): the part lags the body's movement and overshoots (spring-damper follow-through), same frame count, loops. The body never changes; the part moves by whole pixels in the sprite's own colours. Returns a GIF and a sprite sheet (one row). Images up to 2048x2048, 256 frames, 32 MB of input per call. Free: no credits.

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": {
      "colors": "<colors>"
    },
    "name": "secondary_motion"
  }
}

Input Schema

NameRequiredDescriptionDefault
fpsNo
hangNoWhich way the part hangs from where it's attached; it swings across thisauto
saveNoAlso save the result to your Voidless library (free, private) and return its asset id and cdn.voidless.dev URL, for passing to the next tool without base64
seedNoSame seed, same breeze
windNoBreeze strength (default 0.5 for a still, 0 for an animation)
imageNoOne sprite (a still): makes a breeze idle. Or give frames / sheet. An image: an https URL (e.g. a cdn.voidless.dev link from get_asset or a saved result), a library image key (assets/…png, as get_asset lists it), a data: URI, or base64 PNG/GIF.
sheetNoInstead of frames: one sprite sheet image, cut into frames row by row.
anchorNoWhere it's attached (auto: where it touches the body)auto
colorsYesHex colours of the part that should move, e.g. the cape's red shades
followNoAnimation: how strongly the body's movement throws the part
framesNoFrames in order, each an image (https URL, library image key, data: URI or base64). An animated GIF counts as all its frames.
dampingNoLow = floppy, wobbles; high = heavy, settles
outlineNoMove the part's outer dark outline with it
stiffnessNo
toleranceNoPer-channel colour tolerance for matching colors
sheet_rowsNoRows of the sheet (with sheet).
frame_countNoFrames for a still's breeze loop
sheet_columnsNoColumns of the sheet (with sheet). Omit columns and rows to auto-detect the grid.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4/5.0
Behavior4/5

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

Beyond the annotations (readOnly=false, openWorld=true, idempotent=false), it discloses key traits: the body never changes, motion is whole-pixel and confined to the sprite's own colours, output is a GIF plus a one-row sheet, and calls are free with no credits. It leaves the save-to-library side effect to the schema, but the behavioral picture is substantially enriched by the description.

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 a dense but well-ordered block: what it does, what to supply, how each mode behaves, what comes back, limits, cost. The only near-filler is the voidless.dev/tools brand reference, which doesn't help an agent decide how to call the tool.

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 an 18-parameter tool with no output schema, it usefully states the return values (GIF and single-row sheet) and input limits (2048x2048, 256 frames, 32 MB). Minor gaps remain, such as whether frames and image can be combined and how sheet_columns/sheet_rows interact with auto-detection beyond the schema text.

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?

With 89% schema coverage the baseline is 3, and the description adds real meaning: colours select every pixel of those shades and pull the outer outline along, and the still-vs-frames distinction maps to which input parameter to use. It does not explain stiffness, damping or follow beyond what the schema already says, so it stops short of full coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb and resource ('Add secondary motion to a sprite's cape, hair, beard, scarf, tail or plume') and enumerates the two operating modes, so an agent knows exactly what it produces. It never names a sibling such as wind_sway or animate_sprite, so the differentiation from neighbouring tools is left implicit rather than stated.

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?

Usage context is clear: a single still image yields a looping breeze idle, while frames or a sheet yield spring-damper follow-through that lags and overshoots the body. It doesn't explicitly say when to choose this over wind_sway or animate_sprite, so the alternative-selection guidance is missing.

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