Skip to main content
Glama

ramp_between

Build a color ramp between two chosen endpoint colors, interpolating middle steps and preserving both endpoints exactly.

Instructions

Build a ramp from its two ends, which is how a ramp is usually decided.

`generate_ramp` grows a ramp outward from one base colour, so reaching a particular
shadow and a particular highlight means guessing at `hue_shift` until the ends land
near what was wanted. This takes the ends directly: pick the cool shadow and the warm
highlight, and the middle is interpolated between them.

Both ends come back **exactly** as given. They were chosen, and a ramp whose endpoints
are approximations of the caller's own colours is not the ramp that was asked for.

Args:
    easing: "perceptual" (the default) walks the straight line between the ends in
        Oklab, so the middle steps are evenly spaced to the eye and the ramp keeps its
        hue. "linear" is the naive sRGB blend, which darkens and greys the middle.
    filename, apply: As `generate_ramp`. "append" or "replace" writes the ramp into
        that sprite's palette.

Neither mode rotates hue. Interpolating hue between distant colours is what turns a
blue-to-cream ramp magenta in the middle: at that distance both ways round the wheel
are equally short, and neither is the blend anybody wanted.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
applyNoDefault: "none".none
stepsNoDefault: 5.
easingNoDefault: "perceptual".perceptual
filenameNo
light_colorYes
shadow_colorYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.10.0

TDQS

A4.5/5.0
Behavior4/5

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

Annotations only declare readOnlyHint=false and openWorldHint=false, so the description carries the real burden. It adds meaningful disclosure: endpoints are returned exactly as given, easing choices change the middle's brightness/greyness, neither mode rotates hue, and append/replace writes into the sprite palette. It slightly defers by saying filename/apply behave 'As generate_ramp', and it doesn't clarify what apply='none' (the default) does with the built ramp.

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 purpose and the sibling comparison before the Args block, which is the right order. It is slightly verbose — the endpoint-preservation paragraph and the hue-rotation aside both lean on emphasis but each still carries a distinct behavioral point.

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?

For a mutating tool with no output schema and only safety annotations, the description covers purpose, differentiation, key behavior, and most arguments. Remaining gaps are small: the unaddressed 'steps' semantics and the fact that the return value is only implied ('both ends come back').

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 50%, so the description must compensate; it explains easing thoroughly (Oklab 'perceptual' vs naive sRGB 'linear') and partially covers apply ('append'/'replace' writes to palette). However, shadow_color/light_color are only described conceptually and the 'steps' parameter is never addressed anywhere.

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 ('Build a ramp from its two ends') and immediately frames the decision model. It draws an explicit contrast with the sibling generate_ramp, so an agent can distinguish the two without opening 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?

Names the alternative (generate_ramp) and the condition that selects this tool: when you want to pin both a specific shadow and highlight rather than guessing hue_shift. This is explicit when-to-use guidance against a real sibling.

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