Aseprite MCP

by MalloyTheDev

Overview Schema Source Related Servers Discussions Admin

Python

Local

draw_text

Render text onto an Aseprite layer at (x, y) in one color, supporting custom fonts, scaling, and multi-line input.

Instructions

Draw text onto a layer at (x, y) in a single colour.

Args:
    text: The string (supports "\n" for multiple lines).
    x, y: Top-left position of the text.
    color: Text colour.
    scale: Integer pixel-scaling of the rendered glyphs (default 1).
    font_path: Optional path to a .ttf/.otf font. If omitted, a built-in
        bitmap font is used (best for tiny pixel text).
    font_size: Point size when a TrueType font_path is given.
    spacing: Extra pixels between lines.
    threshold: 0-255 cutoff; pixels brighter than this are drawn (lower =
        heavier text). Keeps glyphs crisp (no anti-aliasing artefacts).

scale is capped at 64, font_size at 512, and the rendered text at 200,000
pixels; the pixel budget is enforced while rasterizing, not afterwards.

Returns the standard draw result plus the rendered text's pixel size.

Input Schema

TableJSON Schema

Name	Required	Description
`x`	Yes
`y`	Yes
`text`	Yes
`color`	Yes
`frame`	No	Default: 1.
`layer`	No
`scale`	No	Default: 1.
`spacing`	No	Default: 1.
`filename`	Yes
`font_path`	No
`font_size`	No	Default: 16.
`threshold`	No	Default: 128.

Schema Changelog

Changes observed during successful MCP inspections.

Changed24 schema fields changedv0.10.0Oct 4, 2026
- removedInput schema / properties / color / title
```
Removed value: -"Color"
```
- removedInput schema / properties / filename / title
```
Removed value: -"Filename"
```
- removedInput schema / properties / font_path / anyOf
```
Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
```
- removedInput schema / properties / font_path / default
```
Removed value: -null
```
- removedInput schema / properties / font_path / title
```
Removed value: -"Font Path"
```
- addedInput schema / properties / font_path / type
```
Added value: +"string"
```
- addedInput schema / properties / font_size / description
```
Added value: +"Default: 16."
```
- removedInput schema / properties / font_size / title
```
Removed value: -"Font Size"
```
- addedInput schema / properties / frame / description
```
Added value: +"Default: 1."
```
- removedInput schema / properties / frame / title
```
Removed value: -"Frame"
```
- 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 / scale / description
```
Added value: +"Default: 1."
```
- removedInput schema / properties / scale / title
```
Removed value: -"Scale"
```
- addedInput schema / properties / spacing / description
```
Added value: +"Default: 1."
```
- removedInput schema / properties / spacing / title
```
Removed value: -"Spacing"
```
- removedInput schema / properties / text / title
```
Removed value: -"Text"
```
- addedInput schema / properties / threshold / description
```
Added value: +"Default: 128."
```
- removedInput schema / properties / threshold / title
```
Removed value: -"Threshold"
```
- removedInput schema / properties / x / title
```
Removed value: -"X"
```
- removedInput schema / properties / y / title
```
Removed value: -"Y"
```
- removedInput schema / title
```
Removed value: -"draw_textArguments"
```
First observedv0.7.0Jul 29, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Annotations declare readOnlyHint=false and openWorldHint=false, so the mutating, local nature is already known. The description adds value beyond that: the scale=64, font_size=512, and 200,000-pixel caps, the fact that the pixel budget is enforced during rasterization (not afterwards, implying no silent retro-crop), and the threshold's crisp anti-aliasing behavior.

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-loads the one-line purpose, then an Args block, then caps explanation, then return note. Every sentence carries information, though the return sentence is somewhat redundant given output schema absence is answered anywhere.

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?

For a 12-param draw tool with no output schema and partial schema coverage, the description covers the majority of parameters plus hard limits and return shape. Missing only minor details like frame/layer targeting and spacing units beyond lines, but the important behavioral limits are present.

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?

With 42% schema description coverage and 12 parameters, the schema leaves many parameters with only default values. The description explains text (supports \n), x/y as top-left, color, scale limits, font_path fallback behavior, font_size context, spacing meaning, and threshold 0-255 semantics, substantially compensating for the schema 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 (draw) and resource (text) with precise location semantics (top-left x,y). Distinct from sibling raster tools like draw_line or fill_area, and from stamp_file/draw_image_base64, which place images not glyphs.

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

Usage Guidelines3/5

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

Implies usage (drawing glyph strings onto a layer) and offers a hint via font_path semantics – omit it for built-in bitmap text, provide a .ttf/.otf for TrueType. However, there is no explicit when-to-use vs when-not-to-use guidance relative to sibling text-ish or image-drawing tools.

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

Deploy Server

draw_text

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools