Skip to main content
Glama

export_slice_metadata

Destructive

Exports Aseprite slices to engine-agnostic JSON, including bounds, pivot, nine-slice, color, and parsed user data, so game engines can consume sprite metadata.

Instructions

Export every slice as engine-agnostic JSON (aseprite_mcp.slice_metadata.v1).

Each slice becomes ``{name, type, id, bounds, pivot, nine_slice, color, data,
raw_data}``. **Type detection:** a slice's user-data JSON ``type`` wins; otherwise the
name convention ``<type>:<id>`` (recognized types: hitbox, hurtbox, collision, interact,
pivot, origin, attach, spawn, nine_slice; anything else becomes ``"custom"``, never an
error). ``id`` comes from the data ``id`` or the name's ``:<id>`` suffix. ``nine_slice``
(Aseprite's 9-patch center) and ``pivot`` are emitted whenever the slice has them. Slice
user-data that is valid JSON is parsed into ``data``; the raw string is kept in ``raw_data``.

Args:
    output: Destination .json path. Defaults to ``<sprite>_slices.json`` beside the sprite.
    overwrite: Replace an existing file (default False = no-clobber).

Returns a ``workflow_manifest.v1`` manifest (kind ``engine_metadata``).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
outputNo
filenameYes
overwriteNoDefault: false.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed8 schema fields changedv0.10.0
    • removedInput schema / properties / filename / title
      Removed value: -"Filename"
    • removedInput schema / properties / output / anyOf
      Removed value: -[
      -  {
      -    "type": "string"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]
    • removedInput schema / properties / output / default
      Removed value: -null
    • removedInput schema / properties / output / title
      Removed value: -"Output"
    • addedInput schema / properties / output / type
      Added value: +"string"
    • addedInput schema / properties / overwrite / description
      Added value: +"Default: false."
    • removedInput schema / properties / overwrite / title
      Removed value: -"Overwrite"
    • removedInput schema / title
      Removed value: -"export_slice_metadataArguments"
  2. First observedv0.7.0

TDQS

A4.1/5.0
Behavior4/5

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

Annotations mark it destructive/not-read-only, and the description earns its keep by disclosing the no-clobber default, the overwrite flag semantics, and the default output path — concrete write-behavior context beyond the annotations. It stops short of stating permissions or failure modes, so not a 5.

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?

Front-loads purpose and output format, then type-detection rules, args, and return. It is dense but every section (type precedence, id derivation, raw_data retention) carries information an agent would otherwise have to guess.

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?

No output schema exists, yet the description describes the returned workflow_manifest.v1 manifest (kind engine_metadata) and the emitted slice object shape, so the agent knows both what is written and what comes back. Minor gaps around permissions/failures remain.

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 only 33%, but the description documents both output (destination .json path with default) and overwrite (replace existing, default False), adding real meaning. The required filename param is left unexplained, keeping it from a 5.

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?

States a specific verb+resource ('Export every slice as engine-agnostic JSON') and names the exact format schema (aseprite_mcp.slice_metadata.v1), which cleanly separates it from siblings like list_slices or export_spritesheet.

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 described output format (engine-agnostic JSON for downstream consumption) but there is no explicit 'use this when / not when' or named alternative. The agent must infer when this beats list_slices or export_game_asset_bundle.

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