aseprite-ai-artist

Overview Schema Source Related Servers Discussions Admin

Look at the sprite

look

Read-only

Inspect the current sprite canvas to verify appearance and detect changes. Use preview, ascii, filmstrip, or diff modes for visual and pixel-level analysis.

Instructions

See what is actually on the canvas. Ops: • 'preview' — a nearest-neighbour upscaled PNG of the active frame (~1024px long edge). Use for overall read: silhouette, colour, whether it looks like the thing. • 'ascii' — an exact text grid, one glyph per pixel with a colour legend and coordinate rulers. Use to verify precise pixel positions and values, to count cells, or on any client without vision. Capped at 64×64; pass a region to crop. • 'filmstrip' — every frame composited into one image. The only reliable way to review an animation, since a vision model reads just the first frame of a GIF. • 'diff' — a pixel-level text diff between two frames: '.' unchanged, '-' erased, glyph = the new colour. Use it to confirm exactly what an edit touched. Draw, then look, then fix. Do not report a sprite finished without looking at it.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`op`	No		preview
`frame`	No	1-based frame number. Omit to use the active frame.
`layer`	No	Read a single layer instead of the composited image.
`scale`	No	Integer upscale for image ops, 1-128 (clamped so the output stays under ~2048px). Omit it — the automatic choice targets a ~1024px long edge, which is what a vision model can actually read.
`region`	No	Crop. Required for 'ascii' on sprites larger than 64×64.
`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.
`toFrame`	No	Diff: the later frame.
`fromFrame`	No	Diff: the earlier frame.

Output Schema

TableJSON Schema

Name	Required	Description
`op`	Yes
`rows`	No
`text`	No	The grid, for 'ascii' and 'diff'.
`scale`	No
`width`	Yes
`frames`	No
`height`	Yes
`legend`	No	glyph → #rrggbb.
`sprite`	Yes
`columns`	No
`totalPixels`	No
`changedPixels`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedv0.1.6Sep 9, 2026

changedInput schema / properties / scale / description

Previous value: -"Integer upscale for image ops. Omitted means auto."New value: +"Integer upscale for image ops, 1-128 (clamped so the output stays under ~2048px). Omit it — the automatic choice targets a ~1024px long edge, which is what a vision model can actually read."

changedInput schema / properties / scale / maximum
```
Previous value: -16New value: +128
```

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.9/5.0

Behavior5/5

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

Annotations already mark readOnlyHint=true and openWorldHint=false, and the description adds substantial behavioral detail beyond that: preview is a nearest-neighbour upscaled PNG, ascii is an exact text grid with legend and rulers, filmstrip composites all frames (and notes why it's needed because vision models read only first GIF frame), and diff shows pixel-level changes. It also discloses constraints like the 64x64 ascii cap and scale clamping, which is excellent transparency.

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 structured with bullet points for each op, front-loaded with the overall purpose, and ends with a workflow directive. Each sentence is informative and necessary; there is no fluff. The length is justified by the tool's versatility, and the format makes it easy to scan.

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?

With an output schema present, return values are covered elsewhere. The description covers all operations, their constraints, and the workflow. It explains when to use each op and even warns about pitfalls (e.g., GIF first-frame issue). There are no obvious gaps for an agent to correctly select and invoke this tool.

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 88% (all params except op have descriptions), so the baseline is 3. The description adds extra meaning for scale (explains why omitting it is optimal) and region (required for ascii on large sprites), which goes beyond the schema. It does not repeat schema details but adds practical context, so a 4 is appropriate.

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 states a clear verb+resource ('See what is actually on the canvas') and then enumerates four distinct operations (preview, ascii, filmstrip, diff), each with a specific purpose. It distinguishes itself from sibling tools by focusing on inspection/reading rather than modification, and the ops are well-defined.

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?

Explicit guidance is given for each op: preview for overall read, ascii for precise pixel verification, filmstrip for animation review, and diff for confirming edits. The workflow directive 'Draw, then look, then fix' and the warning not to report finished without looking add clear usage context. No exclusions are needed because the tool is the canonical inspection tool.

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

Deploy Server