Skip to main content
Glama

liquid_tiles

Make a seamless, looping animated pixel-art liquid tile, like the Animated Water & Lava Tiles tool on voidless.dev/tools: ocean (swells, crests, sparkles), river (streaks and foam flowing in a direction), pond (shallow water with caustics), lava (dark crust, glowing cracks), acid (green boil, bubbles that pop) or waterfall (falling streaks, plus a foaming base tile for the bottom of the fall). Every frame tiles in both directions and the last frame flows into the first. Six colours per material. Same seed, same tile. Returns a GIF of the tile, a GIF of it repeated 4x4, and a sprite sheet (frames in one row; a waterfall adds its base as a second row). Images up to 2048x2048, 256 frames, 32 MB of input per call. Free: no credits.

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": "liquid_tiles"
  }
}

Input Schema

NameRequiredDescriptionDefault
fpsNo
flowNoRiver and lava only: which way it flows (default: river right, lava none). A waterfall always falls.
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 tile
sizeNoTile width and height, px: 16, 24, 32, 48 or 64
colorsNoOverride the material's colours, hex: the ramp's dark, mid and light, and the accent (foam, sparkles, hottest cracks)
detailNoCrests, sparkles, foam, cracks or bubbles, 0 to 1
ditherNoOrdered 4x4 dithering between the ramp's colours
framesNo
materialNoocean

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?

Annotations only declare it is a non-read-only, open-world, non-destructive generator; the description adds genuinely new behavior: determinism ('Same seed, same tile'), guaranteed seamless tiling across frames, concrete output artifacts, size/frame/input caps (2048x2048, 256 frames, 32 MB), and that it costs no credits. It omits latency/async handling (e.g. whether check_generation is needed) and how results are delivered, keeping it off a 5.

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 the purpose, then materials, then guarantees, then outputs and limits — a sensible order with no filler. The material parentheticals are long but each earns its place by helping an agent choose an enum value.

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?

For a 10-parameter, all-optional generative tool with no output schema, the description covers what is produced, how frames relate, determinism, hard caps and cost. Nothing essential to calling it correctly is missing, aside from minor param-level detail already handled by the schema.

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 coverage is 70%, so the baseline of 3 applies; the description adds only indirect meaning (limits, determinism, the accent as 'foam, sparkles, hottest cracks'). It says nothing about fps, frames, detail, dither or size choices, and 'Six colours per material' does not match the four-field colors override object in the schema, which could mislead.

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 artifact ('Make a seamless, looping animated pixel-art liquid tile') and enumerates the six materials with what each looks like, so an agent can tell exactly what it will get. The output bundle (tile GIF, 4x4 repeat GIF, sprite sheet) is spelled out, distinguishing it from generic image-generation siblings.

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 through the material catalogue and the 'free: no credits' note, but the description never says when to pick this over siblings like generate_vfx, generate_animation_set, make_gif or pack_sprite_sheet. The only external reference is to a website tool, not to any competing MCP tool.

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