Skip to main content
Glama
sloplink

aseprite-mcp

by sloplink
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

Manage frames

aseprite_frame

Create, select, delete, or set duration for animation frames in Aseprite. New frames copy the active frame by default and become active, returning sprite status.

Instructions

Animation: create a frame after the given/active one (new, copies it by default, becomes active), activate (select), delete, or set its duration (in seconds). To draw several frames at once use aseprite_animation. Returns the sprite status.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
copyNonew: copy that frame instead of inserting an empty one
frameNoFrame number (default: active frame); new inserts after it
actionYes
durationNoSeconds, e.g. 0.1

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv0.6.0
    • changedInput schema / properties / copy / description
      Previous value: -"new: copy the active frame instead of an empty one"New value: +"new: copy that frame instead of inserting an empty one"
    • changedInput schema / properties / frame / description
      Previous value: -"Frame number (select/delete/duration)"New value: +"Frame number (default: active frame); new inserts after it"
    • removedInput schema / properties / frame / maximum
      Removed value: -9007199254740991
    • changedInput schema / properties / frame / type
      Previous value: -"integer"New value: +"number"
  2. First observedv0.2.0

TDQS

A4.6/5.0
Behavior4/5

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

With no annotations available, the description carries the behavioral disclosure burden i and does useful work by stating that 'new' copies the frame by default, becomes active, and that the tool 'Returns the sprite status.' It does not disclose delete/replace side effects or prerequisites like an open sprite, but the core behavioral traits are clearer than most unannotated tools.

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 sentences convey all operations, default behaviors, an alternative, and the return value with no filler. The list of actions is front-loaded and the sibling reference is compactly placed at the end.

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 four-action tool with four parameters and no output schema, the description is reasonably complete: it states what each action does, key defaults, the return status, and the relevant sibling. It could mention prerequisites or failure behavior for delete/duration, but it gives enough for an agent to make a correct call in the common cases.

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?

The schema already documents most parameters, and the description reinforces their meaning by tying 'frame' to the active frame/after insertion, 'copy' to the default behavior of 'new', and 'duration' to seconds. This adds contextual meaning beyond the raw schema, especially for action-dependent parameter use.

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?

The description names the resource (frames) and the exact operations: creating, selecting, deleting, and setting duration. It also distinguishes itself from aseprite_animation by explicitly pointing to that sibling for batch drawing. This gives an agent a clear, differentiation-ready understanding of the tool's purpose.

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

Usage Guidelines5/5

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

The description gives explicit operational context for when to use this tool and names a concrete alternative: 'To draw several frames at once use aseprite_animation.' This is a clear when-not condition that prevents the agent from confusing frame management with multi-frame drawing.

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