Token linting helps keep your code in line with your design system. It checks the style values in your code, such as colours, spacing, radii and durations, against the design tokens in zeroheight, and suggests the right token for each one.

You can ask your coding agent to lint code that already exists, or the agent can check its own code as it writes it. Either way, the agent swaps in tokens only where it's safe, and asks you about everything else.

Learn more about using the remote MCP and the MCP tools.

Before you start

Token linting uses the published version of your token sets. To set it up:

1. Create a token set in zeroheight from your tokens source of truth, such as Figma variables or a tokens file, and publish it.
2. Go to Styleguide settings > Token sets and link the token set to your styleguide. Admins and editors can link sets.

Which token sets the agent can use

This depends on how you connect to the MCP:

If more than one set is available, the agent asks you which to use. You can also name the set in your prompt.

Lint your code

Ask your coding agent to check a file against your tokens, for example:

• "Lint src/components/Card.css using zeroheight. Swap in tokens where it's safe and list anything you're unsure about."
• "Which tokens match the hardcoded colours in this file in Dark mode? Don't change anything."
• "Build a pricing card component styled with our zeroheight design tokens."

Here's what happens:

1. The agent finds the available token sets with list-token-sets. If there's more than one, it asks you which to use.
2. It collects every style value from the code: hardcoded values like #0055FF or 16px, and token references like var(--color-primary) or $space-16.
3. It sends them to zeroheight in one suggest-tokens call. zeroheight compares each value with the tokens in the set and returns the closest matches.
4. The agent swaps in the tokens that are safe to swap, and gives you a list of everything else with its reasoning.

When the agent swaps a token, and when it asks

The agent only swaps a value automatically when the change can't alter how anything looks. That means:

• the token has exactly the same value,
• in every mode (for example both Light and Dark),
• it's a semantic token, such as color.primary, not a raw scale value such as color.blue.500,
• and there's no other sensible choice.

For everything else, it asks you first. For example:

What can be checked

• Colours: hex, rgb()/rgba() and named colours such as white. Colours are compared by how similar they look, and transparency is compared separately.
• Dimensions: such as 16px or 1rem. Units aren't converted, so 1rem only matches rem tokens. Number tokens from Figma variables have no unit, so they're treated as px.
• Durations: such as 200ms or 0.2s. Seconds and milliseconds are compared.
• Numbers: such as an opacity of 0.5.
• Token references: in whatever form your code uses, for example var(--color-bg), $color-bg, {color.bg} or theme.color.bg.

The agent splits shorthand values (like padding: 8px 16px or a box-shadow) into their parts. It can check up to 100 values in one call. Functions such as darken() and text values such as font family names can't be checked, so they're left as they are.

Tips

• Check the token names in your code. zeroheight knows a token's name, such as color.primary, but not how your code refers to it. The agent follows the pattern already in your file (for example var(--color-primary) or theme.color.primary) and tells you when it's guessing.
• Add token descriptions in zeroheight. Descriptions like "Only for text" help the agent spot tokens used in the wrong place.
• Fill gaps in your token set. If a set has no typography, border or motion tokens, those values stay hardcoded. The agent points out these gaps.
• Name the mode if you only care about one. For example, "check against Dark mode only".