Loading ToolBench
Two MCP servers for color-vision accessibility: check whether a palette or image is colorblind-safe, and see it recolored as protan/deutan/tritan. Machado 2009 + CIEDE2000, published method. Local stdio.
This server demonstrates solid tool design with well-structured input schemas, clear descriptions, and purposeful composition. All 10 tools are explicitly registered with Zod-validated schemas and descriptions. However, there are notable gaps: output schemas are documented only in descriptions (not in JSON Schema), some parameter descriptions contain example values that LLMs may reuse literally, and error handling lacks recovery guidance. The tool naming is clear and action-oriented (simulateColor, compareVision, checkPalette, fixPalette, generateSafePalette), and the interface matches natural user intents (accessibility/colorblindness checking). The server splits concerns appropriately: colorblind-mcp handles simulation/visualization, cvdsafe-mcp handles validation/fixing. Most tools accept both file paths and base64 data URIs, reducing friction. Average tool description length is ~180 chars (within the 10-1024 baseline). Param descriptions average ~70 chars. All parameters have type constraints (strings, enums, numbers with min/max). The primary weaknesses are: (1) no explicit output schema documentation in code, (2) some descriptions embed examples ('e.g. #d7191c') that could cause hallucination, (3) no guidance when tools fail (e.g., if image parsing fails), and (4) limited error messages in the code samples shown.
Check whether a foreground color is legible on a background color per WCAG 2.x contrast ratios. Returns the ratio (1-21) and whether it passes AA and AAA. Set large=true for text >=18pt (or 14pt bold). This is the legibility axis, separate from color-blindness.
Check whether the colors in an image, chart, screenshot or mockup stay distinguishable for people with color-vision deficiency. Extracts the image's dominant colors, simulates protanopia, deuteranopia and tritanopia, and flags the color pairs that collapse into each other — each with how much of the image's area those colors cover, so a conflict between two large regions ranks above one between two specks. Reads PNG and JPEG. Pass `path` for a local file, or a base64 `dataUri`. Set returnSimulated=true to also get back the image as a deuteranope sees it. A screening aid, not a legal (ADA/WCAG) audit.
Check whether a set of colors stays distinguishable for people with color-vision deficiency (colorblindness). Simulates protanopia, deuteranopia and tritanopia and flags the pairs whose perceptual difference collapses under simulation. A screening aid, not a legal accessibility (ADA/WCAG) audit.
Return how a single hex color appears under protanopia, deuteranopia and tritanopia at once, for a side-by-side comparison.
Duplicate tool name across servers: 'simulateColor' appears in both colorblind-mcp and cvdsafe-mcp with nearly identical intent. When an LLM has both servers connected, it cannot disambiguate which to use without reading full descriptions. This violates the clear-distinction rule for tools operating on the same resource.
Example hex colors embedded in descriptions ('e.g. #d7191c', 'e.g. #1a9641', 'e.g. #767676') encourage LLMs to reuse those literal values. LLMs frequently treat examples as templates rather than adapting them. Should use formal constraints (regex pattern, description of format) instead.
Output schemas not formally documented in code. Tools return structured responses (text, image, JSON), but the schema is only described in natural language within handlers (e.g., 'Recolored as {{type}} sees it'). LLMs cannot see the exact output structure to plan downstream steps.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 61 | 2026-07-28+ | v2 |
Take a set of colors that fails the colorblind-safety check and return an adjusted set that passes, staying as close to the originals as possible. Conflicting colors are separated in lightness (the axis color-vision deficiency preserves). Returns the new colors, how far each moved, and whether it fully passes.
Return N colorblind-safe hex colors — distinct to each other under protanopia, deuteranopia and tritanopia. Seeded with the Okabe-Ito palette and safely extended above eight. Use when asked for accessible / colorblind-safe / colorblind-friendly colors for a chart, plot, map or UI. Never returns an unsafe color.
Generate a pseudoisochromatic (Ishihara-style) test plate: a digit hidden in a field of dots whose colors are distinct to normal vision but collapse under the chosen deficiency. Returns the plate image. Use when asked to create a colorblindness test plate or demonstrate what a plate looks like. Reproducible from a seed.
Return how a single hex color appears to someone with a given type of color blindness (protan, deutan, or tritan).
Return how a single hex color appears to someone with a given type of color-vision deficiency (protan, deutan, or tritan). Set severity 0..1 for a partial deficiency (anomalous trichromacy); 1 is the full dichromat case.
Recolor an image, chart, screenshot or mockup the way someone with color-vision deficiency sees it, and return the recolored image. Use this to SHOW what a design looks like through colorblindness (to check whether it stays readable, pair it with cvdsafe's checkImage). Reads PNG and JPEG — pass `path` for a local file, or a base64 `dataUri`. `type` picks the deficiency (default deutan); `severity` 0..1 sets strength.
No error recovery guidance in code. If simulateImage fails to parse the PNG/JPEG, or if checkImage encounters a corrupt file, the handlers do not return actionable error messages (e.g., 'File not found. Check the path and try again.'). Generic errors block LLM retry logic.
simulateColor (cvdsafe-mcp) description is significantly shorter (59 chars) and less detailed than simulateColor (colorblind-mcp) (168 chars). The cvdsafe version omits explanation of the 'severity' parameter, forcing users to consult the more complete tool's description. Inconsistent documentation creates discovery friction.
imageCheck.js and imageSim.js are imported but their code is not shown. If analyzeImage() and simulateImage() perform error handling, parsing, or validation, it is not visible in the evaluation. Assume defensive programming, but cannot score those implementations.