How to Use Figma's Remote MCP

If you're setting up Figma MCP today, the easiest mistake is starting with the desktop server.

That was the right setup when I wrote about the newly released Figma MCP server last July, but now the better default for designers is the remote setup, usually through Claude Desktop's built-in Figma connector.

The Remote MCP, in addition to pulling design context into code, It also enables the newer read-write workflows: agents can write directly into Figma and bring live browser UI back into Figma for review.

Here, I'll show you how to get it all working.

What changed since Figma MCP's original release

When Figma MCP first showed up, the main value was giving coding agents structured design context. That's still the foundation, but the workflow is no longer one-way.

The two additions that matter most are Write to Canvas and Code to Canvas. Write to Canvas lets agents create and edit real Figma content, while Code to Canvas brings live browser UI back into Figma for review and iteration. That's why remote is now the better default for most designers: it supports the broader design-to-code-to-review loop.

How to connect Claude Desktop to Figma MCP

Lots of designers now use Claude Desktop to work across Figma and code. Start with Claude Desktop's built-in Figma connector if you see it. If you don't, there's still a manual MCP fallback.

If the built-in Figma connector is available in Claude Desktop, use that first. It's the cleanest setup and the happy path most designers should try before touching any local config.

In the Claude chat box, click the plus icon (+).
Go to Connectors → Manage Connectors → Browse Connectors.
Search for Figma and add it.
Claude will open your browser so you can authorize your Figma account.

From here, you should be able to paste a Figma frame or selection link into chat so Claude can pull the relevant design context from that file.

If you don't see the Figma connector, check with your admin before assuming the workflow is broken. In some enterprise-managed Claude setups, connector access is controlled centrally. If it's genuinely unavailable, you can fall back to Figma's official MCP server with a local Claude Desktop config:

macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json

{
  "mcpServers": {
    "figma": {
      "command": "npx",
      "args": ["-y", "@figma/mcp-server-figma"],
      "env": {
        "FIGMA_ACCESS_TOKEN": "your_figma_personal_access_token"
      }
    }
  }
}

Then:

In Figma, go to Settings → Security → Personal access tokens.
Generate a token and paste it into the config.
Restart Claude.

If MCP setup feels like extra overhead for the workflow you actually want, you can skip it and work directly in Builder instead.

Workflow 1: Pull design context into code

What this is: This is the original Figma MCP handoff: you give Claude a Figma frame or selection link, and it pulls structured design context instead of guessing from a screenshot. That context can include variables, layout data, and component structure, which makes the first code pass much closer to the real design.

When to use it: Use this when the design already exists and you want Claude to implement it with less translation work. It's especially useful when a designer wants to hand off one specific frame, section, or component set instead of explaining the whole layout in plain English.

How to do it: If you used the setup above, this is the first workflow to test.

In Figma, right-click the exact frame you want built and choose Copy link.
In Claude Desktop, paste the link with a prompt like this: Use this Figma selection as the source of truth for the pricing page. Build the React version with our existing Card, Button, and Badge components. Match the layout and spacing from the design, use our tokens where possible, and call out anything the current codebase doesn't support cleanly.
Review the generated implementation against the Figma frame and iterate on any drift.

Watch for: You get better implementation context, not perfect accuracy. This workflow gives Claude the design side of the handoff, but it still doesn't automatically understand your codebase, your naming conventions, or how your team composes components in production. Design drift still happens when the agent has to choose between similar components or invent project-specific implementation details.

Workflow 2: Send live UI back into Figma

What this is: If Workflow 1 pulls design context into code, Workflow 2 sends the built UI back into Figma for review. Instead of starting from a Figma frame, you take a real rendered interface from the browser and import it into Figma as editable frames.

When to use it: Use this when the review needs to happen on the shipped or staged UI rather than the mockup.

It's especially useful when:

a staging build looks different from the approved design
a responsive layout feels off in the browser
the team wants to compare what shipped against the original file side by side
a designer wants to annotate implementation drift directly in Figma

How to do it: This works best after you've already implemented a screen and want design review on the real result.

