Figma MCP to React: A Worked Design-to-Code Workflow

To implement a Figma component with AI, provide the component's node link, retrieve its design context and screenshot, map its values to existing code tokens, then verify the rendered result. Supplying context is only the beginning: the output still needs code and visual review.

This guide uses an illustrative Save button, with invented design values listed explicitly below. It is a reproducible implementation exercise, not a claim that we ran a live Figma session or measured an accuracy improvement.

Prerequisites

Use a React project you can run locally, a Figma file you can access, and an MCP client connected to Figma. Follow Figma's current installation instructions for connection and authentication. Client availability and access limits can change; keep that setup step tied to the official instructions.

Before asking for code, locate your existing button component, token definitions, and any component mappings. Figma documents Code Connect integration for connecting design components to implementations. Prefer reuse when a suitable component already exists.

Define the example and map its tokens

For this exercise, the design contains a primary Save button with these requirements:

| Design property | Example value | Code token or behaviour | |---|---|---| | Primary fill | #1d4ed8 | --action-primary | | Text | White, 16px | --on-action, inherited font | | Horizontal padding | 16px | --space-4 | | Vertical padding | 8px | --space-2 | | Corner radius | 8px | --radius-control | | Label | Save | Button children | | Disabled variant | Cannot submit | Native disabled attribute |

The token names are illustrative. In your project, record the mapping to the actual existing tokens. Similar hex values do not prove two tokens have the same semantic role.

Retrieve context before generating code

Give the agent the node URL and ask it to retrieve both structured design context and a screenshot. Figma's tools documentation describes these capabilities. Use the context to inspect values and component mappings, then the screenshot to check the intended appearance.

A reusable prompt:

Implement the component at [Figma node URL] in [existing React project].
First retrieve its design context and screenshot. Inspect our existing button
and token definitions. List the design-to-code mappings and any missing states.
Reuse the existing component if it can express this design.
Keep native button semantics, keyboard focus, and disabled behaviour.
Implement only the agreed variant. Do not change global tokens to match one node.
Run the component checks and compare the rendered result with the screenshot.
Report mismatches and assumptions rather than claiming pixel-perfect output.

Download this handoff prompt.

Implement the smallest component

If your project does not already have a suitable button, this example preserves native attributes and defaults to a non-submitting button. A form can explicitly request type="submit".

import type { ComponentPropsWithoutRef } from "react";
import "./SaveButton.css";
 
type SaveButtonProps = ComponentPropsWithoutRef<"button">;
 
export function SaveButton({
  children = "Save",
  type = "button",
  className = "",
  ...props
}: SaveButtonProps) {
  return <button {...props} type={type} className={`save-button ${className}`}>
    {children}
  </button>;
}

.save-button {
  --action-primary: #1d4ed8;
  --on-action: #fff;
  --space-4: 16px;
  --space-2: 8px;
  --radius-control: 8px;
  background: var(--action-primary);
  color: var(--on-action);
  padding: var(--space-2) var(--space-4);
  border: 0;
  border-radius: var(--radius-control);
  font: inherit;
  font-size: 16px;
  cursor: pointer;
}
.save-button:focus-visible {
  outline: 2px solid var(--action-primary);
  outline-offset: 3px;
}
.save-button:disabled {
  opacity: 0.5;
  cursor: not-allowed;
}

These local token declarations make the snippet self-contained. In production, use your established token values rather than introducing a second token system. The focus and disabled treatments are explicit assumptions for this exercise; confirm the actual design states before shipping.

Verify the result in the browser

Render enabled, disabled, and long-label examples side by side. Confirm the computed padding, radius, typography, and colours against the mapping table. Compare with the source screenshot at the same scale.

Use Tab to focus the enabled button and Space or Enter to activate it. Confirm that the disabled button cannot activate. Inside a form, verify that the default button does not submit and an explicit submit button does. Check narrow widths and text zoom for clipping.

These checks demonstrate what needs verification; a live Figma comparison has not been performed for this illustrative example. For systematic variant coverage, continue with Design Token to Storybook.

Common failure cases

• The node cannot be read: confirm access to the file and the exact node link before generating a substitute from memory.
• The agent guesses token names: provide the code token definitions and approve the mapping before implementation.
• A duplicate component appears: point to the existing component and its supported variants; adapt it only when the design requires it.
• The screenshot matches but behaviour fails: check semantics, focus, disabled state, and form submission separately.
• A large frame produces incomplete context: isolate the component you need and fetch its context again.

For the reverse direction, read Code to Canvas. For the whole feedback loop, read Design to Code and Back.