Skip to main content
Glama

export_spritesheet_packed

Destructive

Export a packed sprite sheet for game engines: trim frames, extrude edges to stop tile seams, merge duplicate frames, and write optional JSON metadata.

Instructions

Export a sprite sheet with the controls a game engine needs: extrude, dedupe, trim.

The sibling of `export_spritesheet`, which goes through the Aseprite CLI. This one
drives the editor's own export command, which the CLI flags do not fully reach, and
adds three things that matter when the sheet is going into an engine rather than into
a preview:

Args:
    output: Destination sheet image (.png).
    sheet_type: one of horizontal, vertical, rows, columns, packed (the default).
    trim: Trim each frame to its drawn pixels before packing, so empty margins cost
        no sheet space. The frame rectangles in the data file say where each frame
        went and how much was trimmed, so an engine can still place it correctly.
    extrude: Duplicate each frame's edge pixels one pixel outwards around its cell.
        This is the fix for the thin seam or transparent line that appears between
        tiles in Unity, Godot or a shader at non-integer zoom: the sampler reads
        half a texel past the frame's edge, and without extrude that is whatever the
        neighbouring frame or empty space holds. The frame rectangle in the data file
        still names the frame itself, not the border.
    merge_duplicates: Give identical frames one rectangle in the sheet instead of a
        copy each, which is what shrinks a sheet full of held poses. Identical by
        pixels, so it catches both a duplicated frame and a linked cel. A packed
        sheet does this anyway and the result says so.
    padding: Pixels of padding around and between frames, as `export_spritesheet`.
        Padding separates frames; extrude fills the gap at the frame's own edge.
        They solve different halves of the same bleeding problem and compose.
    data_output: Optional .json path for the sheet metadata, which also carries the
        layer, tag and slice lists.
    data_format: "json-array" (the default when `data_output` is given) or
        "json-hash". The array form lists frames in order, which an engine indexing
        by frame number wants; the hash form keys them by name, which a loader
        looking frames up by name wants. The tag section is called `frameTags` in
        both.
    overwrite: Replace existing output(s) (default False = no-clobber). When
        `data_output` is given, both files are checked before anything is written.

The source sprite is not modified: verified, the file's bytes and frame count are the
same afterwards, including with trim and extrude set.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
trimNoDefault: false.
outputYes
extrudeNoDefault: false.
paddingNoDefault: 0.
filenameYes
overwriteNoDefault: false.
sheet_typeNoDefault: "packed".packed
data_formatNo
data_outputNo
merge_duplicatesNoDefault: false.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.10.0

TDQS

A4.5/5.0
Behavior4/5

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

Annotations declare destructiveHint=true and readOnlyHint=false, but the description directly addresses this: 'The source sprite is not modified: verified, the file's bytes and frame count are the same afterwards, including with trim and extrude set.' This casts the mutation as output-file-only, which is valuable context beyond annotations. It also explains overwrite's no-clobber default and that both files are checked before writing. Slight tension with destructiveHint is resolved rather than contradicted.

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

Conciseness3/5

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

Front-loaded with purpose and the sibling distinction in the first paragraph, which is good. But the argument section is very long and partly prose-essay (Unity sampler half-texel explanation), which is thorough yet heavy for a tool description. Earns its place mostly, but less economical than ideal.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers a 10-parameter export tool with no output schema: what each control does, the default sheet_type, data_format behavior, no-clobber semantics, and even a non-modification guarantee. Return values aren't described, but metadata is captured via data_output. Nearly complete for the complexity.

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 coverage is 60%, so the description must carry the rest and largely does. It explains the meaning and purpose of trim, extrude, merge_duplicates, padding, data_output, data_format (including the json-array vs json-hash choice and frameTags), and overwrite. It even clarifies how padding and extrude compose. Only sheet_type enum values are fully enumerated.

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 ('Export a sprite sheet') and immediately names its scope ('with the controls a game engine needs'). It explicitly distinguishes itself from the sibling export_spritesheet: 'The sibling of export_spritesheet, which goes through the Aseprite CLI. This one drives the editor's own export command, which the CLI flags do not fully reach.'

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?

Names the alternative (export_spritesheet) and the condition selecting this tool: it drives the editor's own export and reaches flags the CLI doesn't. Also frames the whole tool as for 'sheet going into an engine rather than into a preview,' an explicit use case boundary.

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