A
licenseNot graded
qualityD
maintenanceProvides comprehensive color conversion, manipulation, analysis, and WCAG accessibility tools supporting multiple formats (hex, rgb, hsl, oklch, oklab) for design systems and web development.
14 npm
2
MIT
Behr Colormapper MCP
by coryking
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@Behr Colormapper MCPmatch #FF6B6B to the closest Behr paint"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Behr Colormapper MCP
A public, stateless MCP server that converts digital sRGB colors into the nearest Behr paint colors and searches Behr colors by code or name. Matching uses CIEDE2000 perceptual distance in CIE Lab space.
MCP endpoint
https://behr-colormapper.coryking.workers.dev/mcp
The endpoint uses Streamable HTTP with JSON responses and requires no authentication. The Worker root is reserved for a human-facing project page.
Related MCP server: color-engine
Tools
behr_match_paintaccepts#RGB,#RRGGBB,rgb(r,g,b), barer,g,b, andhsl(h,s%,l%). It returns canonical RGB, hex, and Lab input values plus nearest Behr colors ranked by CIEDE2000 delta E.behr_search_colorssearches exact or partial Behr codes and names, ranking exact codes first.
Both tools exclude archived colors unless include_archived is true. Their Zod contracts provide MCP input/output JSON Schemas. They are marked read-only, non-destructive, idempotent, and closed-world.
Published screen colors approximate physical paint. Confirm consequential choices with a physical sample under the intended lighting.
Catalog source
data/behr.json is the normalized runtime catalog. Its metadata records the source URL, retrieval date, and catalog counts. src/colormapper/refresh.py is the authoritative definition of the Behr source and normalization rules.
Refresh and validate the checked-in snapshot:
uv sync --group refresh
uv run --group refresh behr-colormapper-refresh
uv run pytest
cd worker && npm testThe runtime never contacts Behr.
Deployment
Pushes to main that affect the Worker, catalog, smoke test, or workflow run tests and deploy through GitHub Actions. The repository requires:
Actions secret
CLOUDFLARE_API_TOKENwith Workers Scripts → Edit permissionActions variable
CLOUDFLARE_ACCOUNT_ID
Run locally with cd worker && npm install && npm run dev.
License
Code is MIT licensed. Behr color names, codes, and catalog data belong to their respective owner and are included as factual compatibility data.
Available Tools
2 toolsbehr_match_paintMatch a color to Behr paintBRead-onlyIdempotent
Convert a digital sRGB color to the nearest Behr paint colors using CIEDE2000 perceptual distance.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| color | Yes | #RGB, #RRGGBB, rgb(r,g,b), r,g,b, or hsl(h,s%,l%) | |
| limit | No | ||
| include_archived | No |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| input | Yes | |
| matches | Yes |
TDQS
B3/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 behavior, so the safety profile is covered. The description adds useful algorithmic context (CIEDE2000 perceptual distance) and the input color model, but it does not disclose result-count behavior, archived-color handling, or any limitations beyond what the annotations and output schema provide.
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 a single, front-loaded sentence that states the transformation and the matching method. Every element earns its place and there is no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be described, but for a three-parameter tool with low schema coverage the description is incomplete. It fails to explain two parameters and gives no usage routing against the sibling tool, leaving meaningful gaps for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33%: the color parameter is documented in the schema, but limit and include_archived have no schema descriptions. The tool description does not compensate; it never explains the result limit, default count, or the effect of include_archived, leaving two of three parameters semantically undocumented.
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 states a specific verb and resource: converting an sRGB color to the nearest Behr paint colors. It clearly implies a nearest-match operation, which is distinct from searching colors, though it does not name the sibling behr_search_colors to make the distinction explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives no guidance on when to use this tool versus behr_search_colors, nor any prerequisites or exclusions. The agent must infer that this is for color-to-paint matching rather than text search from the name and description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
behr_search_colorsSearch Behr colorsBRead-onlyIdempotent
Find Behr colors by exact or partial paint code or color name. Exact codes rank first.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | ||
| include_archived | No |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| colors | Yes |
TDQS
B3.1/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description adds one genuinely useful behavior beyond the annotations — 'Exact codes rank first' — but says nothing about the default result count or how archived colors affect results.
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?
Two short sentences, front-loaded with the core action, no filler. Every clause carries information — the match modes and the ranking rule.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return-value exposition is unnecessary, and annotations carry the safety profile. What is missing for correct invocation is sibling disambiguation and any guidance on the two undocumented optional parameters, leaving the definition merely adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% across 3 parameters. The description clarifies what 'query' accepts (exact or partial code, or color name), which is genuinely additive, but 'limit' (default 20, max 100) and 'include_archived' (default false) are left completely undocumented in both the schema and the description.
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 ('Find Behr colors') plus the accepted match modes ('exact or partial paint code or color name'). It does not, however, differentiate itself from the sibling behr_match_paint, so an agent cannot tell from the description alone which of the two to pick.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit when-to-use, when-not-to-use, or named alternative, even though behr_match_paint sits right beside it. The match-mode sentence implies a lookup use case but leaves the search-vs-match decision entirely to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
2 tool updates
v0.1.0- First observed
behr_match_paint - First observed
behr_search_colors
TDQS
A3.5/5.0
Scored across 2 tools
Disambiguation5/5
The two tools have clearly distinct purposes: one converts an sRGB color to nearest Behr matches, the other searches by code/name. No overlap or ambiguity in selection.
Naming Consistency5/5
Both tools follow a consistent 'behr_' prefix and verb_noun pattern (match_paint, search_colors). Predictable and readable.
Tool Count4/5
Two tools are sufficient for the core mapping and lookup tasks, but the set feels slightly thin for a color service; a third tool (e.g., color detail) would add value without bloat.
Completeness4/5
The surface covers matching digital colors to Behr and searching by code/name, which are the primary workflows. Minor gaps include no explicit reverse mapping (Behr to sRGB) or dedicated color detail retrieval, though search likely returns enough.
Maintenance
ActivitySlowing
ResponsivenessUnresponsive
Related MCP Connectors
Convert colours between hex, RGB, HSL, OKLCH and CMYK, and compute harmonies.
Every UK paint colour, matched across brands by ΔE and priced; palettes, planner projects, trends.
Color API MCP — wraps thecolorapi.com (free, no auth)
Color Pizza MCP — names hex colors using human-friendly color-name lists.
Related MCP Servers
- AlicenseAqualityCmaintenanceProvides CSS color utilities including parsing, conversion, gamut mapping, WCAG contrast, tint/shade ramp generation, and contrast-target solving.635 npmMIT
- AlicenseAqualityDmaintenanceA simple color utility MCP server for frontend developers. Convert, mix, adjust, and analyze colors right from your AI agents.1120 npmMIT
- AlicenseNot gradedqualityBmaintenanceWraps thecolorapi.com to provide color data and information through MCP, with no authentication required.129 npmMIT