Skip to main content
Glama

shift_along_ramp

Move pixels along a colour ramp to darken or lighten pixel art while keeping every colour on the existing palette. Negative steps shade; positive steps lighten; region and tolerance limit edits.

Instructions

Move pixels along a colour ramp, keeping every one of them on the palette.

This is the operation to use for "put this in shadow", "make the night variant" or
"deepen the shadow side". Each pixel is matched to its nearest ramp entry, moved
`steps` along the ramp, and clamped at the ends, so the result uses only colours
that were already on the ramp.

Prefer this over `adjust_brightness_contrast` for anything that should still look
like pixel art: that tool does colour arithmetic and lands almost every pixel
between palette entries.

Args:
    ramp: The ramp, darkest first, as produced by `generate_ramp`. Order matters:
        negative `steps` moves toward the front of this list.
    steps: How far to move. Negative darkens (toward the front of `ramp`), positive
        lightens. Pixels already at an end stay there rather than wrapping.
    x, y, width, height: Restrict the change to a region. Defaults to the whole
        canvas. Scope this when a sprite has several materials: one ramp applied to
        everything flattens steel, brass and leather into the same colours.
    tolerance: How far a pixel may be from a ramp entry and still be treated as
        belonging to it, as a weighted RGB distance. Pixels further away than this
        are left alone and counted in `pixels_skipped`, so shading one material does
        not disturb its neighbours.
    layer: Target layer (default: top layer).
    frame: Target frame, 1-based.

Returns `pixels_written` and `pixels_skipped`. A high skip count usually means the
ramp does not match the artwork, not that the sprite was already correct.

`pixels_matched` counts the pixels that both matched the ramp and were written, so it
agrees with `pixels_written` rather than counting matches an active selection then
refused.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
xNoDefault: 0.
yNoDefault: 0.
rampYes
frameNoDefault: 1.
layerNo
stepsYes
widthNo
heightNo
filenameYes
toleranceNoDefault: 48.0.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.10.0

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only supply readOnlyHint=false and openWorldHint=false, so the description carries most of the load. It discloses real behavior beyond the safety profile: per-pixel nearest-entry matching, clamping at ramp ends rather than wrapping, the tolerance-based skip rule, that skipped pixels are left untouched and counted, and the default target (top layer, whole canvas). The note that a high skip count usually signals a ramp mismatch rather than correct artwork is genuinely useful diagnostic context.

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?

The purpose and the alternative-tool guidance are front-loaded before the Args block, which is the right order. The final paragraph on pixels_matched is convoluted — it introduces a third return field not listed in the preceding 'Returns' sentence and references 'an active selection', a concept not otherwise raised. Minor redundancy costs it a point, but the rest is dense and earns its place.

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, the description takes on return-value documentation (pixels_written, pixels_skipped, pixels_matched) and does so adequately, and it covers the region/tolerance semantics that the thin schema omits. For a 10-parameter mutation tool at 40% schema coverage this is close to sufficient; only the persistence target implied by filename and any undo/permission behavior go unmentioned.

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 only 40% (10 params, mostly undocumented in the schema), so the description must compensate and largely does: ramp ordering and its effect on negative steps, the sign convention for steps with clamp-at-end semantics, region scoping for x/y/width/height, tolerance as a weighted RGB distance with its skip consequence, layer default (top layer), and frame being 1-based. Only filename is left implicit, which is self-evident.

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 states a specific verb and resource ('Move pixels along a colour ramp, keeping every one of them on the palette') and immediately names the sibling it is not: 'Prefer this over `adjust_brightness_contrast`'. An agent can distinguish this from the many other colour/ramp tools (generate_ramp, ramp_between, ramp_from_art) 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?

It gives concrete use-case triggers ('put this in shadow', 'make the night variant', 'deepen the shadow side') and an explicit when-not with a named alternative ('anything that should still look like pixel art' → use this, not adjust_brightness_contrast, because that tool lands pixels between palette entries). It also advises scoping x/y/width/height when a sprite has multiple materials.

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