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., "@tailwind-mcp diagnose p-4 flex bg-red-501 mt-[16px] p-2 p-4 shadow-sm"
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.
A Model Context Protocol server that asks Tailwind itself. No hand-written class lists, no stale snapshots — the server loads your project's own
tailwindcssand queries the real engine, so every answer matches the code you actually build.
Tools | 9 read-only tools ( |
Engine | your project's own |
Class list | 23 000+ real utilities, straight from the engine that generates them |
Latency | 13–340 ms per call, no network, no database |
Dependencies | one runtime dependency tree from the official SDK |
Reload | config edits are picked up automatically — no restart, ever |
An LLM writing Tailwind makes three mistakes, all of them the same mistake: it invents classes that do not exist.
<div class="bg-gray-600 p-4 shadow-lg">
<!-- does this class exist in THIS project? -->
<div class="bg-red-550 mt-[16px]">
<!-- typo, and a magic number instead of a token -->
<div class="p-2 p-4 text-sm text-lg"><!-- which of these two actually wins? --></div>
</div>
</div>Every existing "Tailwind MCP" answers this by shipping a class list copied from a documentation snapshot. That list is wrong the moment you use a custom theme, a plugin, or a version newer than the copy — and it cannot tell you which of two conflicting classes wins, because that depends on your project's own configuration.
This server has no list. It loads the tailwindcss package from your node_modules and asks
the engine:
your project → your tailwindcss → the real engine → the real answerthe class list contains exactly the utilities your project can build, including custom theme
values, @utility blocks and plugin classes;
the version is yours, so v3 and v4 projects each get the truth for their own generation;
which class wins a conflict is decided by Tailwind's own class order, not by a guess;
when you edit your config, the server notices and rebuilds itself — no restart.
Related MCP server: TailwindCSS MCP Server
Requires Node.js ≥ 20.
git clone https://github.com/vitkuz573/tailwind-mcp.git
cd tailwind-mcp
npm ci
npm run buildopencode mcp add tailwind -- node /absolute/path/to/tailwind-mcp/dist/index.jsOr by hand:
{
"$schema": "https://opencode.ai/config.json",
"mcp": {
"servers": {
"tailwind": {
"type": "local",
"command": ["node", "/absolute/path/to/tailwind-mcp/dist/index.js"],
"timeout": { "startup": 60000, "execution": 120000 },
},
},
},
}The server finds the project by walking up from its working directory until it finds a
node_modules/tailwindcss. Every tool also takes an optional project argument with an absolute
path, for when the Tailwind project is not the current directory.
claude mcp add tailwind -- node /absolute/path/to/tailwind-mcp/dist/index.jsnode dist/index.js # stdio transporttailwind_diagnose — start hereOne call, every problem with a class list.
{ "candidates": ["p-4 flex bg-red-501 mt-[16px] p-2 p-4 shadow-sm"] }Finding | Meaning | Example |
unknown | the class does not exist, with spelling suggestions |
|
arbitrary | an arbitrary value where a theme token would do |
|
conflicting | one class silently overrides another |
|
migration | a v3 class whose meaning changed in v4 |
|
Suggestions come from the real class list, so a missing shade is completed too: bg-brand becomes
bg-brand-500 when your project defines that scale.
Tool | Answers |
| Do these classes exist, and what CSS do they produce? |
| What is the exact name of the utility I need? |
| Which design tokens does this project define? |
| Which variants does this project understand? |
| Which of these two classes wins? |
| How should this class list be written? |
| What does this v3 class become in v4? |
| Is this text readable on that background? |
Which class wins. Tailwind sorts the utilities it generates, and at equal specificity the later
rule wins. The server asks the engine for that order rather than guessing, so p-4 beating p-2
is a fact, not a heuristic. Shorthands are expanded, so p-4 and pl-2 are correctly seen to
fight over the left padding.
The v3 trap. In v4 the whole shadow, radius and blur scale shifted. shadow-sm still exists —
and now means what shadow-xs used to mean. The server flags that as meaning-changed, because the
class compiles and the bug is silent.
Contrast. Tailwind v4 stores colours as oklch(). The server converts to sRGB following
CSS Color 4, including the chroma reduction needed for colours outside the sRGB gamut, and reports
the WCAG AA and AAA verdicts.
Reloading. The set of files that feed the design system is discovered by following @import,
@config and @plugin, and a size/mtime fingerprint of those files decides whether the engine
has to be rebuilt. Edit any of them and the next call sees the change.
Package imports. A real stylesheet imports more than itself: the framework's own sheet,
packages that ship utilities (tw-animate-css), and sub-paths of packages (shadcn/tailwind.css).
All three are resolved through the package's exports map, preferring the style condition, and
plugins are loaded from packages too (@plugin "@tailwindcss/typography"). Nothing has to be
rewritten or stubbed out.
Measured against a real project with a custom theme, on the first call after a server start:
Tool | Latency |
| 13 ms |
| 16 ms |
| 17 ms |
| 21 ms |
| 126 ms |
| 305 ms |
| 344 ms |
There is no network call, no database and no cache to go stale. The engine is rebuilt when your configuration changes, so the first call after an edit pays the reload cost once.
Tailwind's own
canonicalizeCandidatesis deliberately not used: it builds an index of every class on first use, which takes seconds and blocks the event loop. The same two rules are applied locally against your theme instead, which answers in milliseconds.
npm run verify # format check, typecheck, tests, build
npm test # vitest
npm run inspect # MCP inspectorThe tests run against real Tailwind installations in temporary project fixtures — v3 and v4, with custom themes, TypeScript configs and plugins. Nothing is mocked.
Tailwind Labs does not ship an official Tailwind MCP server. This is an independent implementation built on the official MCP SDK and Tailwind's own public engine API.
MIT
Rewrite a class list into Tailwind's canonical form and order: arbitrary values that match a theme token become that token, deprecated spellings are renamed, and the classes are sorted the way prettier-plugin-tailwindcss would sort them.
| Name | Required | Description | Default |
|---|---|---|---|
| project | No | Absolute path to the project to inspect. Defaults to the server's working directory. Use it when the Tailwind project is not the current working directory. | |
| candidates | Yes | The class list to canonicalise, e.g. ['mt-[16px]', 'p-4', 'flex'] |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered; the description goes further by naming the exact transformations applied (token substitution, deprecated renames, prettier ordering). It stops short of noting that theme-token resolution depends on the project/config, which is the one behavioural caveat an agent would want.
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 front-loaded sentence whose clauses each enumerate a distinct transformation, with zero filler. It is dense but every phrase earns its place; only the trailing 'the way prettier-plugin-tailwindcss would sort them' could be trimmed.
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 no output schema, the description should clarify the return shape, but it never says whether the canonicalised list comes back as a string or an array, nor whether anything is written to disk (readOnlyHint implies not). For a pure transformation tool that omission is the main completeness gap.
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 both parameters are documented in the schema, so the description is not required to carry parameter meaning. It adds only indirect context (the theme-token mention hints at why 'project' matters) and no format or syntax detail 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?
Specific verb (rewrite/canonicalise) plus resource (a Tailwind class list) and three concrete transformations (arbitrary values to theme tokens, deprecated spellings renamed, prettier-plugin ordering). The only gap is that it never explicitly distinguishes itself from tailwind_migrate, which plausibly also rewrites class names.
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?
Usage is implied by the purpose: you reach for this when you have a class list that needs canonicalising or sorting. There is no explicit when-not guidance, no prerequisite statement (e.g. needing a Tailwind config to resolve theme tokens), and no routing to or away from siblings like tailwind_migrate or tailwind_validate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Report which class wins when several set the same CSS property, and which ones are silently overridden. The winner follows Tailwind's own class order.
| Name | Required | Description | Default |
|---|---|---|---|
| project | No | Absolute path to the project to inspect. Defaults to the server's working directory. Use it when the Tailwind project is not the current working directory. | |
| candidates | Yes | The class list to check, e.g. ['p-2', 'p-4', 'text-sm', 'text-lg'] |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint=true, openWorldHint=false), and the description adds real behavioral context: overrides happen 'silently' and the tie-break follows Tailwind's own class order. It omits anything about output shape or scale limits, but it goes beyond what the annotations state.
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, no filler, with the outcome (which class wins, which is overridden) front-loaded and the tie-break rule stated immediately after. Every sentence 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?
There is no output schema, so the description has to convey the return value, and it does so at a high level (winner plus overridden classes) without describing the result's structure or field names. For a two-parameter, read-only tool this is nearly complete, with only the response shape left unspecified.
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% -- both 'project' (path semantics, default working directory) and 'candidates' (with an example list) are fully documented in the schema. The description adds no parameter-level detail, so the 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: it reports which conflicting Tailwind class wins and which are silently overridden. That is precise enough to separate it from siblings like tailwind_validate (rule-checking) or tailwind_canonicalize (rewriting class order).
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?
Usage is only implied by the scenario ('when several set the same CSS property'); there is no explicit when-to-use statement, no exclusions, and no named alternative among the eight sibling tools. Adequate but leaves routing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compute the WCAG contrast ratio of two colours and whether they pass AA or AAA. Colours may be theme tokens such as 'red-500' or 'white', or literal CSS colours.
| Name | Required | Description | Default |
|---|---|---|---|
| project | No | Absolute path to the project to inspect. Defaults to the server's working directory. Use it when the Tailwind project is not the current working directory. | |
| background | Yes | The background colour, e.g. 'slate-900' or 'white' or '#fff' | |
| foreground | Yes | The text colour, e.g. 'white' or 'red-500' or '#333' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare readOnlyHint=true and openWorldHint=false, so the description must add more, and it does: it discloses that theme tokens ('red-500', 'white') are resolved as well as literal CSS colours, and since there is no output schema it names the return content (ratio plus AA/AAA verdict). It stops short of stating failure behaviour for unresolvable tokens.
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 tight sentences, with the core operation front-loaded and the accepted input formats second. No filler, no repetition of the title, nothing that fails to earn 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?
For a simple 3-parameter read-only tool with full schema coverage, the description covers what the tool computes and what the result contains, which is enough in the absence of an output schema. Minor gaps remain around error handling for unrecognised colour tokens and whether the project parameter is honoured when resolving tokens.
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 foreground, background, and the project override with examples. The description's 'theme tokens such as red-500 or white, or literal CSS colours' largely restates what the parameter descriptions already say, so the 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: 'Compute the WCAG contrast ratio of two colours' plus the pass/fail outcome. The purpose is unambiguous and clearly unlike any sibling (validate, theme, variants, migrate), but the description never names or contrasts a sibling, so it lands at the 'clear, no sibling differentiation' level.
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 gives no when-to-use guidance, no prerequisites, and no alternatives. It does not say whether this is meant for auditing a theme before shipping or spot-checking a pair of tokens, nor what to do if a token is not found in the project.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check a class list for every problem at once: classes that do not exist (with spelling suggestions), classes that use an arbitrary value where a theme token would do, classes that override each other, and v3 classes that need migrating to v4. This is the tool to call before writing or editing markup.
| Name | Required | Description | Default |
|---|---|---|---|
| project | No | Absolute path to the project to inspect. Defaults to the server's working directory. Use it when the Tailwind project is not the current working directory. | |
| candidates | Yes | The class list to diagnose, e.g. ['p-4', 'bg-red-501', 'mt-[16px]', 'p-2 p-4'] |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds meaningful behavioral context by specifying the diagnostics performed (nonexistent classes with spelling suggestions, arbitrary-value warnings, override detection, v3-to-v4 migration needs). It doesn't describe the exact response shape, but the problem categories give a strong behavioral picture.
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, front-loaded with the core action ('Check a class list for every problem at once'), followed by the usage directive. Every clause earns its place by specifying a distinct diagnostic category or the invocation condition.
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 diagnostic tool with two documented parameters and read-only annotations, the description covers the key capabilities and the invocation context well. The main gap is the lack of output-format detail (e.g., how issues are structured), which matters more because there is no output schema, but the enumerated problem categories largely compensate.
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 schema already documents both parameters with examples for the class list. The description only refers generically to 'a class list' and adds no additional syntax, format, or project-path semantics beyond what the schema provides. Baseline 3 is appropriate.
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 gives a precise verb (check/diagnose) and resource (a class list), and enumerates four specific problem categories. The phrase 'every problem at once' differentiates it from narrower siblings like tailwind_validate, tailwind_conflicts, and tailwind_migrate by signaling it is the comprehensive aggregate diagnostic.
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?
It states a clear usage context: 'This is the tool to call before writing or editing markup.' That tells an agent when to reach for it. However, it doesn't name alternative tools or explain when to use a narrower sibling instead, so it stops short of explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Map v3 class names to their v4 equivalents, including the scale renames whose meaning changed silently (shadow-sm, rounded, blur and the rest). Use this when porting v3 code to v4.
| Name | Required | Description | Default |
|---|---|---|---|
| project | No | Absolute path to the project to inspect. Defaults to the server's working directory. Use it when the Tailwind project is not the current working directory. | |
| candidates | Yes | The v3 class list to migrate, e.g. ['shadow-sm', 'bg-opacity-50', 'flex-shrink-0'] |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description goes beyond them by flagging that scale renames like shadow-sm, rounded and blur changed meaning silently, which warns the agent the mapping is not a naive find-and-replace. It still omits how unknown or already-v4 classes 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?
Two sentences, front-loaded with the core mapping behavior and followed by the porting context. The parenthetical enumerates the risky renames compactly without padding.
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 read-only mapping tool with no output schema, the description conveys what the result is (v3 to v4 equivalents) and when to use it. Missing only edge-case behavior such as unrecognized classes or how conflicts between mapped classes are resolved.
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 both parameters, including a concrete candidate example and the project path default, so the schema carries the burden. The description adds no syntax or format detail beyond what is already structured there; 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+resource: mapping v3 class names to v4 equivalents, with examples of the class families involved. It does not, however, differentiate itself from the sibling tailwind_canonicalize, which an agent could plausibly confuse with a class-rewriting tool.
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 this when porting v3 code to v4" gives a clear triggering context. There is no explicit when-not guidance and no named alternative for adjacent tasks (e.g. canonicalize), so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the project's real Tailwind class list. Use when you know the intent but not the exact utility name. Returns utility names and the modifiers they accept.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum results to return | |
| query | No | Case-insensitive substring to match, e.g. 'rounded', 'shadow' | |
| offset | No | Number of results to skip | |
| prefix | No | Only return classes starting with this prefix, e.g. 'bg-' | |
| project | No | Absolute path to the project to inspect. Defaults to the server's working directory. Use it when the Tailwind project is not the current working directory. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds genuinely new behavioral context: it searches the project's real class list (project-scoped, not generic docs) and returns utility names plus their accepted modifiers. It omits any mention of pagination despite offset/limit parameters, which is a minor 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 short sentences, no redundancy: purpose first, then usage trigger, then return shape. Every sentence earns its place and the most decision-relevant 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?
With no output schema, the description usefully states the return contents (utility names and their modifiers), which the agent needs. The remaining gap is pagination/limit semantics, but those are adequately covered by the parameter schema.
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 every parameter (query, prefix, project, limit, offset) is documented in the schema itself. The description adds no syntax, format, or matching semantics beyond what the schema already states, so 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?
Specific verb (search) plus a precisely scoped resource: 'the project's real Tailwind class list,' which signals it queries the actual project rather than a static catalog. It is distinguishable from siblings like tailwind_validate or tailwind_theme by the search/naming intent, though it never explicitly names a sibling to contrast against.
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 when you know the intent but not the exact utility name' gives a clear, actionable trigger condition. There are no exclusions or named alternatives, so an agent must infer that tailwind_validate or tailwind_canonicalize handle the cases where a name is already known.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read the project's design tokens: colors, spacing, breakpoints, fonts and any custom theme values. Use the project's own token names instead of generic ones.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum results to return | |
| query | No | Substring to match, e.g. 'red' or 'primary' | |
| offset | No | Number of results to skip | |
| project | No | Absolute path to the project to inspect. Defaults to the server's working directory. Use it when the Tailwind project is not the current working directory. | |
| namespace | No | Restrict to a namespace, e.g. 'color', 'spacing', 'breakpoint' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered structurally. The description adds that custom theme values are included alongside standard tokens, which is useful context, but it says nothing about behavior when no Tailwind config is found, whether defaults are merged in, or how limit/offset pagination behaves.
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 short sentences, the read scope front-loaded and the one piece of operational advice placed second. No filler or restatement of the title.
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 no output schema, the description is responsible for framing the return value, and it does list the token categories. However, it omits pagination behavior for limit/offset, result ordering, and failure modes, leaving gaps for a tool whose output shape is otherwise undocumented.
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% with five fully documented parameters, so the schema carries the load and 3 is the baseline. The description's mention of colors/spacing/breakpoints loosely maps to the namespace parameter, but adds no syntax or semantics beyond the schema.
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 (Read) and resource (the project's design tokens), enumerating what's returned: colors, spacing, breakpoints, fonts, custom values. It distinguishes itself from siblings like tailwind_contrast or tailwind_migrate by resource, but never explicitly contrasts with tailwind_search_classes or tailwind_variants, so sibling differentiation is left implicit.
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 only guidance is "Use the project's own token names instead of generic ones," which is a naming convention, not a when-to-use rule. There is no statement of when to prefer this over tailwind_search_classes or tailwind_variants, and no prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check whether candidate Tailwind classes exist in this project and return the CSS they generate. Accepts variants (md:hover:bg-red-500) and arbitrary values (w-[37px]). Use before writing markup to avoid emitting classes that do not exist.
| Name | Required | Description | Default |
|---|---|---|---|
| project | No | Absolute path to the project to inspect. Defaults to the server's working directory. Use it when the Tailwind project is not the current working directory. | |
| candidates | Yes | Tailwind class candidates to validate, e.g. ['p-4', 'bg-red-500', 'text-nope'] |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds real value beyond that: it discloses accepted input forms (variants like md:hover:bg-red-500, arbitrary values like w-[37px]) and that CSS is produced as a result. It omits how unknown classes are reported, which keeps it below a 5.
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: purpose and return first, then accepted input forms, then the usage trigger. Every sentence earns its place with no repetition or 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 no output schema, the description does carry the burden of explaining the return, and it does say CSS is generated. However, it does not describe the response shape (e.g. per-candidate validity flags or how failures appear), so it is nearly but not fully complete for a two-param read-only tool.
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 project default. The description's variant/arbitrary-value examples add mild meaning but largely echo what the schema already conveys, making the baseline 3 appropriate.
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 (check/validate) and resource (Tailwind class candidates) with explicit scope ('in this project') and the return ('the CSS they generate'). It is distinguishable from most siblings, but it does not explicitly contrast itself with close neighbors like tailwind_conflicts or tailwind_canonicalize.
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 before writing markup to avoid emitting classes that do not exist' gives a clear use context and a proactive trigger. It does not name alternative siblings or state when not to use it, so it stops short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the variants this project understands, such as hover:, md:, dark: or data-[state=open]. Use this to check that a variant exists before using it.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum results to return | |
| query | No | Substring to match, e.g. 'hover' | |
| offset | No | Number of results to skip | |
| project | No | Absolute path to the project to inspect. Defaults to the server's working directory. Use it when the Tailwind project is not the current working directory. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds that scope is project-local ('this project understands'), consistent with openWorldHint=false, but says nothing about ordering, pagination, or result shape.
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 short sentences with zero filler; the purpose and the use-case are front-loaded in order of importance.
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 read-only list tool with a fully documented schema and no output schema, the description covers purpose, examples, and usage. Only the returned result structure is left implicit, which is a minor gap.
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 limit, query, offset, and project are all documented in the schema itself, including project's default. The description adds no parameter-level detail, so the 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+resource ('List the variants this project understands') and gives concrete examples (hover:, md:, dark:). These examples implicitly separate it from siblings like tailwind_search_classes and tailwind_validate, though no sibling is named directly.
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 clear usage context: 'Use this to check that a variant exists before using it.' That is a real when-to-use signal, but it names no alternatives or exclusions (e.g. when to prefer tailwind_search_classes instead).
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.
v0.1.0tailwind_canonicalizetailwind_conflictstailwind_contrasttailwind_diagnosetailwind_migratetailwind_search_classestailwind_themetailwind_validatetailwind_variantsScored across 9 tools
Most tools have clearly distinct purposes (search, theme, variants, migrate, contrast). However tailwind_validate and tailwind_diagnose overlap significantly, since diagnose also detects non-existent classes, and both are pitched as the thing to run before writing markup, creating a real risk of misselection.
Every tool follows the same tailwind_<verb/noun> snake_case pattern and reads consistently. No mixing of conventions.
Nine tools is well-scoped for a Tailwind helper surface; each covers a distinct facet (validate, search, theme, variants, diagnose, conflicts, canonicalize, migrate, contrast) with no obvious filler.
The surface covers the main lifecycle: discovery (search/theme/variants), validation, diagnostics, conflict resolution, canonicalization, migration, and accessibility. Only minor gaps remain, such as full stylesheet generation or config-editing operations.
Tailwind CSS palettes (50-950) from any color, the closest Tailwind color, and Tailwind's defaults
Canonicalize Tailwind classes to their short form, and search LunarWerx free dev tools.
Serves your design system and coding standards to coding agents, so they stop guessing.
Direct access to Cypress tests results and accessibility reports in your AI workflow.
