Tailwind's real vocabulary is whatever the project's config produces, including arbitrary values and custom scales, so any validator working from a static list will reject valid classes and accept invalid ones. Running the classes through the compiler makes the answer authoritative. The conflict detector addresses the other common failure, which is subtler: two utilities setting the same property do not error, they silently resolve by stylesheet order and produce something that looks nearly right. Supporting both the v3 config file and the v4 CSS theme is necessary rather than generous — that migration split the ecosystem and a tool that handles one is useless on the other.
A Tailwind configuration analysis toolkit: it resolves the project's real theme, validates class strings against it, detects conflicts, and audits which tokens are actually used.
- validate_class_string checks a className against the project's own configuration rather than against Tailwind's defaults, which is where a model's guess usually goes wrong.
- detect_css_conflicts finds utilities that fight each other in the same class string — two values for the same property, where the winner depends on stylesheet order.
- simulate_jit_compilation validates classes against the JIT engine programmatically, which is the authoritative answer rather than a lookup table.
- resolve_theme_tokens queries the resolved theme for a namespace, and resolve_v4_theme_variables parses the root CSS file for Tailwind v4 projects where the theme lives in CSS rather than a config file.
- audit_theme_usage scans the project to identify dead design tokens — defined and never used.
- get_config_summary returns a compact overview including the version, which decides which of the two theme paths applies.
A Tailwind project for it to read — the tools work against the project's own configuration and CSS.
One command — npx -y tailwind-context-resolver-mcp