How to use Figma MCP with Claude Code

To use Figma MCP with Claude Code, install Figma’s plugin (or add the remote server at https://mcp.figma.com/mcp), sign in once, then paste a link to a frame or layer into your prompt. Claude Code calls Figma’s tools to read that selection’s structure, variables and a screenshot, and uses them to write code. The quality of the result depends mostly on two things: how well the Figma file is structured, and how clearly you tell Claude to use your existing components.

This is a practical walkthrough of that loop. For how MCP works in general, see what MCP is for designers.

Connect the Figma MCP server

Figma recommends its remote server for most people. It connects directly to Figma, so the desktop app isn’t required. The installation guide gives two routes for Claude Code.

Option 1: the plugin (recommended)

The plugin bundles the MCP server with Figma’s skills. Install it from your terminal:

claude plugin install figma@claude-plugins-official

Restart Claude Code if it was running, type /plugin, open the Installed tab, select the figma server and sign in. A browser page opens; click Allow access.

Option 2: add the server manually

claude mcp add --transport http figma https://mcp.figma.com/mcp

# or, to make it available in every project
claude mcp add --scope user --transport http figma https://mcp.figma.com/mcp

Start a new session, run /mcp, select figma, choose Authenticate and allow access in the browser. The manual route doesn’t include Figma’s skills.

What you can do depends on your Figma plan and seat. Figma documents those limits, including rate limits on read tools, on its plans and access pages, so check them before you rely on the server for a large job.

Point Claude at a selection, not a file

Design context is link-based. In Figma, right-click a frame or layer, choose Copy link to selection, and paste the link into your prompt. Claude Code doesn’t open the link; it reads the node ID from it and asks the server for that node.

Select deliberately. Figma’s own guidance is to work in smaller pieces: “Generate code for smaller sections or individual components, like a card, header, or sidebar.” A whole page at once can be slow, error-prone or incomplete.

The tools you’ll actually use

Figma’s server exposes many tools. For design-to-code work, a handful do most of the work. The names below are from Figma’s tools reference:

• get_metadata: a lightweight XML outline (layer IDs, names, types, positions and sizes). Use it first on large designs to find the parts you need.
• get_design_context: the main design-to-code tool. Returns design context and generated code for a layer or selection.
• get_variable_defs: the variables and styles used in a selection. This is how tokens reach your code instead of raw values.
• get_screenshot: an image of the selection, so Claude can see the design. Useful, but heavier on tokens.
• get_code_connect_map: Code Connect mappings between Figma components and your code components, where your team has set them up.
• download_assets: rendered exports and source images for up to 20 nodes per call.

You rarely need to name tools. Describe the job and Claude chooses. Naming one is useful when you want a specific behaviour, such as “outline the page with get_metadata first”.

Prepare the Figma file

The MCP server can only pass on the structure that’s in the file. Figma’s guide to structuring files for better code recommends:

• Components for anything that repeats: buttons, cards, inputs, nav items.
• Variables for colour, spacing, radius and typography, so the agent references tokens.
• Descriptive layer names instead of “Frame 427”.
• Auto layout, so resizing behaviour is explicit rather than absolute positioning.
• Annotations for behaviour that a static frame can’t show.
• Code Connect, which Figma describes as the most effective way to get your real components used.

If your file uses hard-coded colours and loose groups, fix the frames you’re about to build first. It’s faster than correcting the code afterwards.

A prompt that produces code you can keep

Figma’s prompting guide recommends briefing the agent like a teammate: name the framework, where the code goes, and which components to reuse. Combined with a request to check the result, that looks like this:

Implement this Figma frame as the account settings page:
https://www.figma.com/design/<file>/<name>?node-id=<id>

- Stack: Next.js App Router, Tailwind, our components in
  src/components/ui. Reuse them; don't create new primitives.
- Put the page in app/(app)/settings/account/page.tsx.
- Map Figma variables to our tokens in app/globals.css. If a
  variable has no matching token, list it instead of hard-coding it.
- Use get_metadata first, then get design context only for the
  header, the form and the danger zone section.
- When it builds, open localhost:3000/settings/account, screenshot
  it at 1440px and compare it with the Figma screenshot. List the
  differences before fixing them.

The instruction to list unmatched variables matters. It turns a silent drift (a new hex value in a component) into a visible decision you make.

Common design-to-code mistakes

• Treating generated code as final. The code from get_design_context is a starting point shaped by the design. Ask Claude to adapt it to your components and conventions rather than paste it in.
• Pixel values instead of tokens. If spacing comes through as 23px, the frame probably isn’t using variables or auto layout. Fix the source or map it to the nearest token on purpose. Our guide to design tokens for AI coding agents covers that mapping.
• Copying desktop layout to every width. A single desktop frame says nothing about mobile. Provide a mobile frame or state the responsive behaviour. See making AI-generated UI responsive.
• Missing states. Figma frames often show the populated happy path. Name the empty, loading and error states you need.
• Selecting too much. Large selections stall or truncate. Outline with get_metadata, then build section by section.

Review against the design, then against the product

Two separate checks are worth doing. First, fidelity: does the build match the frame at the widths that matter? A browser screenshot compared with get_screenshot answers that, and visual testing with Playwright makes it repeatable. Second, fit: does it use your components, tokens and patterns, and does it hold up with real content? Fidelity to a frame doesn’t guarantee either.

Where Figma context stops

Figma MCP describes a specific design very precisely. It doesn’t carry the reasons behind it: the principles, the references the designer had in mind, or how the next screen should feel when nobody has drawn it yet. That gap shows when an agent extends a product beyond the frames it was given. We explain how MCP connects that kind of design context in a separate guide.

It’s also the part Attuna is being built for. In Attuna, which is in development, each project holds a brief, a creative direction, project rules and references, and your agent can read them over MCP alongside the Figma server.