Voidless

match_palette

Free. Only for images generated in Voidless (not uploads): pixel sprites of size 32, 48, 64, 96, 128, 192, 256 or 384 (an HD image: resize_sprite it to a pixel size first). Puts 1-12 sprites on ONE shared palette so separately generated assets look like one scene. The palette is built from all of them as colour ramps, or given as hex colours, or led by one sprite's own colours; every frame of every sprite is remapped along the ramps so shading stays smooth. Each sprite gets a NEW asset (originals untouched).

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": {
      "ids": "<ids>"
    },
    "name": "match_palette"
  }
}

Input Schema

Name	Required	Description
`ids`	Yes	The image assets to put on one palette (1-12)
`lead`	No	One of ids whose own colours are kept exactly; the others follow it
`colours`	No	Size of the SHARED palette all of them draw from (8-64, default 24). Each sprite keeps roughly its own colour count
`palette`	No	Use this palette instead, as hex colours like "#1a2b3c"

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 8, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Adds substantial context beyond the annotations: the operation is free, it is non-destructive ("Each sprite gets a NEW asset (originals untouched)"), it is rejected for uploads, and every frame of every sprite is remapped. The non-destructive guarantee is exactly the reassurance an agent needs for a non-readOnly tool.

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?

Dense but front-loaded: eligibility rules come first, then the operation, then the three modes, then the output guarantee. The parenthetical about resizing HD images is slightly awkward but still earns its place as a prerequisite.

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

Completeness4/5

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

Complete for a mutation tool: prerequisites, modes, limits and the non-destructive outcome are all covered, and no output schema is needed for the agent to call it. The only gap is no hint about what the response contains (e.g. the new asset ids), which matters for chaining.

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 documented, but the description adds the decision model between them: palette either built from all sprites as ramps, supplied as hex colours, or led by one sprite's own colours. That explains how ids, lead and palette interact, which the schema alone does not.

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?

"Puts 1-12 sprites on ONE shared palette so separately generated assets look like one scene" is a concrete verb, resource and outcome. It also distinguishes itself from the related palette tools by describing a shared, multi-asset operation rather than a per-asset swap.

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 hard applicability rules: only Voidless-generated assets, not uploads, only 32-384 pixel sprites, and route HD images through resize_sprite first. It does not explicitly contrast with palette_swap or day_night_palettes, so the agent must infer which sibling to pick, but the constraints are otherwise clear.

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

All Voidless tools Inspect

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

Need Help?