Skip to main content
Glama
MalloyTheDev

Aseprite MCP

by MalloyTheDev
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

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

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
xYes
yYes
frameNoDefault: 1.
layerNo
opacityNoDefault: 255.
filenameYes
blend_modeNoDefault: "normal".normal
image_base64Yes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed15 schema fields changedv0.10.0
    • 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"
  2. First observedv0.7.0

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

Other Tools