Skip to main content
Glama

Make a showcase animation

spine_showcase

Render up to four Spine animations side by side with labels into an animated WebP, GIF, or MP4 for before/after comparisons and reels.

Instructions

1-4 animations rendered by Spine side by side, labelled, as an animated .webp (alpha), .gif or .mp4 written only to output. For before/after and reels. Needs ImageMagick plus img2webp or ffmpeg.

Input Schema

NameRequiredDescriptionDefault
fpsNo
holdNoLast-frame hold, s
alignNo
itemsYes
loopsNo
scaleNoPercent
widthNo
outputYes.webp, .gif or .mp4
projectYes
skeletonNo
overwriteNo
backgroundNo"transparent" (webp) or hex

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.70.1

TDQS

A3.5/5.0
Behavior4/5

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

Annotations only say it is not read-only and not destructive; the description adds real value by clarifying that the artifact is written only to the output path (no project mutation) and that it requires ImageMagick plus img2webp or ffmpeg. It does not cover overwrite behavior or failure modes, but the dependency and write-scope notes are the important ones.

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?

Two tight sentences, front-loaded with the core output description, followed by the dependency note. No filler or restatement of the tool name.

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?

There is no output schema and ten of twelve parameters are undocumented, so an agent must read the schema to understand project/skeleton selection, overwrite semantics, and background handling. The description covers the essential output contract and prerequisites but is thin for a tool of this complexity.

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

Parameters2/5

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

Schema coverage is only 33% across 12 parameters, so the description needs to compensate and largely does not. It clarifies the item count limit, labelling, and the output extension set, but says nothing about project, skeleton, fps, loops, scale, width, align, hold, background, or overwrite.

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?

States a concrete verb and resource: renders 1-4 Spine animations side by side, labelled, into a single animated .webp/.gif/.mp4. That is clearly distinct from spine_render_frames or spine_compare_animations in effect, though it never names those siblings explicitly.

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?

"For before/after and reels" gives a use-case context, and "written only to output" hints at the scope of the operation. There is no explicit guidance on when to choose this over spine_render_frames or spine_compare_animations, so the agent must infer the boundary.

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