Voidless

clean_up_sprite

Make a sprite or a short animation made ANYWHERE (another AI tool, an artist, a screen recording) game-ready with Voidless's own clean-up: background removed with stray pieces checked (sparks and dust kept, smudges removed); pixel art put on a real pixel grid with one palette and stray pixels fixed. A 1-5 s video comes back as 16 frames: kind 'loop' cuts the cleanest loop (walk, run, idle), 'once' keeps the whole move (attack, jump). Saved to the user's library. Give the file as a public URL (best for videos) or base64. 1 free run a day (10 on Voidless+), then 1 credit an image, 2 a video. For a quick pixel-art version of an already clean image, pixelate_image is enough.

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

Input Schema

Name	Required	Description	Default
`url`	No	Public http(s) link to the image or video. Use this for videos
`file`	No	Base64 file instead of url (a data: prefix is stripped automatically)
`kind`	No	What the file is. Inferred from the url's extension when omitted
`size`	No	Output size. Pixel: 32, 48, 64, 96, 128, 192, 256 or 384, 512 or 1024 (default 64); smooth: 512 (default), 768 or 1024
`style`	No	pixel = pixel art at 32-1024; smooth = clean cut-out at 512, 768 or 1024	pixel
`motion`	No	Video only: loop = find the cleanest loop; once = keep the whole clip	loop

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 8, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Annotations only declare the generic write profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false); the description goes well beyond that by disclosing exactly what is altered (background removed, smudges removed, sparks and dust preserved, one palette enforced) and what is returned ('A 1-5 s video comes back as 16 frames'). It also discloses persistence ('Saved to the user's library') and the billing/quota model, none of which is recoverable from annotations. This is a genuine behavioral disclosure, not a restatement.

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?

It is front-loaded with the core verb and outcome, and every clause carries information — nothing is padding. However, the dense semicolon-and-parenthesis packing plus the mid-stream pricing sentence makes it a single heavy block rather than clearly separable sections, which costs a point on structure.

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?

With six optional parameters, no required fields, and no output schema, the description does the heavy lifting well: it covers input forms, the video-to-16-frames output, motion semantics, and persistence to the library. The remaining gap is what an agent receives back after a run (an asset id? a job requiring check_generation?) and whether existing assets are overwritten, which matters for a non-idempotent mutation.

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 the baseline is 3, but the description still adds meaning: it states the undocumented video-length constraint ('A 1-5 s video'), explains motion with concrete use cases ('loop' for walk/run/idle, 'once' for attack/jump) that go past the schema's terse 'find the cleanest loop', and links kind to the 16-frame outcome. Only size/style guidance is left entirely to the schema, which keeps this just short of a 5.

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?

The opening states a specific verb and resource ('Make a sprite or a short animation ... game-ready') and immediately enumerates the transformations applied: background removal with stray-piece checking, and pixel-grid/palette normalization. It also scopes its inputs broadly ('ANYWHERE ... another AI tool, an artist, a screen recording') and names the sibling it supersedes, so an agent can distinguish it from pixelate_image without opening either schema.

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

Usage Guidelines5/5

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

It gives explicit routing guidance: 'For a quick pixel-art version of an already clean image, pixelate_image is enough', which names the alternative and the condition that selects it. It also advises the input medium ('Give the file as a public URL (best for videos) or base64') and states the cost/rate limits (1 free run a day, 10 on Voidless+, then 1 credit per image / 2 per video), which is the practical when-to-use constraint an agent needs.

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?