Colors MCP Server

Blend or build a gradient

colors_blend

Read-onlyIdempotent

Mix colors or build a gradient between two or more colors and get evenly spaced hex values, interpolated in OKLCH for clean midpoints without gray mud.

Instructions

Mix colors or build a gradient between 2+ colors. Returns evenly spaced hex colors with both endpoints included, interpolated in OKLCH so midpoints stay clean (no gray mud). Set at for one mixed color (0.5 = even mix). Always in sRGB gamut.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "colors": "<colors>"
    },
    "name": "colors_blend"
  }
}

Input Schema

Name	Required	Description	Default
`at`	No	Return just ONE blended color at this position between the first two colors (0 = first, 0.5 = even mix, 1 = second). Overrides steps.
`space`	No	Interpolation space. "oklch" (default) keeps colors vivid and takes the shorter hue path; "oklab" is smooth but can dull; "srgb" matches old CSS gradients and goes muddy between far-apart hues; "srgb-linear" mixes in linear light (physical light mixing).	oklch
`steps`	No	How many colors to return, endpoints included. Default 5.
`colors`	Yes	The colors to blend between, in order. 2 to 8 stops. A list, even for a single color. Any CSS color strings.

Output Schema

Name	Required	Description	Default
`space`	Yes
`colors`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Addedv2.1.0Nov 11, 2026

TDQS

A3.5/5.0

Behavior3/5

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

Annotations already declare readOnly, idempotent, and non-destructive, so the safety profile is covered. The description adds real behavioral value by disclosing interpolation behavior (OKLCH default, no gray mud), endpoint inclusivity, and sRGB gamut guarantees. However, it blanket-states 'interpolated in OKLCH' while the `space` parameter allows other spaces, which is slightly imprecise rather than contradicted.

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?

Four short sentences, front-loaded with the core action and output shape, then the `at` shortcut and the gamut guarantee. Every sentence carries information, though the OKLCH sentence partially duplicates the `space` parameter documentation.

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 an output schema present and 100% parameter coverage, the description need not explain return values, yet it still summarizes the return format. Annotations cover the safety profile, leaving no significant gaps for a read-only, idempotent color-generation tool.

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 100%, so the schema already documents `colors`, `steps`, `space`, and `at` thoroughly. The description only reinforces `at` (0.5 = even mix) and repeats the OKLCH default, adding little beyond the structured fields; baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb and resource: mixing colors and building gradients between 2+ colors, and it states the output shape (evenly spaced hex colors, endpoints included). It is clearly distinguishable from inspection siblings like colors_info or colors_compare, though it never explicitly contrasts itself with generation siblings such as colors_palette or colors_harmony.

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

Usage Guidelines3/5

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

Guidance is limited to a parameter-level hint: set `at` to get a single mixed color, with 0.5 meaning an even mix. There is no statement about when to choose this over colors_palette or colors_harmony, no prerequisites, and no exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server