Voidless

extract_palette

Pull the colour palette out of an image, like the Palette Extractor on voidless.dev/tools. Up to max_colors every exact colour is listed with its pixel count; over it the colours are reduced to max_colors in OKLab (median cut refined by k-means), by default snapped to colours the image really has. Sorted by hue (greys first, then hue families dark to light), luminance or frequency. Returns the swatch PNG and, as text, the palette in GIMP .gpl (Aseprite, GIMP, Krita), .hex (Lospec), JSON with counts, and Adobe Swatch Exchange .ase as base64 (decode it to a binary .ase file). 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": "extract_palette"
  }
}

Input Schema

Name	Required	Description	Default
`name`	No	Palette name in the .gpl and JSON	Palette
`save`	No	Also 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
`sort`	No		hue
`image`	Yes	An 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.
`method`	No	How to reduce when the image has more colours than max_colors	k-means
`columns`	No	Swatch PNG: colours per row (default all in one row up to 16)
`from_image`	No	Reduced palettes: use only colours the image has (false = cluster averages)
`max_colors`	No	The cap: list exact colours up to this, else reduce to it
`swatch_size`	No	Swatch PNG: px per colour (1 = the Lospec 1x strip)

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 9, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Beyond the annotations (which only declare readOnly=false, openWorld=true, idempotent=false), the description discloses hard limits (2048x2048, 256 frames, 32 MB), the reduction algorithm (OKLab median cut refined by k-means), the default snapping to real image colours, the sort ordering semantics, and every return artifact including that .ase is base64 and must be decoded. That is exactly the behavioural context annotations cannot carry.

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 purpose and then the core semantics; essentially every clause carries information (thresholds, limits, output formats). It is a dense run-on paragraph, though, and the voidless.dev tool analogy at the start is the one clause that does not earn its place.

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?

There is no output schema, so the description must describe returns — and it does, enumerating swatch PNG plus .gpl, .hex, JSON with counts, and base64 .ase with a decode instruction. Combined with the input limits and the save/asset-id path for chaining to the next tool, an agent has what it needs to call this correctly.

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 89%, so the baseline is 3, but the description genuinely adds meaning on top: it explains that max_colors is a listing cap below the threshold and a reduction target above it, clarifies the default snapping behaviour behind from_image, and describes the actual ordering produced by sort. It does not add much for columns/swatch_size, which the schema already covers.

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 resource ('Pull the colour palette out of an image') and immediately scopes what comes back: exact colours with pixel counts, or a reduced palette. It is clearly distinguishable from siblings like match_palette or palette_swap, which apply a palette rather than extract one.

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?

Gives useful operating context (size caps, free, no credits) and explains the max_colors threshold behaviour, so an agent can tell when it falls into exact-listing vs. reduction mode. However it never names an alternative or exclusion — nothing says when to use match_palette or palette_swap instead, and the 'like the Palette Extractor on voidless.dev/tools' reference adds nothing actionable.

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?