Skip to main content
Glama
Sign In
Colors MCP Server

Colors MCP Server

by HtetOoWaiYan
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Color harmony

colors_harmony
Read-onlyIdempotent

Generate a color scheme from a base color by rotating OKLCH hue for complementary, split-complementary, triadic, tetradic, or analogous harmonies, returning hex colors with matched lightness and chroma.

Instructions

Generate a color scheme from a base color by rotating its OKLCH hue (complementary, split-complementary, triadic, tetradic, analogous) while keeping lightness and chroma matched. Returns hex colors with their hue offsets; the base is included at offset 0. OKLCH hue steps look even, unlike HSL angles.

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": {
      "color": "<color>",
      "scheme": "<scheme>"
    },
    "name": "colors_harmony"
  }
}

Input Schema

NameRequiredDescriptionDefault
colorYesThe base color. Any CSS color: "#3b82f6", "rgb(59 130 246)", "oklch(0.62 0.19 260)", "tomato".
schemeYesColor scheme: complementary (hue offsets 0, 180); split-complementary (hue offsets 0, 150, 210); triadic (hue offsets 0, 120, 240); tetradic (hue offsets 0, 90, 180, 270); analogous (hue offsets -30, 0, 30).

Output Schema

NameRequiredDescriptionDefault
colorsYes
schemeYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv2.1.0

TDQS

A3.5/5.0
Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely useful behavior — it returns hex colors paired with hue offsets, the base appears at offset 0, and lightness/chroma are preserved — but with a full output schema present, most of the return shape is already documented, keeping the added value moderate.

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?

Three sentences, front-loaded with the core verb and method, with no filler or repetition. The closing note about OKLCH steps looking even versus HSL is a rationale rather than an instruction, but it does justify why an agent should prefer this over manual angle math, so it roughly 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?

A low-complexity, two-parameter, idempotent read tool with a full output schema and complete annotations needs little more than a precise statement of what it computes and returns — which this provides. Only the absence of guidance versus sibling palette/harmony tools leaves a small gap.

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 description coverage is 100%; the color parameter spells out accepted CSS formats and the scheme enum lists the exact hue offsets per mode. The description only restates the scheme list and the lightness/chroma invariant, adding little beyond the schema — baseline 3 applies.

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?

States a specific verb and resource — 'Generate a color scheme from a base color' — and names the exact mechanism (OKLCH hue rotation) plus the five supported schemes. It doesn't explicitly contrast itself with siblings like colors_palette or colors_adjust, so it falls short of full sibling differentiation, but the mechanism is distinctive enough to place the tool.

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?

Usage is only implied: it's clear you call this when you want a harmony scheme derived from one base color with lightness and chroma held constant. There is no explicit when-not guidance and no named alternative (e.g., when to use colors_palette instead), which leaves the agent to infer boundaries from sibling names alone.

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