Skip to main content
Glama
Sign In
aseprite-mcp

aseprite-mcp

by MJSchut
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Local

draw

Render shapes, character-grid rows, and pixel data onto a specified Aseprite layer or frame, with optional preview, to compose pixel art and sprite details.

Instructions

Draw on a layer, in order: shapes, rows, pixels. shapes: [kind,x1,y1,x2,y2,color,fill?] kind line|rect|ellipse (fill = interior color); ["curve",[[x,y],...],color,w0?,w1?] smooth spline through points, tapering width (1 = crisp pixel-perfect line); ["blob",[[x,y],...],fill,outline?] smooth closed silhouette through points (heads, bodies, snouts); a point [x,y,1] is a sharp corner (brims, hems, ears); ["tube",[[x,y],...],[dark..light],w0,w1?,{light?,contrast?,bias?}] shaded tapered cylinder (limbs, hair locks, horns, necks, tails; w1=0 for a point); ["form",[[x,y(,1)],...],[dark..light],{light?,shrink?=0.18,shift?=0.5}] blob silhouette shaded with clean crescents (heads, snouts, bodies, rocks); ["eye",cx,cy,w,h,{fill,lid,lower?,pupil?,glint?},{nose:"right"|"left",arch?=0.4,flat?=0.7,tilt?,lidWidth?,pupil:{w,h,dx,dy},light?}] an eye with anatomy: flat lower lid, angular inner corner toward the nose, upper lid arching to a round outer corner, pupil under the lid (mirror nose for the pair); w,h <= 3 draws a tiny eye (dark block, glint on the light side, same for both eyes). Use eye for every eye so glints agree; ["lobe",cx,cy,rx,ry,[dark..light colors],{light?,shift?=0.45,shrink?=0.2,bumps?=7,bumpiness?=0.12,seed?}] shaded form: each lighter tone a smaller copy shifted toward the light, scalloped clump edges (tree = ~3 lobes, back first; bushes, clouds, round bodies); or ["gradient",x1,y1,x2,y2,[colors...],"v"|"h"|"r"] (Bayer-dithered). rows: char grid, legend maps char->color, '.'/space skipped; x,y offset rows. pixels: [[x,y,color]...].

Input Schema

NameRequiredDescriptionDefault
xNo
yNo
pathYes
rowsNo
frameNodefault 1
layerNodefault top layer
legendNo
pixelsNo
shapesNo
previewNoreturn preview image

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv2.3.0

TDQS

B3/5.0
Behavior2/5

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

No annotations are provided, so the description must carry the full behavioral burden. It says 'Draw on a layer' but does not state whether existing layer content is preserved or overwritten, what permissions/path prerequisites apply, whether the operation is reversible, or what is returned.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose is front-loaded, and most of the dense syntax detail is necessary for the complex shapes DSL. However, the description is a single wall of text with poor structure, making the extensive shape mini-language harder to scan than it needs to be.

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 complex, unannotated mutation tool with no output schema and low schema coverage, the description explains the drawing DSL well but omits core context: required path meaning, coordinate origin, color format, layer/frame behavior, and return/side effects. It is helpful but not complete enough for confident 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 only 30%, so the description must compensate and it does so extensively for shapes, rows, pixels, legend, and offsets. It leaves path, frame, preview, and the exact coordinate/color conventions unaddressed, but the complex DSL parameters are well explained.

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 states a specific verb and resource: 'Draw on a layer', and names the three input modes (shapes, rows, pixels). It is clear what the tool does, but it does not differentiate itself from siblings such as edit or create_sprite.

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

Usage Guidelines2/5

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

It explains the order of shapes/rows/pixels and gives subtype-specific advice like 'Use eye for every eye so glints agree', but it gives no guidance on when to choose draw over edit, create_sprite, generate, or other sibling tools. There are no exclusions or explicit selection criteria.

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