Skip to main content
Glama

Generate variants

generate_variants

Generate pixel-art variants of an existing sprite (in-app Variants), or edit it in place with keep_footprint. Source: asset_id (+ artboard_id/artboard_name for multi-artboard files) OR style_reference_id. Defaults when the user does not say: creativity creative, density quality, Variants (not Edit). State the assumptions you used; ask only for what cannot be inferred. Edit = keep_footprint true + custom_prompt (or color_mood alone to recolour only). Replace = creativity "replace" + custom_prompt naming the new object (e.g. "wooden barrel"). Results keep the source artboard size and are appended to the source file. Only an off-center subject blocks (fix_preflight: true re-centers it); brush/size findings are advisory warnings (fix_preflight: "all" applies them). ~8 credits (HD).

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_variants"
  }
}

Input Schema

NameRequiredDescriptionDefault
saveNoAppend finished artboards into the source library file (default true). From a style ref → create a new library file.
countNoOptional hard cap on variant count. Density (max/quality/quantity) sets the plan; when both are set, count is clamped to the plan’s effectiveCount. Prefer density.
labelsNoOptional per-variant names. Defaults to 'Variant 1'..N from the density plan. Same cap as the in-app label inputs (60 characters).
densityNomax (1) | quality (~3, default) | quantity (as many as fit). Edit (keep_footprint) forces max.
asset_idNoSource library asset id (from list_assets). Provide this OR style_reference_id (in-app Variants reference-as-source).
set_nounNoFor creativity "set": category noun (e.g. "swords"). Default "items"; ignored otherwise.
folder_idNoOptional Files folder for a new library file when sourcing from style_reference_id.
reimagineNoEdit only: allow freer re-imagining (in-app Reimagine). Default false.
color_moodNoOptional recolour mood (same as the app). Omit to keep the source colours.
creativityNorecolor (Reskin) | creative (Reskin Creative, default) | set | custom (Prompted) | replace (Replace: swap the subject for the object named in custom_prompt at the same size, position and camera; one result). Edit (keep_footprint) forces custom.
project_idNoWhen sourcing from style_reference_id: project for the new library file (defaults like generate_pixel_art).
artboard_idNoOptional artboard id from get_asset. Multi-artboard files need artboard_id or artboard_name to pick one sprite; omit for single-artboard assets.
color_policyNoPalette policy matching in-app ColorPolicyControl: "32"|"64"|"128"|"256" (max colors) or "none" (don't reduce). Default "128". Put palette caps here, not in the prompt.
artboard_nameNoOptional artboard name from get_asset (e.g. "rocks_crystal"). Alternative to artboard_id.
custom_promptNoRequired when creativity is 'custom' (Prompted / Edit) — subject/style instruction only. Put size on the source artboard (not '64x64' here); put palette caps in color_policy; omit 'no anti-aliasing' / 'crisp pixel clusters' lectures. Same cap as the in-app prompt box: longer text is trimmed to the first 1000 characters and the reply says so.
fix_preflightNotrue = re-center the subject for this run (the only blocking finding). "all" = also apply the advisory brush and artboard-resize fixes, which can change the output size. Default false. The saved library file is not changed.
project_styleNoStyle for this generation: "project" (default) draws the result in the game world of the account's active style (its brief, see get_style_profile); "none" leaves the brief out for a one-off asset outside that world.
keep_footprintNotrue = Edit (in-place edit that keeps the silhouette; forces custom + single output; needs custom_prompt, or color_mood alone for a recolour-only edit). Default false = Variants.
style_reference_idNoUse a References library image as the Variants source (same as in-app picking a style ref on Variants). Alternative to asset_id. Results save as a new library file.
preserve_compositionNoDefault true. Set false only when the user wants a freer layout.

Schema Changelog

Changes observed during successful MCP inspections.

No schema history has been recorded yet.

TDQS

A4.4/5.0
Behavior4/5

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

Annotations only declare it as a non-readonly, open-world, non-idempotent write. The description adds genuinely non-obvious behavior: results inherit the source artboard size and are appended to the source file, cost is ~8 credits HD, and preflight outcome rules (only an off-center subject blocks; brush/size findings are advisory and only applied with fix_preflight "all", which can change output size). The one gap is that it never explains what the call returns (ids, plan, per-variant records) before get_generation_result, but with no output schema that is a minor omission against an otherwise rich disclosure.

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 the core action and defaults, then mode-specific rules, then operational facts (size, save location, preflight, credits). It is dense but nearly every clause carries a decision the agent must make; the telegraphic fragments ('creativity creative, density quality') and semicolon chaining cost some immediate parseability.

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 20-parameter, no-required-field generation tool with no output schema, the definition covers what an agent most needs: which parameters select which mode, what happens to the source file, what the output size is, what blocks versus warns, and the credit cost. Nothing critical for a correct call is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the schema descriptions are already detailed, so the baseline is 3. The description does add cross-parameter logic the schema cannot express—keep_footprint forces custom and a single output, creativity "replace" requires custom_prompt to name the object, palette caps belong in color_policy rather than the prompt—which is real added meaning, but it largely restates the prominent enum semantics already documented per-parameter.

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 opening sentence states a specific verb and resource ('Generate pixel-art variants of an existing sprite') and immediately splits the two modes (Variants vs in-place Edit via keep_footprint). It also names the two mutually exclusive sources (asset_id vs style_reference_id), so an agent can distinguish it from generate_pixel_art or reskin_character without opening sibling schemas.

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 defaults are given for the ambiguous case ('Defaults when the user does not say: creativity creative, density quality, Variants (not Edit)'), plus a decision rule for asking versus inferring. It also spells out the exact parameter combinations that select each mode: Edit = keep_footprint true + custom_prompt (or color_mood alone), Replace = creativity "replace" + custom_prompt naming the new object.

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