Skip to main content
Glama

sprite_tools_inbetween

Smoother sprite animation: in-between frames from motion between your frames (4 frames to 8 or 12), pixel art stays crisp with no new colours, holds stay holds, loop seam included; sheet, JSON and a before/after GIF. Price: $0.05 USDC via x402, charged only on success. Part of Sprite tools: 2D sprite jobs for games: cut sprites out of their background (exact for one-color backgrounds, AI for busy ones), turn animation videos into aligned sprite sheets, make normal maps for 2D lights, build 47-tile autotile sets with Tiled, Godot and Unity rules, slice a sheet into frames, pack frames into an atlas with TexturePacker and Unity metadata, and turn upscaled or AI-generated pixel art into real pixel art on its true grid with a limited palette..

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "sprite_tools_inbetween"
  }
}

Input Schema

NameRequiredDescriptionDefault
fpsNoFrame rate of the original, for the preview.
colsNo
loopNoAlso make in-betweens from the last frame back to the first.
modeNopixel: crisp, no new colours; smooth: blended; auto picks pixel for hard alpha and a small palette.auto
rowsNo
countNoFrames used from the sheet when the last row is not full.
sheetNoOr one sprite sheet, cut into cols x rows equal cells (row by row).
factorNo2: one new frame between each pair (4 frames become 8 for a loop); 3: two new frames.
framesNoThe animation frames in order, all the same size.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A3.5/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does well: it discloses output artifacts (sheet, JSON, before/after GIF), quality guarantees (pixel art stays crisp, no new colours, holds stay holds), loop-seam handling, and the billing model ($0.05 USDC via x402, charged only on success). It omits whether frames and sheet are mutually exclusive or whether one is required — a real gap given both are optional top-level params.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The first clause is front-loaded and dense with real value, and the pricing sentence earns its place. The second half, however, is a 90-word enumeration of every other Sprite tool, which does not help an agent call this tool and significantly bloats the definition.

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

Completeness3/5

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

For a 9-parameter tool with nested objects, no annotations, and no output schema, the description covers outputs and cost adequately but leaves out input-shape rules (frames vs sheet) and any constraints on size or failure modes. An agent still has to open the schema and guess at the two-object case.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 78%, so the schema already explains fps, loop, mode, count, sheet, and factor. The description's only added semantic is the "4 frames to 8 or 12" mapping onto factor, which is mildly useful. It says nothing about rows/cols, which lack descriptions in the schema, nor about the frames-vs-sheet exclusivity.

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 opening clause names a specific verb and resource: generate in-between frames from motion between your frames, with concrete scope (4 frames to 8 or 12) and preserved properties (crisp pixels, no new colours, holds stay holds). It is unambiguous what the tool does, though the long trailing catalogue of the other Sprite tools is not about this tool and adds no differentiation of it.

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 frame counts (4 → 8 or 12) and the loop-seam note, so an agent can infer this is the frame-interpolation step of a pipeline. But nothing states when to choose this over siblings like sprite_tools_video_to_sheet or sprite_tools_slice, and the sibling list is presented as a marketing catalogue rather than routing guidance.

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