Skip to main content
Glama

validate_sprite_for_game_export

Validate a sprite against game export criteria including dimensions, color mode, frames, tags, transparency, palette, and expected exports. Returns a validation manifest with pass/fail and detailed checks.

Instructions

Check whether a sprite is game-ready against the criteria you specify.

Runs a series of checks — does the file open, do dimensions match (exactly or as
a tile multiple), is the colour mode allowed, are frame counts / required animation
tags present, is the background transparent, is the palette within budget, do
expected export files exist, and is sprite-sheet metadata readable — plus soft
warnings for oversized canvases, missing tags, and default/blank layer names.

All criteria are optional; only the ones you pass are enforced. Returns a
``workflow_manifest.v1`` manifest (kind "validation") with a `validation` section
`{passed, checks[], errors[], warnings[]}`. `validation.passed` is the verdict;
`ok` just means the check ran.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
filenameYes
max_framesNo
min_framesNo
required_tagsNo
tile_multipleNo
expected_widthNo
expected_heightNo
expected_exportsNo
max_palette_sizeNo
spritesheet_dataNo
allowed_color_modesNo
require_transparent_backgroundNo
Behavior4/5

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

With no annotations, the description carries the full burden of behavioral disclosure. It details the checks performed, notes that all criteria are optional, and describes the return manifest structure (validation.passed, checks, errors, warnings). It also mentions soft warnings for oversized canvases, etc., providing good transparency.

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 description is front-loaded with the core purpose, followed by a comprehensive list of checks, and ends with return format details. It is informative but not overly verbose for a tool with 12 parameters and no schema descriptions.

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 (12 parameters, no output schema, no annotations), the description provides a clear overview of behavior, the checks performed, and the verdict structure. It could be improved by explaining each parameter's role, but overall it is sufficiently complete for an agent to understand and invoke the tool correctly.

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

Parameters3/5

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

Schema description coverage is 0%, so the description must compensate. It lists the types of checks (dimensions, frames, tags, etc.) which correspond to parameters, but does not explicitly map parameter names to their meanings. For example, 'expected_width' is not mentioned; instead it says 'do dimensions match'. This provides context but not direct parameter semantics.

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 clearly states the tool's purpose: 'Check whether a sprite is game-ready against the criteria you specify.' It enumerates specific checks (file opens, dimensions, color mode, etc.), distinguishing it from sibling tools like validate_asset_spec by focusing on sprite game readiness.

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?

The description implies usage for pre-export validation by listing checks, but it does not explicitly state when to use this tool over alternatives (e.g., validate_asset_spec) or when not to use it. No guidance on prerequisites or context.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/MalloyTheDev/aseprite-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server