Skip to main content
Glama
MalloyTheDev

Aseprite MCP

by MalloyTheDev
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

ramp_from_art

Recover the ordered color ramp from an existing sprite, grouped by luminance into steps, so you can shade or extend art that matches the original palette.

Instructions

Recover the ramp an existing sprite is painted with.

`extract_palette` reports the colours a sprite uses as a set. A set is not a ramp: the
shading tools need them ordered dark to light, and an agent asked to add to somebody
else's sprite has no way to get that order today.

The colours are grouped by luminance into `steps` bands, and each band is represented
by the colour most of its pixels use, so every entry is a colour that is actually in
the art and can be matched against it. `coverage` says what share of the drawn pixels
each step covers, which is how to tell a real ramp from one step plus four stragglers.

Says so when the colours are not a ramp: art spanning many hues is several materials
sharing a sprite, and comes back with a warning rather than with a plausible-looking
five colours. Scope the read with `layer` when that happens.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
frameNoDefault: 1.
layerNo
stepsNoDefault: 5.
filenameYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.10.0

TDQS

A4.1/5.0
Behavior2/5

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

The description is unusually rich about behaviour — luminance banding into `steps`, the modal-colour-per-band rule, the `coverage` share, and an explicit warning when the art is not a ramp. However, it frames the whole operation as a read ('Recover', 'scope the read'), while the annotation declares readOnlyHint=false, so the description's read/write framing conflicts with the supplied hint. That mismatch is the main transparency problem; mild credit is retained for the otherwise substantive disclosure.

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?

Three short paragraphs, front-loaded with the core action and then rationale. The digression about agents 'adding to somebody else's sprite' is slightly wordy but earns its place by motivating the tool. Nothing is buried.

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?

There is no output schema, so the description carries the return-value burden itself and does so: `steps` bands, per-step `coverage`, and a warning path instead of a plausible-looking five-colour answer. Only the unexplained `frame` parameter and absence of any error/permission detail keep it from a 5.

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 only 50%, so the prose has to compensate. It does meaningfully for `steps` (luminance bands, each represented by its dominant colour) and `layer` (scope the read when a warning fires). `filename` is self-evident; `frame` (default 1) is never explained, which is the only real 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?

States a specific verb and resource ('Recover the ramp an existing sprite is painted with') and immediately distinguishes itself from the sibling `extract_palette`, explaining that a colour set is not an ordered ramp. An agent can pick this tool over the palette tools without inspecting either schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit when-to-use (you need colours ordered dark-to-light for the shading tools, or you're adding to someone else's sprite) and names the alternative it supersedes (`extract_palette`, which only reports a set). It also says what to do in the failure case: when the warning about multi-hue art fires, re-run scoped with `layer`.

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