aseprite-ai-artist

Overview Schema Source Related Servers Discussions Admin

Palette

palette

Manage sprite palettes: get current colors, set custom entries, load presets or files, generate hue ramps, and analyze contrast, duplicates, and unused colors.

Instructions

Read and shape the sprite's palette. Ops: • 'get' — current palette with per-colour usage counts. • 'set' — write specific indices, or replace the palette wholesale. • 'preset' — load a bundled palette (pico8, gameboy, gameboy-pocket, cga, 1bit, grayscale-8). • 'load' — read a .gpl/.hex/.pal/.png palette file from disk. • 'ramp' — generate a hue-shifted ramp from a base colour and append it. Shadows rotate toward blue, highlights toward orange; a ramp that only changes brightness is the clearest tell of machine-made pixel art. • 'analyze' — report ramp structure, contrast, near-duplicate entries and colours used in the art that are not in the palette. Decide the palette before drawing. Retro-fitting one onto finished art means repainting.

Input Schema

TableJSON Schema

Name	Required	Description
`op`	Yes
`base`	No	Base colour for op 'ramp'.
`path`	No	Palette file for op 'load'.
`steps`	No	Ramp length.
`colors`	No	For op 'set': the colours to write.
`preset`	No	Preset key for op 'preset'.
`spread`	No	How far the ramp reaches into shadow and light.
`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.
`replace`	No	For op 'set'/'preset': replace the whole palette instead of merging.
`remapArt`	No	When replacing a palette, repaint existing pixels to the nearest new colour instead of leaving them off-palette.
`startIndex`	No	For op 'set': where `colors` starts. Ignored when `replace` is true.

Output Schema

TableJSON Schema

Name	Required	Description
`op`	Yes
`path`	No	Palette file read by op 'load'.
`ramp`	No
`size`	No
`usage`	No
`colors`	No
`sprite`	No
`analysis`	No
`availablePresets`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields 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."

addedOutput schema / properties / path

Added value: +{
+  "description": "Palette file read by op 'load'.",
+  "type": "string"
+}

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?

Annotations only set readOnlyHint=false, leaving the description to explain mutating behavior. The description does this well: it notes that 'set' can write indices or replace wholesale, 'load' reads files, 'ramp' appends a generated ramp, and 'remapArt' repaints pixels. It also provides nuance like shadow/highlight rotation, which goes beyond the schema. No contradiction with annotations.

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 well-structured with a bulleted list of ops, making it scannable. The opening sentence is efficient, and the final guidance is a pithy takeaway. It is longer than necessary due to a few editorial asides (e.g., 'machine-made pixel art'), but these add context without sacrificing readability.

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?

For a tool with 11 parameters and six operations, the description covers the operations clearly and the schema handles the parameter details. The existence of an output schema means return values are already specified. The main gap is that it does not mention error conditions or edge cases (e.g., what happens if a preset key is invalid), but overall it is complete enough 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 91%, so the schema already documents most parameters. The description adds marginal value by explaining the 'ramp' operation's intent (hue-shifted, with shadow/highlight behavior) and hints at 'remapArt' semantics, but it does not systematically elaborate on each parameter beyond the schema. Baseline 3 is appropriate.

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 opens with a clear verb-object statement ('Read and shape the sprite's palette') and enumerates six distinct operations, each with a concise definition. This makes the tool's purpose unambiguous and distinguishes it from siblings like 'recolor' and 'validate' that handle other aspects of color work.

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?

The description gives a strong timing directive: 'Decide the palette before drawing. Retro-fitting one onto finished art means repainting.' This tells the agent when to use the tool. However, it does not explicitly contrast with sibling tools (e.g., 'recolor' for post-hoc changes), so the guidance is clear but not exhaustive.

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

Deploy Server