Skip to main content
Glama
Sign In

Voidless

by dev.voidless
OverviewDiscussionsAdmin

palette_swap

Recolour a sprite. swaps: from→to colour pairs; by default only pixels of those exact colours change (raise tolerance to catch near shades), match "nearest" snaps every pixel to its nearest from colour (the voidless.dev/tools palette swap). Or palette: a preset (1bit, gameboy, cga, gray4) or a list of hex colours to quantize to, with optional dithering. Call with neither to list the image's colours. 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": "palette_swap"
  }
}

Input Schema

NameRequiredDescriptionDefault
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
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.
matchNoexact
swapsNo
ditherNoWith palette or nearest: Floyd-Steinberg or ordered (Bayer) ditheringnone
paletteNo
toleranceNoFor exact: how far (|dr|+|dg|+|db|) a pixel may be from a from colour
pixel_sizeNoChunky pixels: average blocks of this size first

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already declare the safety profile (destructiveHint=false, openWorldHint=true), freeing the description to add operational detail: hard limits of 2048x2048, 256 frames, 32 MB per call, and a clear cost statement ("Free: no credits"). What it omits is what the call actually returns when save is false and whether the source image is preserved — relevant given readOnlyHint=false and idempotentHint=false.

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 verb, then densely packed with semantics in every clause — very little filler. Minor deductions for the run-on semicolon chain and for the "(the voidless.dev/tools palette swap)" parenthetical, which adds brand reference rather than agent-relevant information.

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 an 8-parameter mutation tool with no output schema, the description covers input semantics thoroughly but never states the return shape by default (inline base64? data URI?) or the fallback when save=true versus false. It also leaves the overlap with match_palette unresolved, which matters given the crowded sibling set.

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 63% and the description compensates well: it explains the from→to pair structure, the exact-vs-nearest distinction (which has no schema description), the meaning of tolerance, the four palette presets, and how dithering composes with palette/nearest. Only pixel_size and save go unmentioned in prose, and both carry decent schema descriptions.

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?

Opens with a specific verb+resource ("Recolour a sprite") and then disambiguates its three operating modes: exact swaps, nearest-match snapping, and palette quantization, plus a listing mode when neither is given. An agent can tell exactly which capability it is invoking without opening the schema.

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

Usage Guidelines4/5

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

Gives clear in-tool guidance on which mode to choose (swaps for targeted recolours, palette for quantization, neither to inspect colours) and when to raise tolerance. It stops short of naming alternatives among siblings — notably match_palette, day_night_palettes, and pixelate_image — which overlap and would benefit from explicit routing.

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

All Voidless toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources