Voidless

generate_image

Generate a game sprite/asset image. For an item, weapon or icon the user describes, use this, not the free generate_items. Infer every field from the request: art STYLE, colour PALETTE, asset TYPE, output SIZE and PERSPECTIVE; for characters also facing/pose/bodyType. Leave model out unless the user names one: the server then picks by size (flux2-klein, 1 credit, up to 64 px; gpt-image-2.5, 3 credits, from 96 px). Costs by model: flux2-klein 1, flux-juggernaut 1, seedream-5-flash 10, gpt-image-2.5 3, gpt-image-2.6 10, retro-diffusion 10, nano-banana-2 15 credits (a reference image makes it 2 and uses flux2-klein). ASSET SHEETS: type 'artwork' + model 'gpt-image-2.6' + size 2048 (20 credits) or '4k' (30 credits) draws one big picture holding a whole matching set (e.g. 'nine fantasy RPG items in a grid, clear space between them, plain light background') at full resolution; cut it into one asset per item with extract_parts save_as 'assets' (each cut-out a 1024 sprite). Call it once per request and show the result; ask the user before generating again (each call spends credits). Every image is drawn in exactly one of Voidless's fixed style presets, and the result says which one was used and why.

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": {
      "prompt": "<prompt>",
      "type": "<type>"
    },
    "name": "generate_image"
  }
}

Input Schema

