Skip to main content
Glama

import_sprite_sheet

Open an image and slice it into animation frames by frame width and height; optionally save the result.

Instructions

Opens an image and slices it into frames (File > Import Sprite Sheet). Optionally saves the result.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
xNo
yNo
fileYes
typeNo
saveAsNoSave the imported sprite here (needed in batch mode)
backendNoauto (default): live Aseprite if connected, else headless batch
paddingNo
frameWidthYes
frameHeightYes
partialTilesNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.1

TDQS

B3.1/5.0
Behavior3/5

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

Annotations declare readOnlyHint=false and destructiveHint=false, so the mutation/safety profile is partly covered. The description adds that saving the result is optional, which is useful beyond the annotations, but it says nothing about the live vs batch backend behavior, failure modes, or what the slicing produces.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

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

Two short, front-loaded sentences with no filler; the operation is stated first and the save caveat second. It is efficient, though perhaps terse given the tool's complexity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With 10 parameters at 20% schema coverage, no output schema, and a write-capable operation, the description is too thin. An agent lacks guidance on the frame-grid parameters, the meaning of type, and how the optional save interacts with batch mode.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is only 20% across 10 parameters; saveAs and backend are the only documented ones, and the description touches saveAs only obliquely ('Optionally saves the result'). Critical params like frameWidth, frameHeight, type, x/y, padding, and partialTiles are unexplained in both schema and description, so the description does not compensate for the coverage gap.

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 concrete verb+resource: opens an image and slices it into frames, with the parenthetical menu path (File > Import Sprite Sheet) anchoring it. This distinguishes it from siblings like open_sprite and export_sprite_sheet, though it doesn't name those alternatives directly.

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?

Usage is implied by the UI menu reference and the note that saving is optional, but there is no explicit when-to-use guidance, no statement of when to prefer this over open_sprite or export_sprite_sheet, and no prerequisites.

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