aseprite_layerManage Aseprite layers by creating, selecting, deleting, renaming, or toggling visibility. Returns the current sprite status after each action.
Create (new, becomes active), activate (select), delete, rename, or show/hide (visible) a layer. Returns the sprite status.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Layer name (for new: name of the new layer) | |
| action | Yes | ||
| newName | No | rename only | |
| visible | No | visible only |
Changes observed during successful MCP inspections.
v0.2.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It does disclose a behavioral detail: creating a layer makes it active. It also states the return value (sprite status). However, it omits potential side effects like delete being irreversible or behavior when renaming a nonexistent layer, which would be valuable given the destructive actions available.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tightly packed sentence that lists all actions and the return value. It is front-loaded with the core capability and wastes no words. Every part contributes to understanding the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main actions and return value, but lacks context about prerequisites (e.g., needing an open sprite) and does not explain conditional parameter usage (newName only for rename, visible only for visible) beyond what the schema hints. Since there is no output schema, a clearer description of 'sprite status' would help. Overall, adequate but with notable gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 75%, but the description adds meaning beyond the schema by explaining each action: 'new, becomes active', 'activate (select)', 'show/hide (visible)'. This clarifies the enum values that lack descriptions in the schema. It also notes the return value, which is not in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool manages layers via specific actions: create, select, delete, rename, show/hide. It names the resource (layer) and the verbs. It does not explicitly differentiate from sibling tools like aseprite_frame, but the focus on layers is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites (e.g., an open sprite) or conditions that would favor another tool. The description simply lists capabilities without contextual direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.