Build or update the UI in Claude Code.
Open the rendered page in the browser at the exact state you want reviewed.
Ask Claude Code to send that live UI back into Figma with a prompt like: Capture this rendered settings page and send it to Figma as editable frames so design can review spacing, hierarchy, and responsive differences against the approved file.
Review and annotate the imported frames in Figma, then use those comments in the next code pass.

If you want the full setup and roundtrip walkthrough, see how to send Claude Code output back into Figma.

Watch for: This is much better for focused review loops than for giant end-to-end handoffs. It gives designers something concrete to react to, but it still adds tool switches: code, browser, Figma, then back into code, and it can be hard to know exactly what the AI changed and where.

Workflow 3: Write directly to the canvas

What this is: This is the newer read-write workflow. Instead of only reading a design, the agent can create and edit real Figma content on the canvas and return editable output with frames, components, variants, variables, and auto layout.

When to use it: Use this when the work belongs in Figma itself and the task is bounded. It works best inside a file that already has context, a design system, and recognizable patterns the agent can follow. Think additions and updates, not "design the whole product from scratch."

How to do it: Start inside the file that already contains the right library and patterns. Then be explicit about the target frame, the components to reuse, and the variables you want applied.

Try prompts like:

"In this settings file, add an empty state for a workspace with no members. Use existing library components, keep the layout in auto layout, and apply existing color and spacing variables instead of hardcoded values."
"Update this account page to add a billing summary card under the current plan section. Match the components already used in this file, convert any raw values to variables, and keep the result editable for the design team."

Watch for: This is useful today, but only when the setup is real. Writing directly to files requires the remote server, a supported client, and the right seat and edit permissions on the target Figma file. If use_figma is missing or failing, the blocker may be file permissions or seat level, not your prompt. It also works much better on narrow asks than on giant one-shot generation requests.

How skills help

Figma MCP gets a lot more repeatable and reliable once you stop relying on one-off prompts and start using skills.

Skills carry your standards across runs, so the agent doesn't have to re-guess them every time: reuse library components, apply variables instead of hardcoded values, follow naming and structure rules, and validate the result before calling it done.

If you want the deeper version, here's my guide on agent skills, rules, and commands. That reusable layer doesn't fix every limitation below, but it does make the workflow less fragile from one prompt to the next.

What still breaks

The main thing that breaks is not one edit—it's treating Figma MCP like a durable workflow instead of a bounded session tool. It works well for asks like: in this file, update this frame using these components and variables. It breaks when teams expect one prompt thread to carry system rules, product intent, implementation details, review, and follow-up changes across the rest of the process.

That's when the agent starts skipping constraints, hardcoding values, or producing work that looks close enough until a designer or engineer has to clean it up. The context lives in the prompt session, not in a durable system the whole team can keep working from. Once the work has to survive code review, QA, and another round of feedback, the session starts to run out of room.

Where Builder fits

Builder isn't a replacement for Figma MCP. Figma MCP is the right layer for pulling design context, writing to the canvas, and sending live UI back into Figma. Builder fits when that bounded session needs to turn into durable product work: shared context in the real codebase, structured review, and a path to shipping.

That's the real split: Figma MCP helps with the design interaction itself, while Builder helps the team keep that work moving after the interaction ends. Once changes need to survive review, iteration, QA, and shipping, the bottleneck is no longer generating a first pass. It's preserving context across the real workflow. That's where Builder is stronger: the work stays visible, reviewable, and connected to what actually ships.

If you want the next step after the MCP session — turning approved design work into something live — this walkthrough on turning a Figma landing page into a live website shows that Builder workflow in practice.

When to use Figma MCP vs Builder

Remote Figma MCP is the right default when the task is bounded and high-context: pull a frame into code, send live UI back into Figma for review, or make a focused canvas edit without relying on screenshots and guesswork.

But it's still a session tool, not the whole workflow. Once the work has to persist across review, iteration, QA, and shipping, Builder becomes the better system.

So the practical default in 2026 is simple: use remote Figma MCP for the in-the-moment design/code loop, and use Builder when that work needs to persist, collaborate, and ship.