Skip to main content
Glama
Sign In

Voidless

by dev.voidless
OverviewDiscussionsAdmin

generate_items

Generate pixel-art RPG item icons from a seed, like the Pixel Item Generator on voidless.dev/tools: swords, daggers, axes, spears, staffs and wands, bows, shields, potions, gems, coins, keys, rings, scrolls and chests, or mixed loot. Each icon is built from parts (blade, guard, grip, pommel…) with random proportions, in small fixed material palettes lit from the top-left (at most 16 colours), with a 1 px dark outline; rare items get gems, epic and legendary items runes and a glow in the rarity colour. Every item has a name ("Rusty Iron Dagger", "Greater Mana Potion"). Same seed and options, same items. Returns the sheet PNG and a JSON atlas of names and positions, then each item as its own PNG when there are 16 or fewer. Quick placeholder or bulk procedural loot only: for a specific described item, a particular look, or art matching the game's existing style, use generate_image instead. Images up to 2048x2048, 256 frames, 32 MB of input per call. Free: no credits.

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

Input Schema

NameRequiredDescriptionDefault
saveNoAlso 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
seedNoSame seed, same items (default: random)
sizeNoIcon width and height, px
countNoHow many items
scaleNoScale the returned images up (nearest neighbour); the JSON positions are for the 1x sheet
typesNoItem types to draw (default: mixed loot, every type at random)
rarityNoOne rarity for every item, or random (mostly common)random
columnsNoItems per sheet row (default: square-ish)
outlineNo1 px dark outline
materialNoMain material, used where the item type can be made of it (default: random)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.6/5.0
Behavior4/5

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

Goes well beyond the annotations: determinism ('Same seed and options, same items'), the exact return shape (sheet PNG plus JSON atlas, individual PNGs only when count ≤ 16), hard limits (2048x2048, 256 frames, 32 MB input), and cost ('Free: no credits'). The only gap is that it doesn't say what happens when count exceeds 16 beyond the atlas, though that is implied.

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-loads what is generated, then output format, then the exclusion and limits. Dense but every clause carries information; the long item-type enumeration is the one stretch that could be trimmed since the enum already lists them.

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?

With no output schema, the description fully covers return values, determinism, size/count limits, and cost. For a 10-parameter generator with zero required params, an agent has everything needed to call it correctly and to know when not to.

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; the description adds real meaning on top by explaining that rarity drives visual features (gems for rare, runes and rarity-coloured glow for epic/legendary) and that material applies only 'where the item type can be made of it'. It also clarifies that scale upscales images while JSON positions stay at 1x, which the schema alone does not convey.

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 pixel-art RPG item icons from a seed') and enumerates the exact item categories produced. It also names the reference implementation and the sibling it is not (generate_image), so an agent can distinguish it without opening the 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?

Explicitly scopes use to 'Quick placeholder or bulk procedural loot only' and routes the agent elsewhere for 'a specific described item, a particular look, or art matching the game's existing style' via generate_image. Both the when and the when-not are stated with the alternative named.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Voidless toolsInspect
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