Voidless

extract_parts

Cut an image into its separate pieces. Two uses: (1) a sheet of game items (characters, props, trees...) into one NEW asset per item (the default, save_as 'assets'): each item at its own proportions, framed on a square at the sheet's size (1024 for a 2048/4k asset sheet from generate_image, cut from the full-resolution sheet) like a generated sprite (filling the frame), named after the item, a character or an object, in the sheet's projects and style. Those are generated images like any other: rotate_sprite, animate_sprite, generate_animation_set and resize_sprite all take them; (2) a character sprite into body parts (head, torso, arms, legs...) as 'layer' frames on that asset, for rigging or cut-out animation: pass save_as 'frames'. 10 credits either way. Frames: call get_asset afterwards for their ids.

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": {
      "id": "<id>"
    },
    "name": "extract_parts"
  }
}

Input Schema

Name	Required	Description	Default
`id`	Yes	Asset ID (from list_assets / get_asset or a previous result)
`prompt`	No	Optional: which parts to cut out. Empty = every separate item (assets) or the standard rig parts (frames)
`frameId`	No	Optional: the frame the new frames hang under in the editor (usually the frame referenceFile came from).
`save_as`	No	assets = each piece saved as its own new asset (default); frames = body-part layer frames on this asset, for rigging	assets
`asset_type`	No	save_as 'assets' only: the new assets' type. auto = character when the item's name is one (hero, golem, slime, wolf...), else object	auto
`referenceFile`	No	Work from one image instead of the asset's base: an image key from any of your assets (as get_asset lists it), or its cdn.voidless.dev URL. Empty = the asset's current base image.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 8, 2026

TDQS

A4.2/5.0

Behavior5/5

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

Annotations declare a non-readonly, non-destructive mutation, and the description adds important behavior beyond that: cost (10 credits), creation of new assets or frames, naming and framing behavior, and the follow-up get_asset call for frame ids. There is no contradiction with annotations.

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?

The purpose is front-loaded and the two-use structure is clear, with concrete details about framing, naming, and credits. Some parenthetical density and long sentences reduce crispness.

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?

Given no output schema and a mutating tool, the description explains outputs (assets/frames), post-call id retrieval for frames, cost, and downstream compatibility with tools like rotate_sprite. It is sufficiently complete, though output id handling for asset mode is only implied.

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 schema already documents all six parameters; the description adds useful semantics for save_as modes and asset_type auto behavior. It does not add meaning for frameId or referenceFile beyond what the schema already provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource: 'Cut an image into its separate pieces,' then enumerates two concrete modes (new assets vs layer frames) with their outputs. It does not explicitly compare or contrast with the sibling slice_sprite_sheet tool, so sibling differentiation is incomplete.

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?

It specifies when to use each mode: a sheet of game items should use save_as 'assets,' while a character sprite for rigging or cut-out animation should use save_as 'frames.' It lacks explicit when-not guidance and does not name alternative sibling tools.

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?