Tailwind Shades

Name: Tailwind Shades
Author: bourhaouta

by io.github.bourhaouta

Overview Discussions Admin

Server Details

Tailwind CSS palettes (50-950) from any color, the closest Tailwind color, and Tailwind's defaults

Ownership verified

Status: Healthy
Uptime: 100.0% over 21 days
Last Tested: 2026-10-21 13:44
Transport: Streamable HTTP · MCP 2025-11-25
URL
Repository: bourhaouta/vscode-tailwindshades
GitHub Stars: 78
Server Listing: tailwindshades-mcp

TDQS

A4.4/5.0

Scored 2026-10-15 17:40 across 5 tools

Disambiguation5/5

Each tool targets a distinct operation: convert_color converts a single CSS color, generate_palette creates a full custom palette, find_closest_tailwind_color maps an arbitrary color to the nearest default shade, get_tailwind_palette retrieves exact default values, and list_tailwind_colors enumerates available names. Descriptions explicitly guide when to use one over another, eliminating ambiguity.

Naming Consistency5/5

All names follow a consistent snake_case verb_noun pattern (convert_color, generate_palette, get_tailwind_palette, list_tailwind_colors), with find_closest_tailwind_color being a natural and readable variation. No mixed conventions or confusing prefixes.

Tool Count5/5

Five tools is well-scoped for a focused Tailwind color utility, covering conversion, lookup, closest-match, generation, and listing without redundancy or unnecessary depth.

Completeness4/5

The surface covers core workflows: single-color conversion, default palette lookup by version, closest-color matching, and custom palette generation. Minor gaps exist, such as generate_palette not explicitly supporting version-specific output formats (e.g., hex for v3) and no bulk conversion for custom palettes, but these are workable.

Available Tools

5 tools

convert_colorConvert a colorA

Read-onlyIdempotent

Inspect

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.

ParametersJSON Schema

Name	Required	Description	Default
`color`	Yes	Any CSS color: hex (#db4d53), rgb(), hsl(), oklch() or a named color

Output Schema

ParametersJSON Schema

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)

TDQS

A4.4/5.0

Behavior4/5

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.

Conciseness4/5

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.

Completeness5/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 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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.

find_closest_tailwind_colorFind the closest Tailwind colorA

Read-onlyIdempotent

Inspect

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.

ParametersJSON Schema

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

Output Schema

ParametersJSON Schema

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

TDQS

A4.5/5.0

Behavior4/5

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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.

generate_paletteGenerate a Tailwind paletteA

Read-onlyIdempotent

Inspect

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.

ParametersJSON Schema

