Skip to main content
Glama

Project Gumball

by com.gumballtools

Convert a colour and find its harmonies (Color Companion)

color_analyse
Read-only

Convert a colour between hex, RGB, HSL, OKLCH, CMYK, and CSS names, and derive complementary, analogous, triadic, split-complementary and monochromatic harmonies. Harmonies are rotated in OKLCH, not HSL, so they keep their perceived lightness instead of one looking washed out. Reports WCAG contrast against white and black, and flags colours clipped to fit sRGB.

WHY DELEGATE THIS: Colour-space arithmetic has no feedback signal — a wrong hex-to-OKLCH looks exactly like a right one until someone sees the colour. Harmonies rotated in HSL also come out perceptually unbalanced, which is the usual mistake.

Owned by Color Companion at https://color-companion-ebon.vercel.app, which is also callable directly if you would rather not go through the aggregator.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
colorYeshex, rgb(), hsl(), oklch(), a CSS colour name, or "transparent".

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. First observed

TDQS

A4.2/5.0
Behavior4/5

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

Annotations declare readOnlyHint=true and openWorldHint=true, and the description adds meaningful behavioral detail: harmonies are rotated in OKLCH to preserve perceived lightness, WCAG contrast against white/black is reported, and clipped sRGB colors are flagged. This goes well beyond what annotations alone convey, though it does not specify the exact response structure.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-organized and front-loaded: core function first, then algorithmic nuance, then delegation rationale, then ownership. Every sentence carries distinct information, and the length is justified by the tool's multifunctional nature.

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 read-only color utility with one parameter and no output schema, the description covers inputs, conversions, harmonies, contrast reporting, and clipping detection. It lacks a concrete response shape, but otherwise gives an agent everything needed to decide and invoke the tool correctly.

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?

The schema covers 100% of the single parameter, listing accepted formats identical to the description. The description adds no new semantic info about the 'color' parameter; it only restates what the schema already says. Interestingly, CMYK is mentioned as a conversion target but not as an accepted input, a minor potential source of confusion.

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 description opens with a precise verb-resource pairing: 'Convert a colour between...' and enumerates exact formats plus harmony types. The title and description together make the tool unmistakable, and the sibling tools are unrelated, so there is no ambiguity.

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

Usage Guidelines4/5

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

The 'WHY DELEGATE THIS' section explicitly explains the problem this tool solves (silent colour-space errors, unbalanced HSL harmonies), giving an agent a clear reason to select it. It also notes the provider can be called directly, but does not enumerate alternative sibling tools since none compete directly.

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

All Project Gumball toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.1/5.0
Disambiguation5/5

Each tool targets a clearly distinct domain or a complementary counterpart (cron_build/cron_explain, vocab_draw/vocab_check, round_cash_total/rounding_impact), and the descriptions make those relationships explicit. There is no real risk of selecting the wrong tool for a task.

Naming Consistency3/5

Most tools follow a noun_verb pattern (cron_build, regex_explain, timezone_convert), but there are exceptions like body_metrics, due_date, offside, json_to_types, and round_cash_total, which mix noun phrases, gerunds, prepositions, and verb-first order. The names are readable but not uniform.

Tool Count4/5

13 tools is within a reasonable range, and each utility earns its place as a standalone delegated calculator. The count feels slightly large only because the server is a grab-bag of unrelated domains rather than a focused toolkit, but no tool is redundant.

Completeness4/5

Most subdomains have solid coverage: cron has both build and explain directions, vocabulary has draw and check, and rounding has both per-transaction and aggregate analysis. Minor gaps exist, such as no timezone zone listing, no reverse due-date calculation, and no regex test/match step, but these are workable limitations.

Resources