Skip to main content
Glama

Quote a SpriteForge generation

quote_generation
Read-only

Price an AI generation without starting it: same arguments as generate. Returns the exact price (the amount generate will charge; failed calls are refunded), the balance, whether it's affordable, and the typical time. Show the user the price and wait for their go-ahead before generate, unless they've said to go ahead without asking. Read-only.

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.
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.
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?

Annotations already declare readOnlyHint=true and openWorldHint=false, and the description is consistent ("Read-only"). It adds genuinely non-derivable behavior: that the price equals what `generate` will charge, that failed calls are refunded, and that it also returns balance, affordability, and typical duration — all useful for the agent's decision loop.

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?

Three sentences, all front-loaded: what it does, what it returns, how to use it, and the read-only marker. Nothing repeats the schema and no sentence is filler.

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 36 parameters and no output schema, the description must carry the return-value burden — and it does, naming price, balance, affordability, and time. Combined with a fully documented schema, an agent has everything needed to call and interpret this tool.

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% across 36 params, so the schema carries the field-level detail and the baseline is 3. The description earns a bump by telling the agent the argument set mirrors `generate`, which removes the need to reason about whether the two tools accept different inputs.

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+resource — price a generation without starting it — and immediately anchors it to the sibling `generate` by noting it takes the same arguments. An agent can distinguish quoting from generating 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?

Explicitly prescribes the workflow: show the user the price and wait for go-ahead before `generate`, with a stated exception (user already said to proceed without asking). Names the alternative tool and the condition that selects it.

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