·

Multi-MCP Figma GitHub Workflow

Follow an AI agent as it reads a Figma design through MCP and opens a matching pull request on GitHub, closing the design-to-code gap.

The gap between "here's the Figma frame" and "here's the merged component" is where design handoff traditionally loses fidelity — spacing gets eyeballed, a token gets hardcoded instead of referenced, a variant the designer specified gets missed because nobody scrolled the frame far enough. Figma's Dev Mode MCP server closes part of that gap by giving the agent structured access to the actual frame — layout, tokens, component structure — instead of a screenshot it has to guess dimensions from. Combined with GitHub MCP, the same session that reads the design can also open the branch, commit the component, and get it in front of reviewers.

Assume Figma's desktop app running with Dev Mode MCP server enabled (http://127.0.0.1:3845/mcp), github-mcp-server connected (GITHUB_TOOLSETS=repos,pull_requests), and a design file with a frame someone has handed off for implementation.

Workflow Overview: Figma Frame to Production-Ready Component via AI

The full arc:

  1. Design context extraction — pull the frame's structure, spacing, and token references directly from Figma, not from a screenshot.
  2. Component generation — turn that structured context into code that matches your project's existing component conventions, using real design tokens rather than hardcoded values copied off a color picker.
  3. Branch and commit — push the generated component to a feature branch via GitHub MCP.
  4. PR and design review — open a PR that includes a visual reference back to the Figma frame, so a design reviewer can compare implementation against source without switching context.

The part worth being honest about upfront: Dev Mode MCP gives you far better structural fidelity than a screenshot-based workflow, but it does not eliminate the need for a human designer to look at the rendered result. Figma's server tells the agent what the design says; it doesn't verify the agent's code renders it correctly. That verification step stays in this workflow deliberately.

claude mcp list

Tips
- Treat Figma MCP's output as structured design intent, not a guarantee of pixel-perfect output — the agent still has to translate tokens and layout into your specific component library's idioms, and that translation step is where mismatches creep in.
- Confirm Dev Mode is actually running in the Figma desktop app before starting — the local MCP server only serves while the app is open with a file active, unlike the other servers in this course which run independently of any desktop application.
- Keep the design review step (Step 3) a real, human-in-the-loop check — the fastest way to erode a design team's trust in this workflow is to skip straight to merge on a component nobody with design context has actually looked at.

Step 1: Extracting Design Context and Tokens from Figma with MCP

Select the frame in Figma's desktop app first — Dev Mode MCP's context-extraction tools generally operate against the current selection, not an arbitrary node ID you'd have to hunt for separately:

> get the design context for the currently selected frame in Figma.
  Include layout structure, spacing values, color and typography tokens,
  and any component instances it references.

A realistic structured result:

{
  "frame": "ExportButton / Default",
  "layout": {
    "direction": "horizontal",
    "padding": [12, 20, 12, 20],
    "gap": 8,
    "alignment": "center"
  },
  "tokens": {
    "background": "color/surface/primary",
    "text": "color/text/on-primary",
    "radius": "radius/md",
    "font": "typography/label/medium"
  },
  "variants": ["Default", "Hover", "Disabled", "Loading"],
  "instances": ["Icon/Download"]
}

The token references (color/surface/primary, not a hex value) are the detail that makes this workflow worth doing over a screenshot-based approach. A screenshot tells the agent "this button is blue" — Figma MCP tells it which design token produced that blue, which is what should end up in the generated code if your project already has a token system wired up.

> does color/surface/primary and radius/md already exist in our
  codebase's token file (src/styles/tokens.ts)? If yes, reference
  them by name. If any token is missing, flag it — don't invent
  a value.

color/surface/primary → exists, maps to --color-surface-primary
radius/md → exists, maps to --radius-md
typography/label/medium → NOT FOUND in tokens.ts — flagging for
  designer/engineer follow-up before generating code that depends on it

This check matters more than it looks: generating a component against a token that doesn't exist yet in your codebase produces code that either silently falls back to a wrong default or breaks at build time — better to surface the gap now than debug it after the PR is open.

Tips
- Always select the frame in the Figma desktop app before requesting context — Dev Mode MCP's extraction tools work off the current selection, and an ambiguous or missing selection produces an ambiguous or missing result.
- Cross-check every token the design references against your actual codebase token file before generating code — a token name that exists in Figma but not in your source is a handoff gap worth surfacing explicitly, not papering over with an invented value.
- Pull the full variant list (Default, Hover, Disabled, Loading) up front — generating code from just the default state and bolting on other variants later tends to produce a component whose states don't share structure cleanly.

Step 2: Generating Component Code and Pushing to a GitHub Branch

