Aseprite MCP

Overview Schema Source Related Servers Discussions Admin

draw_image_base64

Composite a base64-encoded PNG or image onto a sprite layer at given coordinates, letting you paste externally generated artwork directly into Aseprite files.

Instructions

Composite an inline base64-encoded PNG (or other image) onto a layer at (x, y).

Useful for pasting externally generated artwork. `image_base64` may include a
`data:image/png;base64,` prefix. The decoded image is capped at 32 MB; for
anything larger, write the file into the workspace and use `stamp_file`.

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": {
      "filename": "<filename>",
      "image_base64": "<image_base64>",
      "x": "<x>",
      "y": "<y>"
    },
    "name": "draw_image_base64"
  }
}

Input Schema

Name	Required	Description	Default
`x`	Yes
`y`	Yes
`frame`	No	Default: 1.
`layer`	No
`opacity`	No	Default: 255.
`filename`	Yes
`blend_mode`	No	Default: "normal".	normal
`image_base64`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed15 schema fields changedv0.10.0Oct 4, 2026
- addedInput schema / properties / blend_mode / description
```
Added value: +"Default: \"normal\"."
```
- removedInput schema / properties / blend_mode / title
```
Removed value: -"Blend Mode"
```
- removedInput schema / properties / filename / title
```
Removed value: -"Filename"
```
- addedInput schema / properties / frame / description
```
Added value: +"Default: 1."
```
- removedInput schema / properties / frame / title
```
Removed value: -"Frame"
```
- removedInput schema / properties / image_base64 / title
```
Removed value: -"Image Base64"
```
- removedInput schema / properties / layer / anyOf
```
Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
```
- removedInput schema / properties / layer / default
```
Removed value: -null
```
- removedInput schema / properties / layer / title
```
Removed value: -"Layer"
```
- addedInput schema / properties / layer / type
```
Added value: +"string"
```
- addedInput schema / properties / opacity / description
```
Added value: +"Default: 255."
```
- removedInput schema / properties / opacity / title
```
Removed value: -"Opacity"
```
- removedInput schema / properties / x / title
```
Removed value: -"X"
```
- removedInput schema / properties / y / title
```
Removed value: -"Y"
```
- removedInput schema / title
```
Removed value: -"draw_image_base64Arguments"
```
First observedv0.7.0Jul 29, 2026

TDQS

A4.2/5.0

Behavior4/5

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

Annotations only state readOnlyHint=false and openWorldHint=false, which already imply a local mutating operation. The description adds real context beyond that: the 32 MB decoded-size cap, tolerance for a data: URI prefix, and the fallback path for oversized images. It does not describe how existing layer content is affected by compositing.

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?

Three short sentences, front-loaded with the core action, then the use case, then the base64/size caveats and fallback. No filler; every sentence carries operational information.

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?

No output schema exists, so return values needn't be explained. The call-critical details (base64 prefix, size cap, preference for stamp_file on large inputs) are present, though unaddressed parameters like blend_mode and opacity leave some gaps for a compositing tool.

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 38% for 8 parameters. The description clarifies image_base64 format (optional data: URI prefix) and implies x/y placement, which does add meaning. However, layer, opacity, blend_mode, and frame are 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.

Purpose5/5

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

States a specific verb (composite) plus resource (inline base64-encoded image) and the destination (a layer at (x, y)). It is immediately distinguishable from the sibling stamp_file, which is file-based, and from draw_pixels/draw_pixel_map which draw pixel data rather than images.

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?

Gives a use case ('pasting externally generated artwork') and explicitly names the alternative stamp_file with the condition that selects it (>32 MB). No explicit when-not beyond the size threshold, but the routing guidance is concrete and actionable.

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

Deploy Server