aseprite-ai-artist

Overview Schema Source Related Servers Discussions Admin

Export

export

Destructive

Export Aseprite sprites to game-ready formats: PNG, GIF, spritesheet with JSON atlas, numbered frames, or .aseprite source. Supports selecting layers, tags, frames, and scaling.

Instructions

Write game-ready files. Ops: 'png' (single frame), 'gif' (animation), 'spritesheet' (packed sheet plus a JSON atlas with per-frame and per-tag data), 'frames' (numbered PNGs), 'aseprite' (save a copy of the source). Spritesheet is what an engine actually consumes: pass sheetType and byTag to control layout. Exporting does not save the working document — use sprite_manage op 'save' for that.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`op`	Yes
`path`	Yes	Output file path. For 'frames', a pattern containing {frame}, e.g. 'walk_{frame}.png' — Aseprite expands it into one file per frame, numbered from 0.
`tags`	No	Export only these tags.
`trim`	No	Trim transparent margins; the atlas keeps the original offsets.
`byTag`	No	Split the sheet by animation tag.
`frame`	No	1-based frame number. Omit to use the active frame.
`scale`	No	Integer upscale, nearest-neighbour.
`layers`	No	Export only these layers.
`sprite`	No	Which sprite: its id as '#7' (what every result reports back, and the only unambiguous form — two unsaved documents are both called 'Sprite'), its filename, or its display name. Omit to use the sprite Aseprite has focused.
`padding`	No	Pixels between frames; prevents bleed at non-integer zoom.
`sheetType`	No	Spritesheet layout.	horizontal
`includeJson`	No	Write a sibling JSON atlas for 'spritesheet'.

Output Schema

TableJSON Schema

Name	Required	Description
`op`	Yes
`atlas`	No
`files`	Yes
`frame`	No	Which frame a single-frame export wrote. Defaults to the active frame, which is not always the one you drew on.
`width`	No
`height`	No
`sprite`	Yes
`frameCount`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv0.1.6Sep 9, 2026

changedInput schema / properties / path / description

Previous value: -"Output file path. For 'frames', a pattern like 'walk_{frame}.png'."New value: +"Output file path. For 'frames', a pattern containing {frame}, e.g. 'walk_{frame}.png' — Aseprite expands it into one file per frame, numbered from 0."

changedInput schema / properties / sprite / description

Previous value: -"Sprite filename or id. Omit to use the sprite Aseprite has focused."New value: +"Which sprite: its id as '#7' (what every result reports back, and the only unambiguous form — two unsaved documents are both called 'Sprite'), its filename, or its display name. Omit to use the sprite Aseprite has focused."

First observedv0.1.0Sep 8, 2026

TDQS

A4.7/5.0

Behavior4/5

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

Annotations already declare destructiveHint=true, and the description adds meaningful context by clarifying that export does not persist the working document, which is a key behavioral distinction from sprite_manage. It also explains the output format (JSON atlas for spritesheet) without contradicting the annotations. It does not mention overwrite behavior or side effects on existing files, but the annotation already covers destructiveness, so the added context is sufficient.

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 four sentences with zero wasted words. The main verb is front-loaded, ops are listed compactly, the critical spritesheet guidance is placed early, and the save-disambiguation is at the end. Every sentence earns its place.

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?

Given the tool's complexity (12 parameters, 5 ops, multiple formats), the description covers the essential context: what each op does, the spritesheet consumption hint, and the crucial distinction from sprite_manage. The schema covers parameter details, and an output schema exists (not shown), so the description does not need to explain return values. It is complete for an agent to select and invoke the tool correctly.

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 92% (most parameters have descriptions), so the baseline is 3. The description adds value beyond the schema by explaining the ops and how parameters like `sheetType` and `byTag` control spritesheet layout, and by clarifying the `path` pattern for 'frames'. This helps an agent understand the semantics without opening the schema, slightly exceeding the baseline.

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 opens with a specific verb+resource ('Write game-ready files') and then enumerates each operation with a short, distinct explanation (png, gif, spritesheet, frames, aseprite). It explicitly differentiates the spritesheet op as the engine-consumable format and names the sibling tool (sprite_manage op 'save') for a different purpose, making its scope unambiguous.

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 provides explicit when-not-to-use guidance by stating 'Exporting does not save the working document — use sprite_manage op 'save' for that.' It also gives usage direction for the spritesheet op ('Spritesheet is what an engine actually consumes: pass `sheetType` and `byTag` to control layout'), helping an agent choose the right op and parameters.

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

Deploy Server