Contrast checks with fixes, OKLCH harmonies, palettes, color-blind previews and code export.
Scored across 6 tools
Each tool has a clearly distinct purpose: color-space conversion, contrast checking, code export, harmony generation, constrained palette rolling, and vision-deficiency simulation. The two palette-generation tools are differentiated by deterministic base-color harmony versus random/locked palette generation.
All six tools follow a consistent snake_case verb_noun pattern: check_contrast, convert_color, export_palette, generate_harmony, roll_palette, simulate_color_vision. The naming is predictable and immediately readable.
Six tools is well-scoped for a focused color utility server. Each tool covers a distinct capability without obvious redundancy or bloat.
The surface covers core color workflows: conversion, contrast checking, palette generation, harmony generation, export, and vision simulation. Minor gaps such as palette save/load or image-based color extraction exist, but agents can work around them for typical color tasks.
Check text/background contrast with WCAG 2 ratio, APCA Lc and a suggested fix that keeps the hue.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | Text color hex. | |
| background | Yes | Background color hex. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, closed-world, so safety is covered. The description adds that a suggested fix is returned and that hue is preserved, which is useful non-obvious behavior. However it doesn't say what the fix looks like (adjusted lightness? nearest passing pair?) or what happens on honestly-unfixable pairs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single efficient sentence that front-loads the operation and packs the metrics and fix into the same clause. It could be slightly longer to explain the fix behavior, but no sentence is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Two required params, no output schema, and the description names the outputs (ratio, Lc, suggested fix), which is the essential piece an agent needs since there's no output schema. Missing only granular detail on the fix and threshold semantics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and both params document hex format with validation patterns, so the schema carries the load. The description adds nothing about accepted input forms beyond what's already in the schema. Baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource (check text/background contrast) and enumerates the exact metrics returned (WCAG 2 ratio, APCA Lc) plus the remediation offered (suggested fix preserving hue). This distinguishes it clearly from siblings like convert_color or generate_harmony, which don't evaluate contrast.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage — verifying color pairs against accessibility standards — but never states when to prefer it over siblings or any prerequisites. No exclusions or alternative routing are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Convert a hex color to RGB, HSL and OKLCH.
| Name | Required | Description | Default |
|---|---|---|---|
| hex | Yes | Color hex. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and openWorldHint=false, so the safety profile is covered. The description adds the useful disclosure that the response contains three representations (RGB, HSL, OKLCH), but it doesn't describe the shape of that return value, and there's no output schema to fill the gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, zero filler, with the input and all output formats front-loaded. Nothing is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, idempotent, read-only, single-parameter tool with full schema coverage, the description gives enough to invoke it correctly and even hints at the return content. The only minor gap is that with no output schema, the structure of the RGB/HSL/OKLCH result (objects vs strings) is unspecified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single parameter's regex enforces supported hex formats (3- or 6-digit, optional #), which the description doesn't need to repeat. The description adds no extra meaning about accepted forms or normalization, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (convert) and resource (hex color) plus the exact target formats (RGB, HSL, OKLCH), so the operation is unambiguous. It doesn't explicitly differentiate itself from siblings like generate_harmony or simulate_color_vision, but the purpose is narrow enough that overlap is unlikely.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: an agent can infer that this tool is for formatting conversions of a single color. There is no explicit when-to-use guidance, no exclusions, and no mention of alternatives for palette-wide operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Turn a list of colors into code for CSS, Tailwind, SwiftUI, Android, Flutter and other formats ColorPickr supports.
| Name | Required | Description | Default |
|---|---|---|---|
| colors | Yes | ||
| format | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish that the operation is read-only, idempotent, and closed-world, so the safety profile is covered. The description adds that the output is code in supported formats, but it does not explain return shape, limits, or error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
It is a single front-loaded sentence with no wasted text. The core action and output are stated immediately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter export tool with no output schema, the description is adequate but incomplete. It says the result is code, yet it does not clarify whether the output is returned as text, a file, or another structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description should compensate, and it does identify the core semantics: colors are a list and format selects the code target. However, it does not clarify constraints such as hex color format or max 32 colors, and its format examples cover only part of the enum.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description gives a clear verb and resource: it turns a list of colors into code for multiple target formats. It is distinguishable from color-conversion siblings, but it does not explicitly contrast itself with alternatives such as convert_color.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It implies the tool is for exporting palette code, but it gives no explicit when-to-use guidance, no exclusions, and no comparison with sibling tools. An agent must infer the usage context from the purpose sentence alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Build a color harmony from a base color in OKLCH, mapped into the sRGB gamut.
| Name | Required | Description | Default |
|---|---|---|---|
| base | Yes | Base color hex. | |
| type | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and openWorldHint=false, so safety is covered. The description adds useful context that computation happens in OKLCH and results are gamut-mapped into sRGB, but says nothing about the return shape (e.g., array of colors) or how many colors each harmony type yields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with no filler. Appropriately sized for a two-parameter tool, though the brevity contributes to the semantic gaps noted elsewhere.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-param tool with annotations covering the safety profile, the essentials are nearly there, but with no output schema the description should state what is returned (one color per type? list of hex values?) and it does not.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 50%: 'base' is documented as 'Base color hex' while 'type' has an enum but no description. The description does not compensate by explaining the harmony types or the relationship between base color and each mode.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Build) and resource (color harmony) with the OKLCH input space and sRGB gamut-mapping detail. It implicitly distinguishes itself from siblings like convert_color and roll_palette, though it never names them explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: an agent can infer you call this when you have a base color and want a harmony, but there is no explicit when-to-use, when-not, or comparison to alternatives such as roll_palette or convert_color.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a 5-color palette that always contains a light/dark pair passing WCAG AA; optionally keep locked colors.
| Name | Required | Description | Default |
|---|---|---|---|
| seed | No | Seed for repeatable results. | |
| locked | No | Colors to keep, in order. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint=false, so safety is covered. The description does add one meaningful guarantee (a WCAG AA light/dark pair is always present), but it omits other behavioral facts an agent would want: what color notation is returned, whether locked colors are preserved verbatim and in position, and what happens when locked input is invalid.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence with no filler; the core output guarantee is front-loaded and the optional locking behavior comes second.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-optional-parameter, read-only generator with no output schema, this covers output size and the key quality guarantee. The remaining gap is the return format (color notation, ordering of locked vs. generated colors), which the agent cannot infer from any structured field.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so both parameters (seed, locked) are already documented, which sets the baseline at 3. The description reinforces that locking is optional and preserves order, but adds nothing about the seed parameter or the seed/locked interaction.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description gives a specific verb (Generate) and resource (5-color palette) plus the defining constraint that it always contains a light/dark pair passing WCAG AA, which separates it from a generic harmony generator. It stops short of naming which sibling to prefer (e.g. generate_harmony), so an agent still has to infer the boundary.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: the accessibility guarantee and the 'optionally keep locked colors' clause hint at when this is the right choice. There is no explicit when-to-use/when-not statement and no reference to generate_harmony or check_contrast as alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show how colors look with protanopia, deuteranopia, tritanopia or achromatopsia (Machado 2009).
| Name | Required | Description | Default |
|---|---|---|---|
| type | Yes | ||
| colors | Yes | ||
| severity | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and openWorldHint=false, so the safety profile is fully covered and the description only needs to add context. It contributes the algorithmic basis (Machado 2009), which aids trust in the numbers, but says nothing about output shape, the 32-color cap, or what severity does to results.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single well-formed sentence with the action verb front-loaded and zero filler; the citation is compact. It is efficient, though the brevity comes partly at the cost of information an agent needs.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 3-parameter tool with no output schema and no parameter descriptions, the description is thin: it never states what is returned (simulated hex values? a swatch set?) or how `severity` and the color-count limit affect the call. Structural constraints live in the schema, but the semantic gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, and it largely doesn't. It restates the four `type` values already enumerated in the schema, and leaves both `colors` (hex format, max 32) and especially `severity` (0–1, default 1, meaning simulation intensity) completely unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb ('show how colors look') plus the resource (colors under simulated vision deficiencies), and it enumerates the four supported deficiency types. It doesn't explicitly contrast with siblings, but the function is distinct enough from check_contrast / convert_color / generate_harmony that an agent can tell it apart.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the narrow purpose — you call it when you want to preview colors under a color-vision deficiency — but there is no explicit when-to-use/when-not framing and no mention of alternatives such as check_contrast for accessibility auditing. The reader must infer the boundary themselves.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
check_contrastconvert_colorexport_palettegenerate_harmonyroll_palettesimulate_color_vision18 color tools: OKLCH, WCAG and APCA contrast fixes, palettes, gradients, color blindness, tokens.
Convert colours between hex, RGB, HSL, OKLCH and CMYK, and compute harmonies.
WCAG color contrast checks, nearest accessible color, CSS color conversion and palette pair checks.
Solve, audit and simulate colorblind-safe chart palettes. WCAG contrast, OKLab ΔE. Read-only.
Add one secure layer between your agents and this server.