Skip to main content
Glama

Generate pixel art with SpriteForge

generate
Destructive

Start an AI generation that spends the user's SpriteForge credits; the result is saved into their library. Unless the user has said to go ahead without asking, quote_generation first and get their OK on the price. max_cents is required: the job is refused if its price is higher (use the quoted price, or the user's budget). Returns a job_id - call get_job with it to wait for the result (most sprites take 20 s to a few minutes). Pass a request_id to make retries safe: the same request_id never starts or charges a second job.

Input Schema

NameRequiredDescriptionDefault
colsNomultiterrain: map width in tiles (default 16).
nameNoName for the new sprite (default: the artist names it).
rowsNomultiterrain: map height in tiles (default 12). The whole map (cols x rows x tile size) must stay under about 160,000 pixels.
tierYesModel x effort. If the user hasn't chosen, choose for them from get_generation_options: Sonnet is the usual default up to 32px, Opus for 48-64px canvases, complex characters and final assets, Haiku for cheap small icons. Low/High variants trade price and time for care.
typeYesWhat to make. single = one sprite. edit = AI-change a library sprite (asset_id + prompt). set = 1-8 sprites sharing one palette (subjects). animation = a looping animation (subject + frame_count; give asset_id to animate a library sprite). phased = one sprite drawn in 2-3 staged passes, the strongest choice for humanoids. terrain = top-down wall / transition / floor tiles. wang = a 16-tile autotile terrain set. platformer = 49 side-view ground tiles incl. slopes. multiterrain = a map of 2-6 terrains blending into each other (terrains, cols, rows).
lightNoLight direction, e.g. "Top-left" (default: the project's).
notesNoAnything else the artist should know (max 500 characters).
styleNoArt-style line for this generation, e.g. "chunky 16-bit fantasy" (on top of the project's style).
widthNoCanvas width in pixels (1-64). Required except for edit and an animation of a library sprite. Tile types need width = height (the tile size).
heightNoCanvas height in pixels (1-64).
motionNoanimation: the movement, e.g. "walk cycle". Lines starting with a frame number direct that frame ("3: raise the sword").
passesNophased: 2 or 3 passes (default 3).
promptNoedit: the change to make, e.g. "give him a red scarf".
outlineNo"Dark-tinted" (optionally "Dark-tinted:<darkness 0-100>"), "Black" or "None" (default: the project's).
subjectNoWhat to draw - single, phased, animation; the material for terrain (the wall) and wang; for platformer the ground surface on top, e.g. "lush grass". Concrete beats vague: subject, pose, colours, materials, mood.
asset_idNoedit: the library sprite to change (required). animation: a library sprite to animate - it becomes the loop's rest pose and sets the size.
subjectsNoset: one short description per sprite.
symmetryNo"Off", or a note such as "horizontal" - mirrored after drawing.
terrainsNomultiterrain: the terrains, e.g. grass, sand, water.
max_centsYesThe most this generation may cost, in US cents.
set_themeNoset: the theme they share, e.g. "medieval armory icons".
subject_bNoterrain: the floor material (default: same as subject). platformer: the earth fill under the surface, e.g. "dark packed earth" (default: same as subject).
aggressionNoanimation: how hard poses are pushed (default normal).
mask_cellsNoedit: limit the change to these [x,y] pixels; everything else is kept.
open_endedNoanimation: a one-shot progression that doesn't loop back to the start.
project_idNoProject to generate into (default: the most recently used). Its style, description, light, outline and palette steer the result.
referencesNoLibrary sprites (up to 64px) that guide the result: role style (default) copies the look, subject copies what's depicted. Used by single, edit, set, phased, wang and multiterrain; each adds a small surcharge.
request_idNoOptional idempotency key, unique per intended generation.
detail_tierNophased: a second tier for the passes after the silhouette, e.g. tier "Opus High" + detail_tier "Sonnet".
frame_countNoanimation: drawn motion frames (1-8; the rest pose of an animated library sprite isn't counted).
perspectiveNoe.g. "side view", "3/4 top-down", "isometric".
save_as_newNoedit: save the result as a new sprite instead of updating the original (whose old version is otherwise kept in its history).
terrain_mapNomultiterrain: rows x cols of indexes into terrains - a painted layout (default: the server paints one).
lock_paletteNoSnap the result strictly onto the project palette.
terrain_rulesNomultiterrain: optional edge-blend rules.
animation_nameNoanimation of a library sprite: the name it's saved under on that sprite (default "idle").
use_project_styleNoApply the project's style and description (default true).
use_project_paletteNoSteer toward the project's palette (default true).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.9/5.0
Behavior5/5

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

The annotations already mark this as destructive and non-read-only, and the description adds important context: it spends the user's credits, refuses the job if priced above max_cents, saves output to the library, and typically takes 20 seconds to a few minutes. The request_id behavior is also explicitly described, which is more than the annotations convey.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core behavior and cost implications, then covers pricing approval, the max_cents guardrail, polling, and idempotency in compact sentences. Every sentence carries operational value.

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?

For a complex 38-parameter generation tool with no output schema, the description covers the critical workflow, cost risk, required approval step, return value (job_id), polling path, and retry safety. The schema supplies the detailed mode-specific parameters, so nothing essential is missing.

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 all 38 parameters are documented structurally. The description still adds meaningful semantics for max_cents (use the quoted price or the user's budget, and the job is refused if the price exceeds it) and request_id (same id never starts or charges a second job), though it does not add much beyond the schema for the larger mode-specific parameters.

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 description uses a specific verb and resource: 'Start an AI generation' for SpriteForge pixel art, and states that the result is saved into the user's library. It cleanly distinguishes itself from siblings by naming quote_generation and get_job as the pricing and polling steps.

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 when-to-use and sequencing guidance: quote_generation first unless the user already approved, then generate, then call get_job with the returned job_id. It also states the required max_cents guardrail and when to use request_id for safe retries.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources