Voidless

downscale_pixel_art

Downscale big art or AI art to a target pixel size without mush, like Smart Downscale on voidless.dev/tools. Each output pixel is one clean colour for its cell: k-centroid (default) runs k-means with k=2-3 on the cell's pixels in OKLab and takes the biggest cluster's centre, so outlines and fills don't blend; dominant takes the cell's most common colour (only colours the input has); nearest takes the centre pixel. Mostly transparent cells become transparent. Target by width (and optionally height) or by factor; optional colour limit after. For AI pixel art drawn on a hidden grid, where the size should be detected rather than chosen, the Pixel Art Fixer on voidless.dev/tools finds the grid. 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": "downscale_pixel_art"
  }
}

Input Schema

Name	Required	Description	Default
`k`	No	k-centroid: clusters per cell, 2 (fill and edge) or 3 for busy cells
`mode`	No		k-centroid
`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
`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.
`scale`	No	Also return a copy scaled up this much (nearest neighbour) to look at
`width`	No	Output width in px (height follows the aspect unless given)
`colors`	No	Limit the result to this many colours (OKLab k-means)
`factor`	No	Or shrink by this factor (default 4 when no width/height)
`height`	No
`alpha_threshold`	No	Share of a cell that must be opaque for its pixel to be opaque

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 9, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Goes well beyond the annotations by disclosing hard limits (2048x2048, 256 frames, 32 MB per call), cost ('Free: no credits'), transparency handling ('Mostly transparent cells become transparent'), and the actual algorithms behind each mode. This is exactly the kind of operational context the readOnlyHint/destructiveHint flags cannot convey.

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?

Purpose is front-loaded and the mode explanations are tight, one clause each. It runs long and repeats 'voidless.dev/tools' twice, which is minor promotional filler an agent does not need to call the tool correctly.

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?

For a 10-parameter mutation that produces an image with no output schema, the description covers sizing rules, mode trade-offs, transparency, resource caps, and cost. The one omission is what is actually returned (image payload vs. saved asset), which matters because the 'save' parameter changes the response shape.

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 already 80%, yet the description still adds real meaning: what k means per cell, what each mode does internally, that width/height and factor are alternative targeting schemes, and that the colour limit applies after downscaling. It leaves 'save' and 'scale' entirely to the schema, which is acceptable given their descriptions there.

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 ('Downscale big art or AI art to a target pixel size') plus the quality goal ('without mush') and a concrete analogue. An agent can distinguish it immediately from siblings like rotate_pixel_art or clean_up_sprite.

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 selection logic: k-centroid is the default for clean outlines, dominant preserves only input colours, nearest takes the centre pixel, and the hidden-grid case is explicitly redirected elsewhere ('where the size should be detected rather than chosen'). The only gap is that the alternative named is an external web tool rather than an in-catalog sibling, so no guidance is offered against tools like clean_up_sprite or extract_palette.

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?