Skip to main content
Glama

replace_color

Destructive

Replace all pixels of a source color with a target color within a tolerance, on a chosen layer and frame of an Aseprite sprite.

Instructions

Replace every pixel matching from_color (within tolerance per channel) with to_color, on the chosen layer + frame.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
frameNoDefault: 1.
layerNo
filenameYes
to_colorYes
toleranceNoDefault: 0.
from_colorYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed12 schema fields changedv0.10.0
    • removedInput schema / properties / filename / title
      Removed value: -"Filename"
    • addedInput schema / properties / frame / description
      Added value: +"Default: 1."
    • removedInput schema / properties / frame / title
      Removed value: -"Frame"
    • removedInput schema / properties / from_color / title
      Removed value: -"From Color"
    • removedInput schema / properties / layer / anyOf
      Removed value: -[
      -  {
      -    "type": "string"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]
    • removedInput schema / properties / layer / default
      Removed value: -null
    • removedInput schema / properties / layer / title
      Removed value: -"Layer"
    • addedInput schema / properties / layer / type
      Added value: +"string"
    • removedInput schema / properties / to_color / title
      Removed value: -"To Color"
    • addedInput schema / properties / tolerance / description
      Added value: +"Default: 0."
    • removedInput schema / properties / tolerance / title
      Removed value: -"Tolerance"
    • removedInput schema / title
      Removed value: -"replace_colorArguments"
  2. First observedv0.7.0

TDQS

B3.3/5.0
Behavior3/5

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the write/mutation profile is covered. The description adds the useful scope detail that all matching pixels across the layer/frame are rewritten, but it does not state whether the change is reversible, whether it operates on a saved file or in-memory sprite, or what happens on no matches. Given annotation coverage, a 3 is appropriate.

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?

Single tight sentence with the operation front-loaded and the scope qualifier appended. No waste, though it sacrifices completeness for brevity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

A destructive mutation tool with no output schema, 33% schema coverage, and an undocumented required filename parameter. The description does not cover color format, filename semantics, or the irreversible nature of the pixel rewrite. It should do more given the tool's complexity and destructive annotation.

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 coverage is 33% – only frame and tolerance have descriptions (defaults). The description names from_color, to_color, tolerance, layer, and frame, giving semantic meaning to the color pair and tolerance that the schema lacks. However, it omits the required filename parameter entirely and gives no format for colors (hex? named? RGBA?), so it only partially compensates for the coverage 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 (Replace) and resource (every pixel matching from_color), plus the exact scope (chosen layer + frame). An agent can distinguish this from select_by_color, fill_area, or recoloring operations without inspecting schemas.

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

Usage Guidelines2/5

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

No when-to-use guidance, no mention of alternatives (e.g., select_by_color + fill_area, or how it differs from invert_colors). The description is purely mechanical and does not route the agent to or away from sibling tools.

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