spriteship

Animate a grid asset from its own tiles

frame_animation

FREE, and NO AI AT ALL — no video model, no credits, nothing to approve. The tiles of a tileset/staged asset ARE the frames: give the tile indices in playback order (repeats allowed) and they are composited into a real spritesheet animation on that asset, exportable to every engine. This is how you animate a coin flip, a flickering torch or a chest opening WITHOUT paying for image-to-video. Try this before animate_asset whenever the motion already exists across the tiles. Returns a jobId — poll get_job.

Input Schema

TableJSON Schema

Name	Required	Description
`fps`	No	Playback fps (1-30, default 12).
`name`	No	Label for the animation (default "Frames").
`assetId`	Yes	Asset id or slug (must be a grid asset: tileset or staged).
`iterationId`	Yes	Revision (iteration) id whose tiles are the frames.
`frameIndices`	Yes	Tile indices in playback order, e.g. [0,1,2,3,2,1]. At least 2, at most 120. Repeats are allowed — that is how you hold or ping-pong a frame.

TDQS

A4.9/5.0

Behavior5/5

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

The description transparently discloses key behavioral aspects: it is free, uses no AI, no credits, no approval required. It explains how the animation is composited into a spritesheet and mentions the return behavior ('Returns a jobId — poll get_job'). This goes beyond annotations, which are sparse.

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

Conciseness5/5

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

The description is well-structured: opens with the key differentiator (FREE, no AI), explains the mechanism, lists examples, gives usage guidance, and closes with the return value. Every sentence earns its place without being overly verbose.

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 covers return value (jobId) and specifies how to poll. It also provides sufficient context for a 5-parameter tool, including prerequisites (tiles exist, grid asset) and destination (every engine). The alternative tool is named, making the context complete.

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%, so parameters are already described. The description adds semantic value, particularly for frameIndices, explaining that repeats allow holding or ping-ponging a frame. It also reinforces assetId must be a grid asset, though this is in the schema as well.

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 description clearly states the tool's purpose: animate a grid asset by using its tiles as frames. It uses specific verbs and resources, and explicitly differentiates from sibling animate_asset by mentioning 'Try this before animate_asset whenever the motion already exists across the tiles.'

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?

Provides explicit usage guidance including when to prefer this tool over animate_asset, with concrete examples (coin flip, flickering torch, chest opening). Also states the condition 'whenever the motion already exists across the tiles', effectively telling when not to use it.

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

All spriteship tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.9/5.0

Disambiguation4/5

Most tools have clearly distinct purposes, and the descriptions are extremely detailed with cross-references (e.g., animate_asset vs frame_animation vs generate_character_animation). A few pairs like reprocess_asset vs revise_asset could be confused initially, but their descriptions and use cases are explicit enough to prevent misselection.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern in snake_case (e.g., create_project, get_asset, cancel_job). Verbs are imperative and nouns are appropriately singular/plural, making the API predictable and readable.

Tool Count2/5

At 41 tools, the server is far beyond the 15-25 range considered reasonable for most APIs. While the domain is broad (project, assets, characters, animations, jobs, exports, credits), the sheer number creates a heavy surface that may overwhelm agents and suggests the API could be consolidated into higher-level operations.

Completeness4/5

The tool set covers the full creative pipeline: project creation, asset/character generation, animation (both AI and frame-based), revisions, exports, and job management. Minor gaps include lack of delete operations for assets/characters/projects and no listing of all jobs, but these are not critical for the core workflow and are likely intentional for a generative art platform.

Resources

Need Help?