aseprite-ai-artist

Overview Schema Source Related Servers Discussions Admin

Tilesets

tileset

Manage Aseprite tilemap layers, create tile collections from painted layers, stamp tiles by grid coordinates, and export to Tiled, Godot, or JSON.

Instructions

Work with Aseprite tilemap layers. Ops: • 'list' — tilesets in the sprite. • 'create_layer' — a new empty tilemap layer on a given grid. • 'get' — tile count and, with a path, the tiles as one packed PNG. • 'stamp' — place tiles by grid coordinate. x/y are grid cells, not pixels. • 'pack' — turn a hand-painted mockup layer into a tileset plus a tilemap that reconstructs it exactly. Deduplicates identical cells; tolerance also merges near-identical ones. The canvas must be a whole number of tiles, and the source layer is hidden rather than deleted so you can compare. • 'export' — writes the packed PNG plus the file the engine reads: 'tiled' (.tsj tileset and a .tmj map that uses it), 'godot' (Godot 4 .tres TileSet), or 'json' (tile grid plus the tilemap layout). Painting a level by hand and packing it produces better tilesets than authoring tiles in isolation, because you see the whole picture while drawing. layout: 'blob47' adds a Tiled wangset for autotiling, and assumes the tileset is authored in canonical blob47 order after the empty tile — it refuses rather than writing a wangset that would autotile wrongly. Requires an extension build advertising the 'tileset' feature — check preflight first.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`op`	Yes
`name`	No
`path`	No	Output path for 'export' and 'get'.
`frame`	No	1-based frame number. Omit to use the active frame.
`layer`	No	Layer name. Omit to use the active layer.
`tiles`	No	For 'stamp'. x/y are tile-grid cells, not pixels.
`format`	No		tiled
`layout`	No	Autotile layout for 'export'.	grid
`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.
`tileWidth`	No
`tolerance`	No	For 'pack': maximum per-channel difference at which two cells count as the same tile. 0 means exact, which is also much faster — anything above 0 compares every cell against every tile found so far.
`tileHeight`	No

Output Schema

TableJSON Schema

Name	Required	Description
`op`	Yes
`rows`	No
`files`	No
`layer`	No
`format`	No
`layout`	No
`sprite`	Yes
`columns`	No
`skipped`	No	For 'stamp': placements outside the grid or naming a tile that does not exist.
`tilesets`	No
`cellCount`	No	For 'pack': grid cells examined.
`tileCount`	No
`tileWidth`	No
`tileHeight`	No
`reusedExact`	No	For 'pack': cells that matched an existing tile exactly.
`reusedFuzzy`	No	For 'pack': cells merged by `tolerance`. A high number here with a low tolerance means the mockup has near-duplicate tiles worth cleaning up.
`sourceLayer`	No	For 'pack': the mockup layer, now hidden.

Schema Changelog

Changes observed during successful MCP inspections.

Changed14 schema fields changedv0.1.6Sep 9, 2026

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."

changedInput schema / properties / tolerance / description

Previous value: -"For 'pack': treat near-identical tiles as one."New value: +"For 'pack': maximum per-channel difference at which two cells count as the same tile. 0 means exact, which is also much faster — anything above 0 compares every cell against every tile found so far."

changedInput schema / properties / tolerance / maximum
```
Previous value: -64New value: +255
```

addedOutput schema / properties / cellCount

Added value: +{
+  "description": "For 'pack': grid cells examined.",
+  "type": "integer"
+}

addedOutput schema / properties / columns
```
Added value: +{
+  "type": "integer"
+}
```
addedOutput schema / properties / format
```
Added value: +{
+  "type": "string"
+}
```
addedOutput schema / properties / layout
```
Added value: +{
+  "type": "string"
+}
```

addedOutput schema / properties / reusedExact

Added value: +{
+  "description": "For 'pack': cells that matched an existing tile exactly.",
+  "type": "integer"
+}

addedOutput schema / properties / reusedFuzzy

Added value: +{
+  "description": "For 'pack': cells merged by `tolerance`. A high number here with a low tolerance means the mockup has near-duplicate tiles worth cleaning up.",
+  "type": "integer"
+}

addedOutput schema / properties / rows
```
Added value: +{
+  "type": "integer"
+}
```

addedOutput schema / properties / skipped

Added value: +{
+  "description": "For 'stamp': placements outside the grid or naming a tile that does not exist.",
+  "type": "integer"
+}

addedOutput schema / properties / sourceLayer

Added value: +{
+  "description": "For 'pack': the mockup layer, now hidden.",
+  "type": "string"
+}

addedOutput schema / properties / tileHeight
```
Added value: +{
+  "type": "integer"
+}
```
addedOutput schema / properties / tileWidth
```
Added value: +{
+  "type": "integer"
+}
```

First observedv0.1.0Sep 8, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Annotations only set readOnlyHint=false and openWorldHint=false, leaving the description to carry behavioral detail. It discloses non-obvious behaviors: 'stamp' uses grid cells not pixels, 'pack' deduplicates and hides (not deletes) the source layer, 'blob47' refuses when ordering is wrong, and 'tolerance' has performance implications. This goes well beyond the schema.

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?

The description is long but appropriately so for a multi-operation tool. It front-loads the purpose, then lists ops in a scannable bullet format, and adds a rationale paragraph at the end. Every sentence serves a purpose, with no filler. It could be slightly more compact, but the structure aids readability.

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?

With 12 parameters and six operations, the description covers most critical details: output formats, grid semantics, preconditions, and error behavior. An output schema exists (per context), which likely covers return structures. Minor gaps include exact return values for 'list' and 'create_layer', but these are not critical for correct invocation.

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 58%, so the description must compensate for undocumented parameters. It explains 'tolerance', 'layout', 'sprite', and 'tiles' in detail, and clarifies grid-vs-pixel semantics. While 'name', 'tileWidth', and 'tileHeight' lack description-level context, they are straightforward from the schema defaults and bounds. The description meaningfully enhances understanding of the complex parameters.

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 begins with 'Work with Aseprite tilemap layers' and then enumerates six distinct operations (list, create_layer, get, stamp, pack, export). It clearly states what the tool does and each op has a specific verb and resource. It distinguishes itself from sibling tools like 'layer' and 'export' by focusing on tileset-specific functionality, so an agent can immediately understand its scope.

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?

The description provides clear guidance on when to use the 'pack' operation ('Painting a level by hand and packing it produces better tilesets than authoring tiles in isolation') and warns about prerequisites ('Requires an extension build advertising the 'tileset' feature — check preflight first'). It does not explicitly contrast with sibling tools like 'layer' or 'export', but the internal op routing is clear and context is sufficient.

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

Deploy Server