aseprite-mcp

Overview Schema Source Related Servers Discussions Admin

export

Save sprite copies to PNG, GIF, WebP, JPG, SVG, or other formats using scale, tags, frame ranges, slices, layers, and filename templates; multi-frame single-image output writes one file per frame.

Instructions

Exports a copy of the sprite to any format (png, gif, webp, jpg, bmp, tga, pcx, ico, qoi, flc, svg, css, ...). Options: scale, a tag or a 1-based frame range, a slice, specific layers, or a filename template like 'out_{frame}.png' ({frame} counts from 0). Single-image formats with several frames get one file per frame (name1.png, name2.png..., or starting from a trailing number in the name); the result lists every file written.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "file": "<file>"
    },
    "name": "export"
  }
}

Input Schema

Name	Required	Description
`tag`	No
`file`	Yes
`scale`	No
`slice`	No
`aniDir`	No
`bounds`	No
`layers`	No	Export only these layers
`sprite`	No	File path, open tab title, or sprite id. Defaults to the active sprite (live). Batch mode needs a file path.
`backend`	No	auto (default): live Aseprite if connected, else headless batch
`toFrame`	No
`fromFrame`	No
`ignoreEmpty`	No
`playSubtags`	No
`filenameFormat`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.1Oct 18, 2026

TDQS

A3.6/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=false and destructiveHint=false, but the description adds real behavioral context beyond them: single-image formats emit one file per frame, the trailing-number / templated naming scheme, and that the result lists every file written. It stops short of stating overwrite semantics or permission needs, but it is well above the annotation-only bar.

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?

Three sentences, purpose front-loaded, with the options and the multi-file output behavior packed into the following sentences. Dense but every sentence carries information; no filler.

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

Completeness3/5

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

For a 14-parameter tool with a nested bounds object, two enums, and no output schema, the description usefully explains the return ('lists every file written') but leaves multiple parameters unexplained. It is adequate but not complete enough to call all 14 params correctly.

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 only 21%, so the description must carry the load; it explains scale, tag, 1-based frame range, slice, layers, and the filename template ({frame} counting from 0), which maps to several parameters. It still leaves bounds, aniDir, ignoreEmpty, and playSubtags undocumented in both schema and description, so it only partially compensates for the coverage gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description gives a specific verb and resource ('Exports a copy of the sprite') plus the output surface ('any format' with a format list), so an agent immediately knows this writes image files. It does not, however, differentiate from the very close sibling export_sprite_sheet or save_sprite, leaving the agent to infer the boundary.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

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

It enumerates the options (scale, tag, frame range, slice, layers, filename template), which implies how to use the tool, but never states when to reach for it over export_sprite_sheet, render_preview, or save_sprite, and offers no when-not guidance.

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

Deploy Server