Skip to main content
Glama
Sign In
Aseprite AI Artist

Aseprite AI Artist

by mohandtest
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Local

Look at the sprite

look
Read-only

Inspect the Aseprite canvas as previews, pixel-accurate ASCII grids, filmstrips, onion-skin views, diffs, or reference comparisons to verify artwork before reporting it finished.

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. Reads up to the whole canvas; pass a region to crop. Glyphs are bound to palette indices, so every region and frame of a sprite agrees on what a glyph means; each read's legend lists only the colours it contains, so merge legends when rows from one piece go into another. Only colours outside the palette (listed in offPalette) get per-read glyphs. rulers=false prints the bare rows, which draw kind 'grid' takes back as-is: read a layer, edit the rows, send them at the same x/y. • '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. • 'onion' — the target frame at full opacity over ghosted neighbouring frames, oldest-first. Use to check in-betweens and spacing while animating, without stepping through frames one at a time. Over an opaque background the target hides every ghost — pass layer to onion-skin just the part that moves. • 'diff' — a pixel-level text diff between two frames: '.' unchanged, '-' erased, glyph = the new colour. Use it to confirm exactly what an edit touched. • 'compare' — the reference layer (left, full opacity) beside the art without any reference layer (right), same frame, same scale. Use it when drawing from a concept or storyboard: name the few largest mismatches and fix only those. Draw, then look, then fix. Do not report a sprite finished without looking at it.

Input Schema

NameRequiredDescriptionDefault
opNopreview
frameNo1-based frame number. Omit to use the active frame.
layerNoRead a single layer instead of the composited image. Honoured by preview, ascii, diff, filmstrip and onion; compare has its own `reference`.
scaleNoInteger 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.
regionNoCrop. Omit to read the whole canvas.
rulersNoascii: false drops the coordinate rulers and row labels, leaving rows you can edit and pass straight to `draw` kind 'grid' with the reported origin.
spriteNoWhich 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.
toFrameNoDiff: the later frame.
fromFrameNoDiff: the earlier frame.
referenceNoCompare: the reference layer. Default 'reference'.
framesAfterNoOnion: ghost frames after the target.
framesBeforeNoOnion: ghost frames before the target.
ghostOpacityNoOnion: opacity of the ghosted (non-target) frames.

Output Schema

NameRequiredDescriptionDefault
opYes
rowsNo
textNoThe grid, for 'ascii' and 'diff'.
scaleNo
widthYes
framesNoFilmstrip: frame count.
heightYes
legendNoglyph → #rrggbb. Palette colours keep the same glyph across every read of the sprite.
originNoascii: sprite position of the grid's top-left cell — the `x`/`y` for `draw` kind 'grid'.
spriteYes
columnsNo
gridRowsNoascii: the bare rows, '.' transparent — `draw` kind 'grid' `rows`, with `legend` and `origin`.
framesUsedNoOnion: 1-based frame numbers composited.
offPaletteNoascii/diff: glyphs whose colour is not in the palette. Their assignment can change between reads — do not reuse them across regions.
totalPixelsNo
changedBoundsNoDiff: tight bounding box of every changed pixel. Null when nothing changed.
changedPixelsNo
percentChangedNoDiff: changed / total * 100.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.8.2

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already establish readOnly/no-open-world, but the description layers on substantial behavior: glyphs are bound to palette indices so regions agree, each legend lists only contained colours, off-palette colours get per-read glyphs, rulers=false output is reusable by draw kind 'grid', and onion ghosts are occluded by opaque backgrounds. This is detail an agent could not infer from annotations or 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?

Front-loaded with the intent sentence, then a scannable bullet per op with bolded op names. It is long, but nearly every clause carries operational information; a few ascii details (legend merging, glyph binding) run longer than strictly necessary.

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?

For a 13-param, six-mode read tool with an output schema already present, the description covers mode selection, crop/scale behavior, cross-tool round-tripping (ascii -> draw grid), and the animation-review caveat. Nothing an agent needs to invoke it correctly is missing, and return formats are appropriately left to the output schema.

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%, so the baseline is 3, but the description adds real meaning beyond it: what ascii/rulers output composes with, that scale defaults to a vision-readable ~1024px long edge, the crop semantics of region, and how layer/reference interact. It stops short of documenting fromFrame/toFrame and ghost opacity fully, leaving some to the schema.

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?

Opens with a specific verb+resource ('See what is actually on the canvas') and then enumerates six named ops, each described by what it renders, clearly separating this inspection tool from mutating siblings like draw and transform. An agent can tell exactly what it gets back per op without opening the schema.

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?

Every op carries an explicit 'Use for…' clause ('total read: silhouette, colour', 'verify precise pixel positions', 'the only reliable way to review an animation', 'check in-betweens while animating', 'confirm exactly what an edit touched'). It also gives conditional caveats (opaque background hides ghosts, use vision-less clients with ascii) and a workflow rule: draw, then look, then fix.

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