Name	Required	Description	Default
`pose`	No	Characters, front or side view: 'idle' = relaxed stance with the arms down — the default, for animation sets, rotations and almost everything. 'tpose' = arms held straight out — ONLY when the user asks for a T-pose (e.g. to rig the character in the skeleton editor).	idle
`seed`	No	RNG seed (0 = random)
`size`	No	Output px. 32, 48, 64, 96, 128, 192, 256 and 384 give pixel art; 512 for every other style; 768 for a sharper smooth sprite (drawn at 1024, stored at 768); 1024 for high-res. 2048 and '4k' are ASSET-SHEET sizes, only for type 'artwork' with model 'gpt-image-2.6' in a smooth (not pixel) style: 2048 = 2048x2048 (aspect '16:9': 2560x1440), '4k' = 2880x2880 (aspect '16:9': 3840x2160), kept at that size. For a set of matching assets to cut apart with extract_parts save_as 'assets'.
`type`	Yes	'character' = full-body sprite (uses facing/pose/bodyType); 'character portrait' = headshot; 'object' = props and items; 'artwork' = scenes/backgrounds; 'tileset' = a terrain tile sheet (always GPT-Image, see tilesetKind; below 512 it is drawn at 512 and pixelated); 'ui' = interface pieces (see uiMode).
`model`	No	Only when the user names a model. Left out, the server picks by size: flux2-klein up to 64 px, gpt-image-2.5 from 96 px.
`style`	No	Style preset: pixel-art, cartoon, cel-shading, flat, hand-drawn, paper-cutout, comic-book, anime, watercolor, low-poly, 3d-render, claymation, photorealistic, voxel. Always ends up as one of these: another value is mapped to the nearest preset ('watercolour', '8-bit', 'realistic'), or the default if none fits. Empty = the preset the prompt names, at 512/1024 for non-pixel styles (at 32-384 the result is pixel art); otherwise pixel art below 512, cartoon at 512/1024.
`aspect`	No	type 'artwork' at size 512, 1024, 2048 or '4k' only: '16:9' for a backdrop, scene or game background (1344x756 at 1024, 672x378 at 512; pixel-art styles come out on a 4 px grid, 672x376 at 512; 2560x1440 at 2048, 3840x2160 at '4k'). Smaller sizes, Retro Diffusion and everything that is not artwork are always 1:1	1:1
`facing`	No	Characters: front view or side profile. Side profiles rotate best.	forward
`prompt`	Yes	The subject (max 300 chars; an asset sheet, type 'artwork' at size 2048 or '4k', up to 1000 so each item and its view can be named). Prefer the style/palette fields; if style is empty, a style the prompt names (e.g. 'watercolour frost mage', 'a cel-shaded golem') picks that preset and those words are taken out of the prompt, so the preset's own style words are the only ones the model sees.
`uiMode`	No	type 'ui' only: 'graphic' = button/panel/HUD piece, 'title' = game-title wordmark spelling the prompt, 'text' = plain label spelling the prompt	graphic
`palette`	No	Colour-scheme preset, independent of style. 'none' = the palette the prompt names (e.g. 'in a neon palette', 'greyscale'), else the style's own colours. Pixel art (32-384 px, or a pixel style) is also held to the preset's colours: gameboy (the 4 DMG greens), cga (4), pico8 (16 fixed), c64 (16 fixed), nes (16 from the NES set), endesga32 (32 fixed), black-and-white (5 greys), sepia (8); retro, earthy, sunset, ice, dungeon, forest, desert, candy and cyberpunk set the mood and cap the colours (12-16). Edits, rotations and animations of the asset keep its palette. There is no colour-count setting: Voidless picks it by size.	none
`bodyType`	No	Characters: body plan	humanoid
`dimension`	No	'2d' = side view, 'top down' = overhead, 'isometric' = 2.5D	2d
`styleImage`	No	Optional image whose art style to copy: an image key from one of your assets (get_asset lists them, e.g. assets/64/images/<id>.png) or its cdn.voidless.dev URL. The server loads it at full resolution. Prefer this (or styleAssetId) over base64: get_image_data only returns a small thumbnail. With gpt-image-2.6 the picture itself is shown to the model; other models get a description of its style
`tilesetKind`	No	type 'tileset' only: 'platformer' = side-view 3x3 ground sheet (default for 2d); 'wang' = top-down two-terrain 4x5 auto-tile sheet in the free Tileset Generator's layout (default for top down; name both terrains, e.g. 'a cobblestone path in grass'), every edge matched so any arrangement tiles seamlessly; 'blob17' = top-down 17-piece sheet of one terrain on transparent. Top-down sheets have 256 px tiles; a pixel size returns pixel tiles at that size (up to 256)
`styleAssetId`	No	Optional: the id of one of your image assets whose art style to copy (its main image, full resolution). Same as passing its image key as styleImage
`referenceImage`	No	Optional raw base64 image (no data: prefix) to base the result on

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 profile (not read-only, not idempotent, not destructive), so the description carries the real burden and does: it discloses credit costs per model, that every call spends credits, that a reference image doubles nano-banana-2 cost to 2 and switches to flux2-klein, and how the server auto-selects a model by size. It also explains that output is always one of a fixed preset set and that the result reports which preset was used and why.

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, then the exclusion, then inference guidance, then cost/workflow detail — a sensible order for a 17-parameter tool. It is dense but nearly every sentence carries an actionable rule. Minor waste in the per-model credit list partially repeating the earlier parenthetical (flux2-klein 1, gpt-image-2.5 3), but that redundancy is small relative to the tool's complexity.

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 17-parameter generator with no output schema and thin annotations, the description covers the decision-critical pieces: when to use it, how to fill fields, how models are chosen and priced, and the multi-step asset-sheet workflow. Gaps remain around seed, style transfer (styleImage/styleAssetId), and what the returned asset looks like beyond the style-preset note, but these are low-risk given full schema documentation.

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 adds genuine cross-parameter meaning the schema does not: the model-by-size selection rule with prices, the asset-sheet triple ('artwork' + 'gpt-image-2.6' + 2048/'4k' at 20/30 credits), and the mapping of a reference image to a specific model. It does not cover seed, styleImage, referenceImage, or dimension, leaving those entirely to the schema.

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 ("Generate a game sprite/asset image") and immediately scopes it against a named sibling ("use this, not the free generate_items"). An agent can distinguish this from generate_items, generate_asset_set, and edit_image without opening any 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?

Explicit routing rules: use this for a described item/weapon/icon instead of generate_items; infer every field rather than asking; omit model unless the user names one; call once per request and ask before regenerating. The asset-sheet path names the exact parameter combination and the follow-up tool (extract_parts save_as 'assets').

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?