aseprite-ai-artist

Overview Schema Source Related Servers Discussions Admin

Frames

frame

Destructive

Manage animation frames in Aseprite: list, add, duplicate, delete, set durations, activate, or reorder. Control per-frame timing to shape animation cycles.

Instructions

Manage animation frames. Ops: 'list', 'add', 'duplicate', 'delete', 'set_duration', 'activate', 'reorder'. Durations are milliseconds per frame and carry most of the life in a cycle — hold a contact pose longer than a pass pose. Use count to add several at once and durations to set a whole cycle's timing in one call.

Input Schema

TableJSON Schema

Name	Required	Description
`op`	Yes
`count`	No
`frame`	No	1-based frame number. Omit to use the active frame.
`sprite`	No	Which sprite: its id as '#7' (what every result reports back, and the only unambiguous form — two unsaved documents are both called 'Sprite'), its filename, or its display name. Omit to use the sprite Aseprite has focused.
`toIndex`	No	For 'reorder'.
`linkCels`	No	For 'duplicate': share the cel image instead of copying it, so edits apply to both.
`durations`	No	Per-frame durations from frame 1, for 'set_duration'.
`afterFrame`	No	Insert position. Default: at the end.
`durationMs`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
`frames`	No
`sprite`	Yes
`frameCount`	Yes
`activeFrame`	No
`totalDurationMs`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv0.1.6Sep 9, 2026

changedInput schema / properties / sprite / description

Previous value: -"Sprite filename or id. Omit to use the sprite Aseprite has focused."New value: +"Which sprite: its id as '#7' (what every result reports back, and the only unambiguous form — two unsaved documents are both called 'Sprite'), its filename, or its display name. Omit to use the sprite Aseprite has focused."

First observedv0.1.0Sep 8, 2026

TDQS

A3.9/5.0

Behavior3/5

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the mutating nature is known. The description adds domain context about durations carrying the life of a cycle, which is helpful but does not disclose operational details like irreversibility of delete or that operations affect the active sprite. Since annotations cover the core safety profile, the description's modest additional disclosure merits a 3.

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?

The description is tightly written, with the ops list front-loaded and each sentence earning its place. The usage guidance for durations and batch operations is concise and directly actionable, with no filler.

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?

Given the tool's complexity (9 parameters, 7 ops), an output schema exists to define returns, and annotations cover safety. The description covers the operation scope and provides key usage tips. It does not explain every edge case (e.g., behavior when frame is omitted, or activate semantics), but the schema already documents frame omission, and the ops list is self-explanatory. This is adequate for an experienced user.

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 coverage is 67%, with descriptions for frame, sprite, toIndex, linkCels, durations, and afterFrame. The description adds value beyond the schema by explaining the semantics of durations (milliseconds per frame) and the purpose of count and durations in batch operations. This compensates for the undocumented parameters (op, count, durationMs) with practical usage context.

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?

The description clearly states 'Manage animation frames' and enumerates seven operations (list, add, duplicate, delete, set_duration, activate, reorder), making the resource and verb specific. It does not explicitly distinguish this tool from siblings like layer or tag, but the ops list leaves little ambiguity about scope.

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?

The description provides practical guidance on when to use certain parameters ('Use count to add several at once and durations to set a whole cycle's timing in one call') and explains the role of durations in animation cycles. It lacks explicit alternative routing to sibling tools, but the context is clear and not misleading.

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

Deploy Server