This MCP server lets AI agents generate and look up Tailwind CSS color palettes, convert colors, and find closest Tailwind matches.
Generate a full Tailwind palette (50–950) from any CSS color, placing the input color exactly at its best-fit shade.
Output palettes for Tailwind v4, v3, v2, or v1 in formats like @theme, tailwind.config.js, plain CSS variables, runtime ‘live’ CSS, or Shopify theme code.
Find the closest default Tailwind color/shade for a given color, with distance and visibility info.
Retrieve Tailwind’s default colors for any major version, either whole colors or specific shades.
List available default Tailwind color names, shade ranges, and sample values.
Convert any CSS color to oklch(), hex, and rgb formatted like Tailwind.
Use the add_brand_color prompt to guide adding a brand color to a project’s Tailwind theme.
All tools are read-only.
Generates complete Tailwind CSS color palettes (shades 50–950) from any input color, matching the project's Tailwind version (v4, v3, v2, v1). Provides tools to produce ready-to-paste palette code (e.g. a v4 @theme block, a v3 tailwind.config.js entry, or CSS variables) and to find the closest existing Tailwind color class to a given color (e.g. #db4d53 → red-500).
An MCP server that gives AI agents real Tailwind CSS palettes, so they stop guessing shades. Works with Tailwind v4, v3, v2 and v1.
Ask your agent "Add a brand color #db4d53 to my theme", and it writes a full 50 to 950 palette in the project's Tailwind format, with #db4d53 exactly at brand-500. Same engine as the Tailwind Shades editor extension and tailwindshades.bourhaouta.com.
Connect your agent to https://tailwindshades.bourhaouta.com/mcp (Streamable HTTP, no API key).
Claude Code
claude mcp add --transport http --scope user tailwindshades https://tailwindshades.bourhaouta.com/mcpCursor (~/.cursor/mcp.json, or .cursor/mcp.json in a project)
{
"mcpServers": {
"tailwindshades": { "url": "https://tailwindshades.bourhaouta.com/mcp" }
}
}VS Code (.vscode/mcp.json)
{
"servers": {
"tailwindshades": { "type": "http", "url": "https://tailwindshades.bourhaouta.com/mcp" }
}
}Runs on your machine with npx, so nothing leaves it. Needs Node.js 20 or later.
Claude Code
claude mcp add --scope user tailwindshades -- npx -y tailwindshades-mcpCursor (~/.cursor/mcp.json, or .cursor/mcp.json in a project)
{
"mcpServers": {
"tailwindshades": { "command": "npx", "args": ["-y", "tailwindshades-mcp"] }
}
}VS Code (.vscode/mcp.json)
{
"servers": {
"tailwindshades": { "command": "npx", "args": ["-y", "tailwindshades-mcp"] }
}
}Other agents: use the URL above, or run npx -y tailwindshades-mcp as a stdio server. It's also in the MCP Registry as io.github.bourhaouta/tailwindshades.
Related MCP server: MCP Color Converter
All five tools are read-only.
generate_paletteA full palette from one color, ready to paste.
Input | Default |
| required: any CSS color ( |
| the closest Tailwind color, which replaces Tailwind's own palette, so the tool warns |
|
|
|
|
|
|
|
|
live is for colors picked at runtime (a user, a tenant, a CMS setting): CSS where every shade follows one variable, rebuilt in the browser. shopify adds the color setting and Liquid line for Shopify themes, where the merchant picks the color in the theme editor. See Colors picked at runtime.
Returns the code, plus the shades, the shade that holds the input color and the closest Tailwind color as structured data.
The code starts with a comment of readable pairs: text and background classes that pass WCAG AA (4.5:1), tested on the real shades. Agents use them for buttons and text, so a red brand gets bg-brand-600 text-white instead of the failing bg-brand-500 text-white:
/* Readable pairs (WCAG AA, 4.5:1 or more):
button bg-brand-600 text-white 5.09:1
text bg-white text-brand-600 5.09:1
badge bg-brand-100 text-brand-700 5.43:1
dark mode bg-brand-950 text-brand-400 5.33:1
avoid bg-brand-500 text-white 4.03:1 */find_closest_tailwind_colorThe Tailwind shade that looks most like a color, e.g. #db4d53 → red-500, with Tailwind's value, the distance, and whether the difference is visible. Agents use it to pick an existing class instead of an arbitrary value, or to decide a custom palette is needed.
get_tailwind_paletteTailwind's own default colors, exactly as Tailwind defines them: a whole color (blue) or one shade (slate-500), for Tailwind v4, v3, v2 or v1. Values are oklch() in v4 and hex before. Agents use it instead of writing Tailwind's default values from memory.
list_tailwind_colorsThe names of Tailwind's default colors for a version (26 in v4, including mauve, olive, mist and taupe), with the shades they have and each one's 500 value as a sample.
convert_colorAny CSS color as oklch(), hex and rgb, formatted like Tailwind. Handy when a project on Tailwind v4 needs one oklch() value rather than a whole palette.
add_brand_colorArguments: color and an optional name (default brand). It asks the agent to find the project's Tailwind version, call generate_palette, and paste the code into the theme. Clients like Claude Code show it as a slash command.
The package also exports createServer(), a fresh McpServer with all its tools and the prompt. Serve it with the MCP TypeScript SDK, for example over HTTP in any web-standard runtime (this is how the remote server above runs, as a Next.js route):
import { createMcpHandler } from '@modelcontextprotocol/server'
import { createServer } from 'tailwindshades-mcp'
const handler = createMcpHandler(createServer)
export const POST = (request: Request) => handler.fetch(request)tailwindshades-cli: the same palettes from the command line
MIT © Omar Bourhaouta
Converts any CSS color to oklch(), hex and rgb, formatted like Tailwind (oklch() is what Tailwind v4 uses). Colors outside a format are mapped into it: oklch() to Display P3 like Tailwind's palette, hex and rgb to sRGB. Use it for one value; to add a color with all its shades, call generate_palette instead.
| Name | Required | Description | Default |
|---|---|---|---|
| color | Yes | Any CSS color: hex (#db4d53), rgb(), hsl(), oklch() or a named color |
| Name | Required | Description |
|---|---|---|
| hex | Yes | e.g. #db4d53 |
| rgb | Yes | e.g. rgb(219, 77, 83) |
| oklch | Yes | e.g. oklch(61.6% 0.177 21.62) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-open-world), and the description goes further by disclosing gamut behavior: out-of-format colors are mapped into Display P3 for oklch and sRGB for hex/rgb. That is real behavioral context beyond structured fields, though it does not mention precision, casing of hex output, or error behavior for unparseable input.
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?
Three compact sentences, front-loaded with the purpose and output formats before the routing advice. The parenthetical asides about Tailwind v4 are slightly chatty but still informative and not wasteful enough to drop it below a 4.
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?
An output schema exists, so return values need no explanation, and the description still covers the format, the gamut-mapping semantics, and the alternative tool. Nothing an agent needs to invoke this single-argument tool correctly is missing.
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?
Only one parameter and schema description coverage is 100%, so the schema already documents the accepted color syntaxes (hex, rgb(), hsl(), oklch(), named). The description's 'any CSS color' adds no syntax detail beyond that, so the baseline of 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 (converts) and resource (any CSS color) and names the exact output formats (oklch(), hex, rgb) with the Tailwind framing. It also explicitly distinguishes itself from the sibling generate_palette, so an agent can route correctly without opening schemas.
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?
Gives an explicit scope rule ('use it for one value') plus the alternative and the condition that selects it ('to add a color with all its shades, call generate_palette instead'). This is exactly the when/when-not/alternative structure the dimension rewards.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Finds the shade in Tailwind's default palette that looks most like a given color, e.g. #db4d53 -> red-500. Use it to pick an existing Tailwind class (bg-red-500) instead of an arbitrary value. If the difference is visible, use generate_palette to add the exact color as a custom palette instead.
| Name | Required | Description | Default |
|---|---|---|---|
| color | Yes | Any CSS color: hex (#db4d53), rgb(), hsl(), oklch() or a named color | |
| tailwindVersion | No | The project's Tailwind CSS major version. Defaults to 4 |
| Name | Required | Description |
|---|---|---|
| name | Yes | Tailwind color name, e.g. "red" |
| input | Yes | The input color |
| shade | Yes | Closest shade, e.g. 500 |
| distance | Yes | OKLab distance: 0 is identical, under 0.02 is hard to see |
| className | Yes | Color part of a utility class, e.g. "red-400" for bg-red-400 |
| tailwindValue | Yes | Tailwind's value for that shade |
| tailwindVersion | Yes | |
| visiblyDifferent | Yes | True when the Tailwind shade looks different from the input |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/closed-world, and the description adds the key behavioral nuance that this is an approximate nearest-match (not an exact lookup), plus the practical consequence that a visible difference should route to generate_palette. It doesn't discuss tolerance thresholds or return shape, but the output schema covers the latter.
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?
Three short sentences: purpose+example first, then the preferred use, then the fallback. Every sentence carries distinct decision-relevant information with no filler.
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?
With an output schema present, return values need not be described. For a two-parameter lookup tool, the description supplies purpose, example, and the sibling routing rule, leaving nothing an agent needs to invoke it correctly.
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 both parameters (color formats, tailwindVersion default 4) are already documented in the schema. The description's example illustrates the color input but adds no syntax or version-selection guidance beyond the schema. 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 and resource ('finds the shade in Tailwind's default palette most like a given color') and grounds it with a concrete input→output example (#db4d53 -> red-500). This clearly separates it from generate_palette, which creates new colors rather than matching existing ones.
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?
Explicitly states when to use it ('to pick an existing Tailwind class instead of an arbitrary value') and when to prefer the alternative ('if the difference is visible, use generate_palette to add the exact color'). The switching condition is concrete, not implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generates a full Tailwind CSS palette (50-950) from one color, ready to paste. Call it whenever you add a color to a Tailwind theme (e.g. "add a brand color #db4d53"), instead of writing a single variable or inventing shades. The input color stays exactly at its best-fit shade, and the other shades follow the closest Tailwind color, so they look like Tailwind's own.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Color name used in the code, e.g. "brand". Defaults to the closest Tailwind color, which replaces Tailwind's own palette of that name (e.g. red), so pass a name unless that is what the user wants | |
| color | Yes | Any CSS color: hex (#db4d53), rgb(), hsl(), oklch() or a named color | |
| plain | No | With output live or shopify: a plain :root block instead of @theme, for projects without Tailwind (like the Dawn theme) | |
| format | No | Color format. Defaults to oklch for v4 and hex for older versions | |
| output | No | theme: a v4 @theme block for the main CSS file. config: an object for theme.extend.colors in tailwind.config.js. css: plain CSS variables. live (v4 only): for a color picked at runtime (user, tenant or CMS setting): CSS where every shade follows one variable, --color-<name>, rebuilt in the browser with relative colors, with this palette as the fallback. shopify (v4 only): live, plus a settings_schema.json color setting and the Liquid line for snippets/css-variables.liquid, for Shopify themes where the merchant picks the color in the theme editor. Each part says which file it goes in. Defaults to theme for v4 and config for older versions | |
| semantic | No | With output live or shopify: also add --color-<name>-foreground for text on the color: white or the darkest shade, whichever contrasts more, following the runtime color | |
| tailwindVersion | No | The project's Tailwind CSS major version. Defaults to 4 |
| Name | Required | Description |
|---|---|---|
| code | Yes | The palette as code, ready to paste |
| name | Yes | |
| avoid | No | White text on the input color, when it fails WCAG AA |
| format | Yes | |
| output | Yes | |
| shades | Yes | |
| inputShade | Yes | Shade that holds the input color unchanged, e.g. 500 |
| readablePairs | No | Text and background pairs that pass WCAG AA. Use them for text and buttons in this color. Not for live and shopify outputs, whose shades change at runtime |
| tailwindVersion | Yes | |
| closestTailwindColor | Yes | Tailwind color whose curve the palette follows |
| replacesTailwindColor | Yes | True when the code replaces a default Tailwind palette (default color name, theme or config output) |
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 a real behavioral guarantee beyond that: the input color is pinned to its best-fit shade and the remaining shades track the closest Tailwind color, producing Tailwind-consistent output. It stops short of describing any limits or edge cases.
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, zero filler, and the purpose is front-loaded ahead of the usage rule. The behavioral nuance about shade matching is packed into the tail of the second sentence rather than a separate paragraph.
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?
An output schema exists so return values need no explanation, annotations carry the safety profile, and all 7 parameters are documented in the schema. Purpose, invocation trigger, and output-quality expectation are all present — nothing an agent needs is missing.
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%, and the parameter descriptions themselves are unusually rich (output modes, defaults, name-replacement caveat). The description adds no parameter-level information of its own, so this sits at the baseline for fully documented schemas.
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 and resource with scope: 'Generates a full Tailwind CSS palette (50-950) from one color, ready to paste.' The 'from one color' framing cleanly separates it from get_tailwind_palette (retrieval) and find_closest_tailwind_color (lookup) without needing to name them.
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?
Gives an explicit trigger ('Call it whenever you add a color to a Tailwind theme') with a concrete example, plus a negative case ('instead of writing a single variable or inventing shades'). It does not name the sibling tools that cover the cases this tool is not for, so routing is clear but not complete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Looks up Tailwind's own default colors, exactly as Tailwind defines them: a whole color (e.g. "blue", all shades) or one shade (e.g. "slate-500"), for Tailwind v4, v3, v2 or v1. Use it instead of writing default Tailwind color values from memory. Values are oklch() in v4 and hex in older versions.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | A default Tailwind color, like "blue", or one shade of it, like "blue-500" | |
| tailwindVersion | No | The project's Tailwind CSS major version. Defaults to 4 |
| Name | Required | Description |
|---|---|---|
| name | Yes | Tailwind color name, e.g. "blue" |
| shades | Yes | All shades, or only the one asked for |
| tailwindVersion | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, closed-world behavior, and the description usefully adds that returned values are oklch() in v4 and hex in older versions. It says nothing about failure behavior for unknown color names, which is the remaining behavioral 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?
Three tight sentences, front-loaded with the core action and scope before the usage directive and format note. No redundant or filler content.
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?
An output schema exists, so return values need no elaboration, and annotations cover the safety profile. For a two-parameter lookup tool this description supplies everything an agent needs to call it correctly.
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 both parameters are already documented, including the version enum. The description's version/format note (oklch in v4, hex earlier) adds a little meaning but does not go beyond what the schema already conveys about accepted inputs.
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 and resource ("Looks up Tailwind's own default colors") and qualifies scope precisely (a whole color or a single shade, across v1-v4). It does not explicitly distinguish itself from the siblings find_closest_tailwind_color and generate_palette, so it stops short of a 5.
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?
"Use it instead of writing default Tailwind color values from memory" gives a clear condition for reaching for this tool. It names no alternative tool and no exclusion case, so it lacks the explicit when-not routing that would earn a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists the names of Tailwind's default colors for a Tailwind version (e.g. red, slate, mauve in v4), with the shades each one has and its 500 value as a sample. Use it to see which colors exist before calling get_tailwind_palette or picking a utility class.
| Name | Required | Description | Default |
|---|---|---|---|
| tailwindVersion | No | The project's Tailwind CSS major version. Defaults to 4 |
| Name | Required | Description |
|---|---|---|
| colors | Yes | |
| shades | Yes | Shades every color has, e.g. 50 to 950 |
| tailwindVersion | 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 the safety profile is fully covered. The description adds the shape of each returned entry (shade list plus a 500 sample), but an output schema exists, so this is largely restating structured data rather than adding behavioral context.
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 zero filler; the purpose and return shape come first and the usage routing follows. Every clause earns its place.
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?
With a single optional enum parameter, full schema coverage, and an output schema handling return values, the description supplies everything else an agent needs: scope, entry contents, and the workflow position relative to get_tailwind_palette.
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% for the single tailwindVersion enum parameter, so the schema already carries the meaning. The description only implies that the version changes the color set ("for a Tailwind version" with the v4 mauve example), which is marginal value over the enum's own description.
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 ("Lists the names of Tailwind's default colors") and specifies exactly what each entry contains: name, available shades, and the 500 sample value. It also implicitly distinguishes itself from the sibling get_tailwind_palette, which returns palette data rather than the color inventory.
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?
Gives an explicit use case ("see which colors exist before calling get_tailwind_palette or picking a utility class"), naming the sibling it precedes in a workflow. An agent knows when to reach for this versus the palette tool without further inference.
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.6.0generate_palette2 fields changedOutput schema / properties / avoidAdded value: +{
+ "additionalProperties": false,
+ "description": "White text on the input color, when it fails WCAG AA",
+ "properties": {
+ "classes": {
+ "type": "string"
+ },
+ "ratio": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "classes",
+ "ratio"
+ ],
+ "type": "object"
+}Output schema / properties / readablePairsAdded value: +{
+ "description": "Text and background pairs that pass WCAG AA. Use them for text and buttons in this color. Not for live and shopify outputs, whose shades change at runtime",
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "classes": {
+ "description": "e.g. \"bg-brand-600 text-white\"",
+ "type": "string"
+ },
+ "level": {
+ "enum": [
+ "AA",
+ "AAA"
+ ],
+ "type": "string"
+ },
+ "ratio": {
+ "description": "WCAG contrast ratio, 4.5 or more",
+ "type": "number"
+ },
+ "use": {
+ "description": "dark: text in dark mode",
+ "enum": [
+ "button",
+ "text",
+ "badge",
+ "dark"
+ ],
+ "type": "string"
+ }
+ },
+ "required": [
+ "use",
+ "classes",
+ "ratio",
+ "level"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+}v1.5.1generate_palette4 fields changedInput schema / properties / output / descriptionPrevious value: -"theme: a v4 @theme block for the main CSS file. config: an object for theme.extend.colors in tailwind.config.js. css: plain CSS variables. Defaults to theme for v4 and config for older versions"New value: +"theme: a v4 @theme block for the main CSS file. config: an object for theme.extend.colors in tailwind.config.js. css: plain CSS variables. live (v4 only): for a color picked at runtime (user, tenant or CMS setting): CSS where every shade follows one variable, --color-<name>, rebuilt in the browser with relative colors, with this palette as the fallback. shopify (v4 only): live, plus a settings_schema.json color setting and the Liquid line for snippets/css-variables.liquid, for Shopify themes where the merchant picks the color in the theme editor. Each part says which file it goes in. Defaults to theme for v4 and config for older versions"Input schema / properties / output / enumPrevious value: -[
- "theme",
- "config",
- "css"
-]New value: +[
+ "theme",
+ "config",
+ "css",
+ "live",
+ "shopify"
+]Input schema / properties / plainAdded value: +{
+ "description": "With output live or shopify: a plain :root block instead of @theme, for projects without Tailwind (like the Dawn theme)",
+ "type": "boolean"
+}Input schema / properties / semanticAdded value: +{
+ "description": "With output live or shopify: also add --color-<name>-foreground for text on the color: white or the darkest shade, whichever contrasts more, following the runtime color",
+ "type": "boolean"
+}v1.4.0convert_colorlist_tailwind_colorsclosest_tailwind_colorfind_closest_tailwind_colorget_tailwind_palettev0.1.0closest_tailwind_colorgenerate_paletteScored across 5 tools
Each tool has a clearly distinct purpose: generate custom palettes, convert individual colors, find nearest default shade, retrieve exact default palette values, and list default color names. The descriptions explicitly differentiate overlapping cases (e.g., convert_color vs. generate_palette, find_closest_tailwind_color vs. get_tailwind_palette).
All tool names use a consistent snake_case verb_noun pattern (generate_palette, convert_color, find_closest_tailwind_color, get_tailwind_palette, list_tailwind_colors). The convention is predictable and easy to scan.
Five tools are well-scoped for a focused Tailwind color utility server. Each tool covers a distinct operation and none feels redundant or excessive.
The surface covers the core lifecycle: listing, retrieving, converting, matching, and generating palettes. Minor gaps exist (e.g., no batch conversion or accessibility/contrast checking), but these are workaroundable and not critical for the stated purpose.
18 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.
Solve, audit and simulate colorblind-safe chart palettes. WCAG contrast, OKLab ΔE. Read-only.
Generate design systems: OKLCH colors, fluid type scales, spacing, shape, icon and motion tokens.