Skip to main content
Glama

create_sprite

Destructive

Create a new Aseprite sprite file with a set canvas size, color mode, and optional background fill, saved as an editable, layer-preserving document.

Instructions

Create a new sprite file and save it.

Args:
    filename: Output path. Relative paths go in the workspace. Use a
        .aseprite/.ase extension to keep layers & frames editable.
    width, height: Canvas size in pixels. Each axis is capped at 16384px
        and the total area at 16,777,216 pixels (e.g. 4096x4096).
    color_mode: "rgb" (default), "indexed", or "gray".
    background: Optional fill colour for the first layer (e.g. "#1d2b53").
        Omit for a transparent canvas.
    overwrite: Replace `filename` if it already exists (default False = no-clobber).

An **indexed** sprite is created with a usable 33-colour palette: a transparent
entry at index 0 (the index that means "no pixel here"), then the 32 colours
Aseprite ships as its default. Aseprite's own new indexed sprite has 256 entries of
identical black instead, which made every colour equidistant from every entry, so
every draw resolved to index 0 and was invisible while reporting success. A
`background` colour that the default palette does not contain is appended to it, so
the background is the exact colour asked for rather than the nearest one available.
Replace the whole palette with `set_palette` when you have one in mind.

Returns the new sprite's structured info.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
widthYes
heightYes
filenameYes
overwriteNoDefault: false.
backgroundNo
color_modeNoDefault: "rgb".rgb

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed12 schema fields changedv0.10.0
    • removedInput schema / properties / background / anyOf
      Removed value: -[
      -  {
      -    "type": "string"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]
    • removedInput schema / properties / background / default
      Removed value: -null
    • removedInput schema / properties / background / title
      Removed value: -"Background"
    • addedInput schema / properties / background / type
      Added value: +"string"
    • addedInput schema / properties / color_mode / description
      Added value: +"Default: \"rgb\"."
    • removedInput schema / properties / color_mode / title
      Removed value: -"Color Mode"
    • removedInput schema / properties / filename / title
      Removed value: -"Filename"
    • removedInput schema / properties / height / title
      Removed value: -"Height"
    • addedInput schema / properties / overwrite / description
      Added value: +"Default: false."
    • removedInput schema / properties / overwrite / title
      Removed value: -"Overwrite"
    • removedInput schema / properties / width / title
      Removed value: -"Width"
    • removedInput schema / title
      Removed value: -"create_spriteArguments"
  2. First observedv0.7.0

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already declare destructiveHint=true and readOnlyHint=false, but the description adds substantial behavior the schema cannot convey: no-clobber default on `overwrite`, the 16384px per-axis / 16,777,216px area caps, and a detailed disclosure of how indexed sprites differ from Aseprite's own black-256-entry default and how an unmatched `background` colour is appended rather than snapped.

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 action, then parameter guidance, then the palette caveat. The indexed-palette paragraph is long and partially defensive in tone, but it carries real decision-relevant information and is not duplicative; still, it could be tightened by a sentence or two.

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 6-parameter creation tool with no output schema, the description covers defaults, limits, overwrite risk, extension choice, and returns ('Returns the new sprite's structured info'). With no output schema, the description notes the return shape adequately, and nothing needed to call this correctly is missing.

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

Parameters5/5

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

Schema description coverage is only 33% (just the two defaults), yet the description documents all six parameters: filename path/extension rules, per-axis and total-area pixel caps, the three color_mode values (the schema has no enum), background fill syntax and omit-for-transparent semantics, and overwrite's no-clobber default.

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 first line states a specific verb+resource ('Create a new sprite file and save it') and the body goes on to distinguish the creation behavior from the palette-editing sibling by name ('Replace the whole palette with set_palette'). An agent can tell this apart from save_sprite_as, list_sprites, and set_color_mode 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 Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives concrete when-to-use guidance: pick a .aseprite/.ase extension when layers & frames must stay editable, omit `background` for transparency, and defer to `set_palette` when a specific palette is in mind. It does not state when creation should be avoided entirely (e.g., use save_sprite_as on an existing sprite), so it falls just short of explicit exclusions.

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

Deploy Server

Other Tools