Now AI Coding Tools Check If They Actually Used Your Tokens
By The WAALEE Team · · 4 min read
Here's a failure mode every extraction tool quietly ignores: you hand an agent a perfect token file, it reads it, and three components later it writes `background: #4f9bf5` straight into the JSX anyway because that's what felt right for this one button. The tokens were never wrong. The agent just didn't check its own work against them. Two new MCP servers, Preset and SuperDuperUI, are the first tools built specifically to catch that, after the code is written, not before.
Extraction answers the wrong question
Every design-token tool up to now, including the ones we've covered here, answers "what are my brand's real values." None of them answer "did the agent actually use them in the file it just wrote." Those are different problems. A model can read your tokens.json in full, acknowledge it, and still default back to a hardcoded hex value for one component it generated in a different pass, because nothing re-checked that output against the source of truth. Extraction gets the right answer into the context window. It doesn't force the agent to show its work.
Preset: a drift score and a violations list
Preset ships as an MCP server with over 60 tools for Claude Code, Cursor, Windsurf and Claude Desktop, and the ones that matter here are `validate_generated_code`, `quick_check_violations` and `check_drift`, which returns a 0 to 100 drift score for how far a file has wandered from the design system. Its own anti-patterns list names hardcoded hex values as a critical mistake, which tells you exactly what keeps happening in practice. You install it against a Preset account with `claude mcp add --transport http preset https://mcp.presetai.dev/mcp`, and the same `get_design_tokens` tool that feeds an agent the real values is sitting next to the tool that checks whether it used them.
SuperDuperUI: compliance as the last step, not an afterthought
SuperDuperUI takes a narrower, more opinionated shape. Its README lays out the intended loop explicitly: call `get_design_system` before writing UI, call `get_tokens` when exact values are needed, call `check_compliance` before calling the work done. That last tool flags hardcoded colors, bad spacing, unknown tokens and unrecognized components, and treats a hardcoded color as a hard error, not a warning. It installs with `npx @superduperui/context init` and auto-detects Claude Code, Cursor and Windsurf, so the compliance step isn't a separate audit you remember to run later, it's written into the same workflow as the generation itself.
- Both tools assume you already have a structured token file. Neither one extracts your brand's colors and type from a live site; they check an agent's output against values you (or another tool) already defined.
- Both put the check inside the same MCP session as generation, so the agent can self-correct in the same pass instead of a human catching a wrong hex code in review three days later.
- A hardcoded hex value is apparently common enough that two unrelated teams independently built a rule specifically against it. That's the actual signal here: this isn't a hypothetical failure mode, it's the default one.
- Neither tool fixes a token file that was wrong or stale to begin with. A compliance check against bad tokens just enforces the bad tokens more consistently.
The two problems are the same shape and still separate
Where your tokens come from and whether the agent used them are not the same question, and conflating them is how teams end up with half a solution. Pull the wrong palette from a stale Figma file and a compliance checker will faithfully enforce that wrong palette on every file going forward, just more consistently than a human reviewer would have caught it by hand. Get a clean, current extraction and skip the compliance step, and you're back to hoping the agent reads the file instead of defaulting to its own taste on the one component it generates differently. You need an accurate source before you need an accurate check.
Where the source of truth and the enforcement step currently live, as two separate jobs:
- Preset: 60+ MCP tools for Claude Code, Cursor and Windsurf. validate_generated_code, quick_check_violations and check_drift score generated code against your design system after the fact.
- SuperDuperUI: MCP server, CLI and live preview. check_compliance flags hardcoded colors, bad spacing and unknown tokens as hard errors before the agent calls a component done.
- WAALEE: Extracts your real, live site's colors, type and spacing as W3C tokens and tool-specific prompts, the accurate source these checkers assume you already have.
Where this is heading
The honest read is that neither half of this works alone. A compliance checker needs a token file worth enforcing, and a token file needs something making sure the agent actually used it past the first screen. If you're already running Claude Code, Cursor or Windsurf against a real design system, it's worth asking which half you're missing: do you not actually know your brand's real values yet, or do you know them and just have no way to catch the moment an agent quietly stops using them. Most teams building AI products are going to need both pieces before this problem is actually solved, not just one of them with a confident name on the npm registry.