Name	Required	Description
`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

Output Schema

ParametersJSON Schema

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)

TDQS

A4.3/5.0

Behavior4/5

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.

Conciseness5/5

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.

Completeness5/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 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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.

get_tailwind_paletteGet Tailwind's default colorsA

Read-onlyIdempotent

Inspect

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.

ParametersJSON Schema

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

Output Schema

ParametersJSON Schema

Name	Required	Description
`name`	Yes	Tailwind color name, e.g. "blue"
`shades`	Yes	All shades, or only the one asked for
`tailwindVersion`	Yes

TDQS

A4.1/5.0

Behavior4/5

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.

Conciseness5/5

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.

Completeness5/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 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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines4/5

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.

list_tailwind_colorsList Tailwind's default colorsA

Read-onlyIdempotent

Inspect

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.

ParametersJSON Schema

Name	Required	Description	Default
`tailwindVersion`	No	The project's Tailwind CSS major version. Defaults to 4

Output Schema

ParametersJSON Schema

Name	Required	Description
`colors`	Yes
`shades`	Yes	Shades every color has, e.g. 50 to 950
`tailwindVersion`	Yes

TDQS

A4.3/5.0

Behavior3/5

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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

1 tool updateOct 13, 2026

Changedgenerate_palette2 fields changed

addedOutput schema / properties / avoid

Added 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"
+}

addedOutput schema / properties / readablePairs

Added 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"
+}

1 tool updateOct 7, 2026

Changedgenerate_palette4 fields changed

changedInput schema / properties / output / description

Previous 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"

changedInput schema / properties / output / enum

Previous value: -[
-  "theme",
-  "config",
-  "css"
-]New value: +[
+  "theme",
+  "config",
+  "css",
+  "live",
+  "shopify"
+]

addedInput schema / properties / plain

Added value: +{
+  "description": "With output live or shopify: a plain :root block instead of @theme, for projects without Tailwind (like the Dawn theme)",
+  "type": "boolean"
+}

addedInput schema / properties / semantic

Added 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"
+}

2 tool updatesOct 2, 2026
- Addedconvert_color
- Addedlist_tailwind_colors
3 tool updatesOct 1, 2026
- Removedclosest_tailwind_color
- Addedfind_closest_tailwind_color
- Addedget_tailwind_palette
2 tool updatesOct 1, 2026
- First observedclosest_tailwind_color
- First observedgenerate_palette

Publisher details

Operator: Omar Bourhaouta · Publisher source
Operator website: https://tailwindshades.bourhaouta.com · Publisher source
Vendor relationship: First-party · Publisher source
Documentation: https://github.com/bourhaouta/vscode-tailwindshades#readme · Publisher source
Trust center: Not available
Restrictions: None. No paid plan, admin approval, regional restriction, or custom OAuth app is required. · Publisher source

Related MCP Connectors

PickShade color tools A
com.pickshade
18 color tools: OKLCH, WCAG and APCA contrast fixes, palettes, gradients, color blindness, tokens.
Design Tools Developer Tools
181
PaletteGet A
io.github.yang7206
Curated app, web and mini program color palettes with WCAG contrast and CSS variables.
41
Color Companion A
com.gumballtools
Convert colours between hex, RGB, HSL, OKLCH and CMYK, and compute harmonies.
Design Tools Developer Tools
11
Coolours A
ltd.perpetualsummer
Turn AI-designed colour palettes into Coolours links, with colour names, CSS and contrast checks
Design Tools Developer Tools
31

Related MCP Servers

Nearest Tailwind Colors
Developer Tools Code Analysis
brunocpf
F
license
B
quality
D
maintenance
Finds the closest Tailwind CSS palette colors to any given CSS color value. Supports multiple color spaces and customizable result filtering to help match designs to Tailwind's color system.
Updated a year ago (2025-11-28 19:35 UTC)
1
-
huetension mcp
Design Tools Image & Video Processing
leporel
A
license
Not graded
quality
B
maintenance
Extract palettes from images, generate harmonies, gradients, random palettes; Check WCAG and APCA contrast; Suggest nearest passing OkLCH lightness; Simulate color-blindness; Convert and sort colors across formats (hex / RGB / HSL / OkLCH / …)
Updated a month ago (2026-09-08 23:49 UTC)
MIT
TailwindCSS MCP Server
Developer Tools Documentation Access
CarbonoDev
A
license
B
quality
D
maintenance
Provides comprehensive tools for TailwindCSS development including utility class retrieval, CSS-to-Tailwind conversion, and color palette generation. It enables AI assistants to search documentation, generate component templates, and provide framework-specific installation guides.
Updated a year ago (2025-08-28 18:53 UTC)
8
1,391 npm
40
MIT
MCP Color Server
Developer Tools Image & Video Processing App Automation
keyurgolani
A
license
B
quality
D
maintenance
Enables comprehensive color manipulation, conversion between 22+ formats (HEX, RGB, HSL, CMYK, LAB, etc.), palette generation, gradient creation, and accessibility compliance checking. Supports framework-specific outputs for CSS, Swift, Android, Flutter, and Tailwind with high-precision conversions and visualization capabilities.
Updated a year ago (2025-09-23 20:18 UTC)
25
MIT

Try in Browser

Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Server Details

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Publisher details

Related MCP Connectors

Related MCP Servers

Glama MCP Gateway

Resources