With verified tokens in hand, generate the component against your project's existing conventions — point the agent at an existing similar component so it matches your patterns instead of inventing its own:

> generate a React component ExportButton.tsx matching the Figma frame
  context above. Follow the same structure as src/components/Button.tsx
  (existing component in this repo) for props, styling approach, and
  file layout. Include all four variants as a `state` prop.
  Don't write the file yet — show me the code first.

type ExportButtonState = "default" | "hover" | "disabled" | "loading";

interface ExportButtonProps {
  state?: ExportButtonState;
  onClick?: () => void;
  children: React.ReactNode;
}

export function ExportButton({
  state = "default",
  onClick,
  children,
}: ExportButtonProps) {
  return (
    <button
      className={`export-button export-button--${state}`}
      disabled={state === "disabled" || state === "loading"}
      onClick={onClick}
    >
      {state === "loading" ? <Spinner /> : <DownloadIcon />}
      {children}
    </button>
  );
}

Review the generated code against the actual token mapping before it touches disk — this is the checkpoint where a mismatched spacing value or a hardcoded color that should have been a token reference gets caught cheaply:

> write the file, plus a matching .module.css using the token
  variables we confirmed exist (--color-surface-primary, --radius-md).
  Also create a branch feature/export-button-component off main
  in acme/webapp and commit both files there.

Claude Code calls create_branch (GitHub) followed by create_or_update_file for each new file. Confirm what actually landed rather than trusting the summary:

> show me the diff of what was just committed to feature/export-button-component

Tips
- Point the generator at a real existing component in your codebase as a style reference — a component generated in isolation tends to drift from your project's actual prop-naming and file-layout conventions, even when the visual output looks right.
- Review generated code against the confirmed token mapping before committing, not after — catching a hardcoded value that should be a token reference is far cheaper before the commit than after a reviewer flags it.
- Diff the actual commit after pushing, not just the code shown in chat — a create_or_update_file call using stale content (if the model re-generates between showing you code and committing) is a real failure mode worth a five-second check.

Step 3: Opening a PR and Requesting a Design Review from Figma Stakeholders

Open the PR with a visual anchor back to the source frame — a design reviewer shouldn't have to go searching Figma for what this PR is supposed to match:

> open a PR from feature/export-button-component into main.
  Title: "Add ExportButton component (Figma: ExportButton/Default)".
  Body should include a link to the Figma frame, the four variants
  implemented, and a note on which tokens were used.

## Summary
Implements the ExportButton component per Figma frame
"ExportButton / Default" — all four variants (Default, Hover,
Disabled, Loading).

## Figma Reference
https://www.figma.com/file/abc123/Design-System?node-id=42:108

## Tokens Used
- color/surface/primary → --color-surface-primary
- radius/md → --radius-md

## Note
typography/label/medium was not found in tokens.ts at generation time —
using --font-label-fallback pending design system update. Flagging for
review.

That last note is exactly the kind of honest limitation you want surfaced in the PR rather than silently absorbed — a reviewer who knows a fallback was used can make an informed call, one who doesn't will assume the token mapping was clean when it wasn't.

Since a design reviewer's context lives in Figma, close the loop there too rather than expecting them to review from a GitHub diff alone:

> add a comment on the Figma frame linking to the new PR,
  so the designer can review the implementation against the source

Comment added to "ExportButton / Default":
"Implementation PR: https://github.com/acme/webapp/pull/224 —
flagging that typography/label/medium wasn't found in our token file,
using a fallback for now."

Tips
- Link the PR back to the exact Figma frame (with node-id), not just the file — a design reviewer working across a file with dozens of frames shouldn't have to hunt for which one this PR implements.
- Surface any token or fidelity gap explicitly in the PR body rather than silently working around it — a fallback value used without disclosure is the kind of small compromise that erodes design-engineering trust over several PRs, even when each individual instance is minor.
- Close the loop with a comment on the Figma frame itself, not only a GitHub PR description — the designer's workflow lives in Figma, and expecting them to monitor GitHub notifications for design review requests is how reviews get missed.

Tips

Tips
- Use Figma MCP's structured token and layout output as ground truth for what the design specifies, and verify every referenced token actually exists in your codebase before generating code against it.
- Generate components against an existing in-repo component as a style reference, review the diff against confirmed tokens before committing, and diff the real commit afterward rather than trusting the chat transcript's account of it.
- Close the design-to-code loop in both directions — link the PR to the exact Figma frame, and post the PR link back as a Figma comment — and disclose any fidelity gap (missing token, fallback value) explicitly instead of letting it pass unnoticed.

Next Multi-MCP Sentry GitHub Workflow