Screenshots. Descriptions. Figma links. MCP connections that give the agent direct file access.

Same result every time. Layout approximately right. Spacing close. Colors in the ballpark. But tokens hardcoded as hex values. Padding as magic numbers. A component that works visually but sits completely outside the design system.

I kept blaming the model. The model was never the problem.

What’s actually happening:

When you share a screenshot: The agent is doing visual inference. 
Intelligent guessing.

When you write a description: You’re doing the translation manually, losing fidelity at every step.

**When you connect via MCP, and this is the one that surprises people:
**Your agent gets the raw Figma node tree. Layer names, positions, properties. But token names would be missing and agent would read hexacode value. Layout intent isn’t surfaced cleanly with details. The agent reads raw JSON and guesses.

What it means technically:

When Figma exposes a node via MCP or the REST API, the data looks something like this:

{
  "name": "Button",
  "fills": [
    {
      "type": "SOLID",
      "color": { "r": 0.404, "g": 0.314, "b": 0.643 },
      "boundVariables": {
        "color": {
          "type": "VARIABLE_ALIAS",
          "id": "VariableID:123:456"
        }
      }
    }
  ]
}

Notice what’s missing

The token name color/background/primary isn't in this object. What's there is a variable ID. A reference pointer like VariableID:123:456. To get the actual token name, agent have to make a second API call to resolve that ID against the file's variable collection.

An AI agent reading this raw JSON sees:

• A fill color: r: 0.404, g: 0.314, b: 0.643 converts to #6750A4

• A variable reference ID doesn’t automatically resolve

So it uses the hex value. Because that’s what is immediately readable.

MCP gives your agent access to the file. Not understanding of the design. The gap isn’t the model. It’s the input format.

What the agent actually needs:

Not a screenshot. Not a description. Not a raw node tree.

A structured, semantic spec file. Where every piece of information the agent needs is explicit, labelled, and machine-readable.

Here’s what that looks like in practice. This is the component.rules.md FigSpecs generates directly from a Figma component:

## Component Structure
> Hierarchical layout annotation

### Button  `91 × 40px`

- **Content** (flex row) · justify-center · items-center
  · gap 8px · padding 10px 16px · rounded 20px · `fill × fixed`
  - **Icon** (icon) · `20 × 20px`
    · tokens: color/icon/on-primary
  - **Label** (text) · 14px SemiBold
    · color: color/text/on-primary

## Design Tokens
- `color/background/primary`
- `color/text/on-primary`
- `color/icon/on-primary`

## Accessibility Requirements
- [ ] Touch target 44×44px minimum
- [ ] aria-label="Button" · role="button"
- [ ] VoiceOver: "Button, button"

Notice what's here:

Token paths, not hex values. color/background/primary carries semantic meaning. #6750A4 carries none. Your agent can't know if that hex is a brand color, a state, or a one-off. The token name tells it exactly what the value represents.

1. Layout intent, not coordinates. flex row · justify-center · items-center · gap 8px is implementable. A screenshot of a button is a puzzle.

2. Sizing mode. Whether a layer is fixed, hug, or fill changes how a component behaves in a real layout. A screenshot only shows the static result.

3. Accessibility baked in. ARIA roles, Voiceover announcements, touch targets - your agent implements these correctly by default instead of skipping them entirely. Drop this file into your Cursor, Claude Code, Lovable, or v0 session. The first-pass component quality changes immediately 🏆.

Plus a Tailwind v4 @theme {} block

This is for building the component — the actual CSS variables ready to use in code. It answers “what values do I use?” Your developer drops this into the project and starts executing.

@theme {
  /* Colors & Tokens */
  --color-background-primary:     /* resolve: color/background/primary */;
  --color-text-on-primary:        #FFFFFF;
  --color-icon-on-primary:        #FFFFFF;

  /* Spacing */
  --spacing-button-content-py:    10px;
  --spacing-button-content-px:    16px;
  --spacing-button-content-gap:   8px;

  /* Border Radius */
  --radius-button-content:        20px;

  /* Typography */
  --text-button-label:            14px;
  --font-weight-button-label:     600;
}

👋Quick context:

component.rules.md is the blueprint — it tells agent what to build & why.

tailwind-v4.css is the materials list — it gives the developer the exact values to build with.

One without the other leaves a gap. The blueprint without materials still requires manual value lookup. The materials without the blueprint gives you values with no context on how to use them.

Together they give your AI agent everything it needs to go from Figma component to working code in one pass.

The bottleneck was never the model

We’d been treating the AI as the problem. The actual bottleneck was upstream at the point where design information gets converted into something an agent can reason about.

The data exists in Figma. Tokens are a solved problem. The gap is the pipeline between them.

I used FigSpecs — A figma plugin that helped me create component.rules.md & Tailwind v4.css files that acted as pipeline giving AI Agent a better context.

If you prefer to try out: Here’s link.

Q: Using MCP or AI-assisted workflows for component development? 
What’s your current input format? Have you found something that gets token fidelity right on the first pass? or what do you think about my approach? 
Curious to know 🤞