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., "@contrast-checker-mcp Check if #777 on white passes WCAG AA"
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.
An MCP server that provides color contrast checking tools for AI assistants. Verify WCAG 2.1 accessibility compliance, compute contrast ratios with alpha transparency support, and get accessible color suggestions — all via the standard Model Context Protocol.
Contrast calculations match WebAIM's contrast checker — including alpha compositing, WCAG 0.03928 sRGB threshold, and truncated (not rounded) ratios.
check_contrastCheck the contrast ratio between two colors and evaluate WCAG 2.1 compliance.
Inputs:
foreground — Foreground color (e.g. #333, rgb(0,0,0), rgba(0,0,0,0.5), navy)
background — Background color (e.g. #fff, rgb(255,255,255), white)
Output: Contrast ratio, WCAG 2.1 pass/fail results (AA normal, AA large, AAA normal, AAA large), parsed color values. When the foreground has alpha, shows the effective composited color used for the calculation.
suggest_accessible_colorSuggest a replacement color that meets a WCAG contrast target, keeping the hue as close to the original as possible.
Inputs:
foreground — Foreground color
background — Background color
target_level — "AA" or "AAA" (default: "AA")
fix — "foreground" or "background" (default: "foreground")
Output: A suggested replacement color (in hex, rgb, hsl) that meets the target level, along with the new contrast ratio.
parse_colorParse a color string and return it in multiple formats.
Inputs:
color — Color to parse (e.g. #ff6600, rgb(255,102,0), tomato)
Output: The color in hex, rgb, and hsl formats.
Related MCP server: MCP Color Converter
Hex: #rgb, #rrggbb, #rgba, #rrggbbaa
RGB: rgb(r, g, b), rgba(r, g, b, a)
HSL: hsl(h, s%, l%), hsla(h, s%, l%, a)
CSS named colors: red, cornflowerblue, rebeccapurple, etc.
Add to ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) or %APPDATA%\Claude\claude_desktop_config.json (Windows):
{
"mcpServers": {
"contrast-checker": {
"command": "npx",
"args": ["-y", "contrast-checker-mcp"]
}
}
}claude mcp add contrast-checker npx -y contrast-checker-mcpAdd to .cursor/mcp.json or .vscode/mcp.json:
{
"servers": {
"contrast-checker": {
"command": "npx",
"args": ["-y", "contrast-checker-mcp"]
}
}
}git clone https://github.com/ogSINGH/contrast-checker-mcp.git
cd contrast-checker-mcp
npm install
npm run build
node dist/index.jsBlack on white — 21:1 ratio, all WCAG levels pass:
check_contrast({ foreground: "#000000", background: "#ffffff" })Semi-transparent text — alpha composited onto background before checking:
check_contrast({ foreground: "rgba(0,0,0,0.5)", background: "#ffffff" })
→ effective color #808080, ratio 3.94:1Fix a failing color pair:
suggest_accessible_color({
foreground: "#777777",
background: "#ffffff",
target_level: "AA"
})
→ suggests #757575 (4.61:1)Apache-2.0
Check the contrast ratio between two colors and evaluate WCAG 2.1 compliance. Accepts hex (#fff, #ffffff), rgb(r,g,b), hsl(h,s%,l%), and CSS named colors.
| Name | Required | Description | Default |
|---|---|---|---|
| background | Yes | Background color (e.g. '#fff', 'rgb(255,255,255)', 'white') | |
| foreground | Yes | Foreground color (e.g. '#333', 'rgb(0,0,0)', 'navy') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden and does disclose core behavior: computing a ratio, evaluating WCAG 2.1, and accepting various color formats. It does not reveal the output shape, WCAG levels/thresholds, or how invalid colors are handled.
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?
The description is two focused sentences with no filler. It front-loads the primary function and follows with the accepted input formats, making it easy to scan.
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 tool with full schema coverage, the description is largely complete. The main missing piece is an explicit statement about the return format, but the tool's purpose and invocation requirements are clear enough.
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?
The schema already provides 100% coverage with descriptions and examples for both parameters. The description adds value by explicitly listing all accepted formats (hex, rgb, hsl, named colors), which clarifies valid inputs beyond the schema examples.
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 names a specific operation ('Check the contrast ratio') and resource (two colors), and adds a concrete outcome: evaluating WCAG 2.1 compliance. It also enumerates accepted color formats, making its scope clear and distinguishing it from siblings like parse_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?
The use case is implied: use this tool when a contrast ratio or WCAG compliance check is needed. However, it never explicitly contrasts itself with suggest_accessible_color or parse_color, nor does it state when to prefer those alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Parse a color string and return it in hex, rgb, and hsl formats. Accepts hex (#fff, #ffffff), rgb(r,g,b), hsl(h,s%,l%), and CSS named colors.
| Name | Required | Description | Default |
|---|---|---|---|
| color | Yes | Color to parse (e.g. '#ff6600', 'rgb(255,102,0)', 'tomato') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and does disclose the core behavioral trait: it parses a color string and returns representations in hex, rgb, and hsl. It also lists exactly which input grammars are accepted. It stops short of describing invalid-input behavior or the exact output shape, but for a pure parsing function it is reasonably transparent.
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, tightly written sentence front-loads the action and output formats, then lists accepted inputs with concrete examples. No words are wasted and every clause carries useful information.
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 one-parameter pure function with no output schema and no annotations, the description covers accepted input grammar and return formats well enough for an agent to select and invoke it. It omits invalid-input behavior and the exact structure of the returned object, but these are minor gaps for such a small, focused utility.
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 schema already provides an example, so baseline is 3. The description adds value by explicitly enumerating accepted shorthand hex, functional rgb/hsl notation, and CSS named colors, going beyond the schema's single example string and giving the agent a fuller semantic model of the parameter.
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 states a specific verb ('Parse'), a clear resource ('a color string'), and the three output formats. It also enumerates accepted input forms, which makes the tool's purpose unmistakable and clearly distinct from the contrast and accessibility sibling tools.
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 this tool is for normalizing color strings into hex/rgb/hsl, and the sibling names suggest contrast/accessibility tasks belong elsewhere. However, it never explicitly names alternatives or states when not to use this tool, so the agent must infer routing from names rather than guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Suggest a replacement color that meets a WCAG contrast target. Adjusts lightness while preserving hue and saturation to stay as close to the original as possible.
| Name | Required | Description | Default |
|---|---|---|---|
| fix | No | Which color to adjust (default: foreground) | foreground |
| background | Yes | Background color | |
| foreground | Yes | Foreground color | |
| target_level | No | WCAG target level (default: AA) | AA |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden and largely succeeds: it discloses the adjustment strategy (lightness only) and the constraint (preserve hue/saturation and stay close to the original). It does not mention failure behavior for impossible contrast targets or the return format, but the core behavioral contract is clearly stated.
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?
Two sentences with no filler: the first states the primary purpose, and the second adds the key behavioral constraint. Every word earns its place and the most important information is front-loaded.
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?
The tool is a simple pure function with all parameters documented in the schema and an implied return value ('replacement color'). The description covers purpose and behavior sufficiently, though it could be more complete by addressing impossible contrast targets and explicitly mentioning sibling tool alternatives.
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 100%, so the schema already documents all four parameters; the baseline is 3. The description adds algorithmic context but no additional parameter-specific meaning, such as accepted color formats or how target_level maps to adjustment behavior.
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 uses a specific verb ('Suggest') and resource ('a replacement color that meets a WCAG contrast target'), and adds the algorithm nuance of adjusting lightness while preserving hue and saturation. This clearly differentiates it from sibling tools check_contrast and parse_color, which do not generate replacement colors.
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 intended use case is implied: use this when a color pair needs to meet a WCAG contrast target and you want the closest adjusted color. However, the description does not explicitly state when not to use it or how it relates to check_contrast and parse_color, so it stops short of clear exclusions or alternative guidance.
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.
v1.0.0check_contrastparse_colorsuggest_accessible_colorScored across 3 tools
Each tool has a clearly distinct purpose: checking contrast, suggesting accessible alternatives, and parsing color formats. No overlapping functionality exists.
All tool names follow a consistent verb_noun pattern in snake_case (check_contrast, suggest_accessible_color, parse_color). Naming is predictable and uniform.
Three tools is well-scoped for a focused utility server. Each tool earns its place without redundancy or bloat.
The tool surface covers the core workflows of the domain: analyzing contrast, generating accessible alternatives, and parsing colors. No obvious missing operations for the stated purpose.
WCAG AA contrast for two hex colors
WCAG AAA contrast for two hex colors
Accessibility compliance for AI coding tools. WCAG 2.2 reviews with shared evidence.
Scan URLs for WCAG 2.1 violations, generate AI fixes, and produce VPAT 2.5 compliance reports.
