Skip to main content
Glama

sprite_death

Make a death (or despawn) animation from a sprite, like the Sprite Death Animation tool on voidless.dev/tools: dissolve (eaten away in patches, with an edge colour), burn (burns away with embers), burst (pixels fly apart and fall), disintegrate (drifts away pixel by pixel) or blink (classic retro flash and fade). Every frame keeps the sprite's own colours; the first frame is the sprite, the last is empty. Returns a GIF and a sprite sheet (frames in 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": {
      "image": "<image>"
    },
    "name": "sprite_death"
  }
}

Input Schema

NameRequiredDescriptionDefault
fpsNo
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 animation
colorNoDissolve's edge colour and blink's flash colour, hex#ffffff
imageYesAn 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.
effectNodissolve
expandNoBurst and disintegrate: grow the canvas so pixels can fly outside the sprite's box
framesNo
directionNoWhich way burn and disintegrate travel (default: burn up, disintegrate right)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.4/5.0
Behavior5/5

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

Goes well beyond the supplied annotations: it discloses the return artifacts (GIF plus single-row sprite sheet), the frame invariants (first frame is the sprite, last is empty), size limits (2048x2048, 256 frames, 32 MB input), and cost ('Free: no credits'). The seed/determinism and optional save-to-library behavior fill in the mutation profile that the annotations only hint at.

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 purpose, then return values, then limits and pricing — a sensible order where nothing is filler. The opening sentence is a long run-on stringing five parentheticals together, which costs some scanability even though each gloss is informative.

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?

With no output schema, the description carries the return contract itself (GIF + sprite sheet, frame ordering) and adds constraints and cost, which is what an agent needs before calling. For a 9-parameter media tool, the remaining gaps (fps/frames semantics, which are self-evident and bounded in schema) are minor.

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 67%, and the description compensates by explaining what each effect actually looks like and what the colour parameter means (dissolve edge colour, blink flash colour), which is meaning the enum alone cannot convey. It does not add anything for fps or frames beyond their bounds, but the effects gloss is the high-value parameter context here.

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?

States a specific verb and resource ('Make a death (or despawn) animation from a sprite') and enumerates the five effects with one-line glosses, so an agent immediately knows what it produces. The 'death/despawn' framing also separates it from general animation siblings like animate_sprite without needing to name them.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied by the effect list and the voidless.dev reference, but there is no explicit when-to-use/when-not guidance and no named alternative (e.g. animate_sprite vs generate_animation_set) for an agent choosing between animation tools. The reader must infer the routing decision.

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