Skip to main content
Glama

export_minecraft_texture

Destructive

Export an Aseprite sprite to a Minecraft resource pack at its correct texture path, writing a PNG or animated vertical strip with .mcmeta sidecar.

Instructions

Export a sprite into a resource pack at its correct texture path.

A single-frame sprite exports as a plain PNG. A multi-frame sprite exports as a
**vertical strip** (frame 1 on top, no padding) and gets a ``.png.mcmeta`` sidecar -
that pairing is what the game reads as an animation, and either half alone is broken.

Args:
    pack_root: The resource-pack directory (its ``assets/`` tree is written under this).
    namespace: Your mod/pack id. Defaults to "minecraft", which overrides vanilla.
    category: Texture subdirectory - block, item, entity, gui, particle, ...
    texture_name: In-pack texture name, ``/`` allowed for subdirectories. Defaults to
        the sprite's filename stem.
    frametime: Ticks per frame for the animation sidecar (1 tick = 50 ms).
    interpolate: Blend between animation frames.
    frame_order: Optional playback order (see ``write_texture_mcmeta``).
    overwrite: Replace existing files (default False = no-clobber).

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

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
categoryNoDefault: "block".block
filenameYes
frametimeNoDefault: 1.
namespaceNoDefault: "minecraft".minecraft
overwriteNoDefault: false.
pack_rootYes
frame_orderNo
interpolateNoDefault: false.
texture_nameNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.10.0

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already declare destructiveHint=true, and the description adds concrete value beyond them: the no-clobber default for overwrite, the requirement that the .png.mcmeta sidecar and the vertical-strip PNG must be written together, and the fact that assets/ is written under pack_root. It does not discuss permissions or rate limits, but for a local file-writing tool that is minor.

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?

The critical behavioral distinction (PNG vs vertical strip + mcmeta) is front-loaded before the Args block, and the Args block is compact. It runs slightly long, but nearly every line carries information an agent needs to call the tool correctly.

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

Completeness5/5

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

For a 9-parameter mutation tool with no output schema, the description covers behavior, parameter meaning, side effects, and the return value ('workflow_manifest.v1' manifest, kind 'minecraft_texture'). Nothing essential to a correct invocation is missing.

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

Parameters5/5

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

Schema coverage is only 56% (mostly bare defaults), yet the description documents essentially every parameter meaningfully: pack_root's assets/ tree, namespace's vanilla-override semantics, category values, texture_name's '/'-based subdirectories, frametime in ticks (1 tick = 50 ms), interpolate blending, and overwrite's no-clobber default. This is strong compensation for the schema gap.

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 a specific verb and resource ('Export a sprite into a resource pack at its correct texture path') and immediately distinguishes this tool from the many sibling export_* tools by specifying the Minecraft resource-pack target. The single-frame vs multi-frame behavior further pins down what it produces.

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?

It clearly states the condition that changes behavior (single-frame vs multi-frame) and routes frame_order to the sibling write_texture_mcmeta. It does not, however, explicitly say when to prefer this over export_png or validate_minecraft_texture, so routing is implied rather than fully spelled out.

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