Skip to main content
Glama
Sign In
aseprite-mcp

aseprite-mcp

by shin2344234
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Local

resize_sprite

Scale an entire sprite across all layers and frames by setting width, height, or scale factor. Use it to change pixel art dimensions while preserving animation and layer structure.

Instructions

Scales the whole sprite (all layers and frames). Give width and/or height, or scale.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "resize_sprite"
  }
}

Input Schema

NameRequiredDescriptionDefault
saveNoBatch mode: write changes back to the sprite file (default true)
scaleNo
widthNo
heightNo
methodNo
spriteNoFile path, open tab title, or sprite id. Defaults to the active sprite (live). Batch mode needs a file path.
backendNoauto (default): live Aseprite if connected, else headless batch

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.1

TDQS

B3.3/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=false and destructiveHint=false, so the safety profile is partially covered. The description usefully adds that the operation hits every layer and frame, but it omits that pixel data is permanently resampled (nearest/bilinear/rotsprite), the live-vs-batch write behavior, and whether the original dimensions can be recovered.

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?

Two tight sentences, zero filler, with the scope statement front-loaded before the parameter hint. Every clause earns its place.

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 7-parameter mutation tool with no output schema, the description covers the core intent but leaves method selection, save/backend interaction, and return behavior to inference. It is minimally adequate rather than complete.

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 43%, so the description must compensate; it does partially by clarifying that width/height and scale are alternative ways to specify the same resize ("Give width and/or height, or scale"). However it leaves the precedence when both are supplied, and the meaning of the method enum values (especially rotsprite), unexplained.

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?

"Scales the whole sprite (all layers and frames)" gives a specific verb plus the resource and its scope, which clearly separates it from related siblings like canvas_size or crop_sprite. It stops short of naming an alternative explicitly, so it earns a 4 rather than a 5.

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?

The only guidance is "Give width and/or height, or scale," which is parameter usage rather than when-to-use. Nothing tells the agent when to choose resize_sprite over canvas_size or crop_sprite, nor when to prefer one method or backend over another.

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