Skip to main content
Glama
MalloyTheDev

Aseprite MCP

by MalloyTheDev
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

import_image

Destructive

Create an editable .aseprite sprite from a flat raster image such as PNG, JPG, or BMP, with optional overwrite control for existing output files.

Instructions

Create an editable .aseprite sprite from a flat image (.png/.bmp/.jpg/...).

Args:
    input_image: Source raster image.
    output: Destination .aseprite path.
    overwrite: Replace `output` if it already exists (default False = no-clobber).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
outputYes
overwriteNoDefault: false.
input_imageYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv0.10.0
    • removedInput schema / properties / input_image / title
      Removed value: -"Input Image"
    • removedInput schema / properties / output / title
      Removed value: -"Output"
    • addedInput schema / properties / overwrite
      Added value: +{
+  "default": false,
+  "description": "Default: false.",
+  "type": "boolean"
+}
    • removedInput schema / title
      Removed value: -"import_imageArguments"
  2. First observedv0.7.0

TDQS

A3.9/5.0
Behavior4/5

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

Annotations flag destructiveHint=true and readOnlyHint=false, and the description usefully qualifies that this destruction only occurs when overwrite is true, since the default is no-clobber. That is real added value beyond the flat annotation, though it never says what happens on a no-clobber collision (error vs. skip) 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.

Conciseness5/5

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

One front-loaded purpose sentence plus a tight three-line args block; nothing is padded and the most important constraint (output must be .aseprite) appears first.

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 low-complexity 3-parameter file-conversion tool with no output schema, the description covers the purpose, both required inputs, formats, and overwrite semantics. The only gap is undefined error behavior when output already exists and overwrite is false, plus no hint about what the call returns.

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 description coverage is only 33% (just 'Default: false.' on overwrite), so the description must compensate, and it does: it defines input_image as the source raster, output as the destination .aseprite path, and overwrite as the replace-existing flag with its default. The .aseprite constraint on output is information the schema does not carry.

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?

States a specific verb and resource ('Create an editable .aseprite sprite from a flat image') and enumerates accepted source formats, so the conversion direction is unambiguous and distinguishable from create_sprite or import_reference_sequence. It stops short of naming a sibling tool explicitly, which keeps it out of the top band.

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?

There is no explicit when-to-use or when-not-to-use statement, nor any named alternative among the many sprite/import siblings. Usage is only implied by the accepted file formats and the no-clobber note, which is the level the rubric defines as 'implied usage'.

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