aseprite-ai-artist

Overview Schema Source Related Servers Discussions Admin

Validate

validate

Read-only

Check a sprite for pixel-art violations—off-palette colors, stray pixels, broken outlines, banding, and animation issues—with evidence instead of guesswork.

Instructions

Lint a sprite against pixel-art rules and report concrete, located problems. Checks: off-palette colours, orphan/stray pixels, broken or doubled outlines, banding, unintentional anti-aliasing on a hard-edged sprite, odd-pixel asymmetry, empty layers, untagged frames, inconsistent frame timing, and cross-frame volume drift in an animation. Run this before telling the user a sprite is finished. It answers 'is this actually done' with evidence rather than optimism.

Input Schema

TableJSON Schema

Name	Required	Description
`checks`	No	Omit to run everything.
`sprite`	No	Which sprite: its id as '#7' (what every result reports back, and the only unambiguous form — two unsaved documents are both called 'Sprite'), its filename, or its display name. Omit to use the sprite Aseprite has focused.
`strict`	No	Treat style warnings as failures. Use when the user asked for a specific discipline.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`score`	Yes
`passed`	Yes
`sprite`	Yes
`summary`	Yes
`findings`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv0.1.6Sep 9, 2026

changedInput schema / properties / sprite / description

Previous value: -"Sprite filename or id. Omit to use the sprite Aseprite has focused."New value: +"Which sprite: its id as '#7' (what every result reports back, and the only unambiguous form — two unsaved documents are both called 'Sprite'), its filename, or its display name. Omit to use the sprite Aseprite has focused."

First observedv0.1.0Sep 8, 2026

TDQS

A4.1/5.0

Behavior4/5

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

The annotations already declare readOnlyHint=true, so the description's safety profile is established. The description adds behavioral detail beyond that by listing the specific categories of problems it detects (off-palette colours, orphan pixels, banding, etc.) and clarifying that it returns 'concrete, located problems.' This goes beyond the structured annotation and helps the agent understand the tool's scope.

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 a single paragraph with a clear lead sentence, followed by a list of checks and a closing directive. It is efficient and front-loaded with the primary purpose. It could be slightly more concise by trimming the long enumeration, but it remains well-structured and easy to scan.

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 (a linting tool with multiple checks) and the presence of an output schema (which presumably describes the report format), the description covers what the tool does and when to use it. It does not need to explain return values because the output schema handles that. It is sufficiently complete for an agent to call it 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 100% — each of the three parameters (checks, sprite, strict) already has a description in the input schema. The tool description itself adds no extra parameter-level detail, so it relies on the schema. This meets the baseline for full coverage, but there is no additional value added.

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 states a specific verb ('lint') and resource ('a sprite'), enumerates concrete checks, and clarifies its role as a final readiness gate ('answers is this actually done'). It is clearly distinct from sibling tools like sprite_info (which likely just reports metadata) or preflight (which might be a broader check), even without naming them.

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 provides an explicit when-to-use directive: 'Run this before telling the user a sprite is finished.' This gives clear context for the tool's appropriate invocation. However, it does not mention alternatives or exclusions (e.g., when NOT to use it), which would make the guidance fully explicit.

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

Deploy Server