Skip to main content
Glama

select_by_color

Select every pixel matching a color on a chosen layer to scope edits to that material; raise tolerance to include anti-aliased or nearby colors.

Instructions

Select every pixel of one layer matching a colour, the magic-wand selection.

The usual way to scope an edit to one material: select the armour's base colour and
every later operation touches only the armour. Pair it with `shift_along_ramp` to
shade one material without disturbing its neighbours.

Args:
    color: The colour to match.
    tolerance: 0 matches exactly. Higher values also catch nearby colours, which is
        useful on artwork that was anti-aliased or converted from a photo.
    frame: Which frame to sample, 1-based.
    layer: Which layer to match on. Defaults to the top layer, which is the layer the
        drawing and shading tools also default to, so a selection made here scopes
        the call that follows it.

**One layer, not the composite**, and that is deliberate for the same reason
`get_pixels` takes a layer: the tools this selection is for write to one layer, so a
pixel selected on a different one is selected and unreachable. Select on the layer you
are about to edit.

This used to run Aseprite's `MaskByColor` without saying which layer it meant, and the
layer it got was whichever one Aseprite made active on opening the file, which is the
*bottom* one. Measured on an 8x8 sprite with red on the bottom layer and an opaque
blue square over half of it on the layer above: matching red selected all 64 pixels,
including the 32 nothing can see, and matching blue (32 pixels, plainly visible, and
on the layer every drawing tool writes to) selected nothing at all.

Refuses when no pixel matches, rather than reporting a success with no selection. The
old behaviour cleared the sidecar on the way through, so a mistyped colour silently
unscoped every edit that followed it, which is the opposite of what asking for a
selection means. A refusal leaves the previous selection as it was.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
colorYes
frameNoDefault: 1.
layerNo
filenameYes
toleranceNoDefault: 0.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.10.0

TDQS

A4.4/5.0
Behavior5/5

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

Annotations only declare readOnlyHint=false and openWorldHint=false; the description goes well beyond that, disclosing that the tool refuses rather than reporting a false success, that a refusal preserves the previous selection, and the exact layer-defaulting behavior (top layer, matching drawing tools) with an explicit account of the legacy MaskByColor bug. For a state-mutating selection tool this is unusually complete.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded and clearly sectioned (summary, Args, rationale), so structure is good, but the two final paragraphs are lengthy historical narration about the old MaskByColor behavior. That detail explains a real behavioral change, yet it is duplicated across the 'One layer, not the composite' paragraph and the bug story, costing more words than the agent needs to invoke the tool.

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?

With no output schema, no annotations covering mutation semantics, and 5 parameters, the description carries most of the burden and does so competently: it covers selection scope, refusal semantics, layer defaults, and side effects on prior selections. It does not say what is returned on success (e.g. whether selection bounds or a count comes back), which is the main remaining gap.

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 40% (frame and tolerance carry just a default; color/filename have none). The description compensates by explaining color, the tolerance scale including the anti-aliasing/photo rationale for higher values, the 1-based frame, and the layer default plus why it matters. Only `filename` is left unmentioned, which is self-evident, so the gap is nearly closed.

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 opening sentence names a specific verb+resource+scope: 'Select every pixel of one layer matching a colour, the magic-wand selection.' This is immediately distinguishable from siblings like select_region, modify_selection, and invert_selection, and even names the conceptual analogue (magic wand).

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 states a concrete use case (scoping an edit to one material) and names a companion tool (`shift_along_ramp`) for the follow-up operation, plus an operational rule ('Select on the layer you are about to edit'). It gives no explicit comparison to select_region or get_selection, so it stops short of full when-not-to-use routing, but the guidance is clear and actionable.

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