Aseprite AI Artist

Overview Schema Source Related Servers Discussions Admin

Palette

palette

Read, set, load, generate, analyze, or extract Aseprite sprite color schemes so you can choose colors before drawing and avoid repainting completed art.

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 by key: ~2000 of them, the classics (pico8, gameboy, cga, nes…) and the most-downloaded on Lospec (sweetie-16, endesga-32, resurrect-64, aap-64…). An unknown key or a name answers with the matching keys, so 'preset: "gameboy"' or 'preset: "endesga"' is a search. • '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. • 'extract' — replace the palette with one quantized from the art itself (RGB sprites only). Use to derive a curated palette from a reference image imported at full colour. Decide the palette before drawing. Retro-fitting one onto finished art means repainting.

Input 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.
`maxColors`	No	For op 'extract': target palette size.
`startIndex`	No	For op 'set': where `colors` starts. Ignored when `replace` is true.

Output Schema

Name	Required	Description
`op`	Yes
`path`	No	Palette file read by op 'load'.
`ramp`	No
`size`	No
`total`	No	Op 'preset' with no such key: presets bundled.
`usage`	No
`colors`	No
`sprite`	No
`matches`	No	Op 'preset' with no such key: presets whose key, name, author or tags match it.
`analysis`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.8.2Nov 7, 2026

TDQS

A4.4/5.0

Behavior4/5

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

With readOnlyHint=false the annotations already signal mutation; the description goes further by disclosing that 'extract' replaces the palette and is RGB-only, that 'ramp' appends rather than replaces, that presets search on unknown keys, and that remapping can repaint pixels. It does not state permission requirements or failure modes for load of bad files.

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-loaded summary sentence followed by a scannable bullet list keyed by op value, with zero filler. It is longer than most descriptions, but nearly every clause carries invocation-relevant information.

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 12-parameter mutation tool with an output schema (so return values need no explanation) and annotations covering the safety profile, the description covers every op, the destructive side effects, and the sequencing convention. Nothing needed to invoke it correctly is missing.

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 92%, so the baseline is 3, but the description adds real meaning the schema cannot: a preset key may be a fuzzy name, ramp shadows rotate toward blue and highlights toward orange, and analyze reports off-palette colours. This meaningfully extends the structured fields.

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?

Opens with a specific verb+resource ('Read and shape the sprite's palette') and then enumerates all seven ops with concrete semantics for each. An agent can tell this apart from siblings like recolor or transform without opening the schema.

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?

Gives per-op guidance ('Use to derive a curated palette from a reference image'), a workflow rule ('Decide the palette before drawing. Retro-fitting one onto finished art means repainting'), and operational advice ('a preset name is a search'). However it never explicitly contrasts this tool with the closest sibling, recolor, which also changes colour; that exclusion is left to inference.

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

Deploy Server