Skip to main content
Glama

glow

Create a palette-safe halo around pixel art using layered ramp rings, with optional edge dithering, on a separate layer so the original artwork stays unchanged.

Instructions

Halo a shape in rings of ramp steps, so it glows without leaving the palette.

`add_outline` gives one flat ring, which reads as a sticker. A glow is several rings,
each a step further down a ramp: hottest against the artwork, fading outward, with the
outer ring optionally dithered so it ends in something softer than a hard edge.

The ramp is what makes this different from a glow in an image editor. A halo made of
alpha, or of colours interpolated between two others, takes the art off its palette,
and then `palette_conformance` drops and the sprite no longer exports to an indexed
format, reuses a tileset, or matches the sprite beside it. Every pixel this writes is
exactly one of the colours you passed in.

The glow goes on its own layer below the artwork, so the subject's cel is untouched
and deleting one layer removes the effect.

Args:
    ramp: Colours darkest first. Ring 1, touching the artwork, takes the top step and
        the outermost ring takes `ramp[0]`, so a longer ramp fades more finely. For a
        glow that reads as light rather than as a coloured border this usually wants
        its own bright ramp (a gem's or a flame's), not the subject's body ramp.
    radius: How many rings, in pixels. 2 or 3 reads as a glow; much more reads as fog.
    falloff: "linear" spaces the steps evenly. "quadratic" drops away faster, keeping
        a hotter core and a dimmer skirt, which is the one that reads as a light
        source rather than as an outline.
    dither_edge: Dither the outermost ring, so the glow ends in a half-density
        scatter instead of a hard line. This is binary coverage, a pixel either drawn
        or not, rather than a partial alpha, so every drawn pixel is still exactly a
        ramp step and conformance stays at 1.0.
    base_color: Glow only around pixels near this colour, which is how a gem glows
        while the hand holding it does not. Distance is measured out from those
        pixels, but the glow is never painted over any part of the subject layer, so
        a body blocks the halo of a gem inside it.
    tolerance: How close a pixel must be to `base_color` to be treated as a source,
        as a weighted RGB distance. Ignored when `base_color` is omitted.
    new_layer: Name for the glow's own layer, created directly below `layer`, or
        reused when a previous call of this tool made it and `frame` has no cel on it
        yet. That is how one glow layer carries a flickering torch across four frames
        rather than needing four layers with one cel each. A second call for the same
        layer *and* frame is refused, because two halos composited into one cel are a
        picture neither call describes, and so is a layer of that name this tool did
        not create.
    layer: The layer to glow around (default: top layer). Its cel is never modified.
    frame: Target frame, 1-based.

Refuses rather than drawing nothing: no pixel matching `base_color` is an error, and
so is a subject that leaves the glow nowhere to go.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
rampYes
frameNoDefault: 1.
layerNo
radiusNoDefault: 3.
falloffNoDefault: "linear".linear
filenameYes
new_layerNoDefault: "glow".glow
toleranceNoDefault: 24.0.
base_colorNo
dither_edgeNoDefault: true.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.10.0

TDQS

A4.9/5.0
Behavior5/5

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

Annotations declare only readOnlyHint=false and openWorldHint=false, so the description carries the rest and delivers: it writes to a new layer below the artwork, the subject cel is untouched, deleting one layer removes the effect, palette conformance stays at 1.0, layer reuse across frames is allowed but a duplicate layer+frame call is refused, and specific refusal conditions are enumerated. This is unusually rich behavioral disclosure for a mutation tool.

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 with a one-sentence summary followed by rationale and a dense but well-organized Args section; nearly every sentence carries non-redundant information. It is long for a tool description, but the length is largely earned by the ten parameters and the refusal semantics, with only mild room for trimming in the palette-conformance rationale paragraph.

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 10-parameter mutation tool with no output schema and only two annotation hints, the description covers layer side effects, error/refusal behavior, cross-frame reuse, and palette guarantees. Nothing an agent needs to invoke it correctly appears to be missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 60% and the schema only supplies defaults, yet the description adds genuine meaning for every parameter: ramp ordering and why a separate bright ramp is wanted, radius-as-ring-count, the two falloff modes, dither_edge's binary-coverage semantics, base_color's distance measurement and subject-layer blocking, tolerance's weighted RGB distance and its interaction with base_color, and new_layer's reuse rule. The enum-less falloff string is disambiguated purely by prose.

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 line states a specific verb+resource ('halo a shape in rings of ramp steps') and immediately distinguishes the tool from its closest sibling by contrasting with `add_outline`'s single flat ring. An agent can tell this apart from add_outline, add_drop_shadow, and cast_shadow without opening any 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?

Explicitly names the alternative (`add_outline`) and the condition that separates them, plus contrasts with image-editor glow techniques and explains when falloff='quadratic' vs 'linear' is appropriate and what radius values read as glow vs fog. The when-not case (image-editor alpha interpolation) is also stated.

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