Figma to a coding agent: what the MCP server actually sends

The first thing to internalise about Figma's MCP server is the unit of transfer. It is not the document. You select a frame or a component in Figma, and the agent receives a structured description of that selection — the node hierarchy, the component tree, the values of any variables bound to properties, and any Code Connect mappings that link a Figma component to a component in your codebase.

This is a much better payload than a screenshot, and it changes what you should ask for. The agent is not looking at a picture and guessing at structure; it has the structure. What it does not have is the rest of the file, the rest of the product, or any account of why the design is the way it is. This post covers the mechanics; the wider picture is in how to export a UI design to a coding agent.

Figma runs two servers. The remote one at mcp.figma.com is the recommended route and needs no local app running. The desktop one runs locally out of the Figma desktop app and is useful when you want the agent reading whatever is selected on screen right now. Enable the desktop server from Dev Mode in the Figma desktop app — toggle Dev Mode in the bottom toolbar, then enable the MCP server in the inspect panel — before any client can reach it.

# Remote server (recommended)
claude mcp add --transport http figma https://mcp.figma.com/mcp

# Or the local desktop server, with Figma desktop running in Dev Mode
claude mcp add --transport http figma-desktop http://127.0.0.1:3845/mcp

Restart Claude Code so it picks up the change, then run /mcp to confirm the server is listed and connected. Once it is, add a line to CLAUDE.md saying the Figma server is available and that designs arrive as selections — otherwise every new session starts by rediscovering it.

Cursor reads MCP configuration from a file at the repository root, which means committing it hands the same design route to everyone who clones the repo.

{
  "mcpServers": {
    "figma": {
      "type": "http",
      "url": "https://mcp.figma.com/mcp"
    }
  }
}

Pair it with a rule file under .cursor/rules scoped by glob to your component directories. Figma knows nothing about your local components unless Code Connect tells it, so the rule is where you say "reuse what is in src/components/ui before creating anything new".

codex mcp add figma --url https://mcp.figma.com/mcp

That writes to ~/.codex/config.toml under an [mcp_servers.figma] block. Note the path: it is user-level, so it does not travel with the repository and every teammate configures it themselves. Replit is the opposite — configuration goes in .replit and travels with the project, but the token belongs in Replit Secrets rather than the file.

Lovable is the exception, and it is worth knowing before you plan a workflow around it. Figma's server only accepts connections from clients in its own catalogue, and Lovable is not in it. The route there is the Builder.io plugin: export the frame from Figma with the plugin, then open the result in Lovable. That is a one-time conversion rather than a live connection — later changes in Figma do not propagate — and Auto Layout stops being best practice and becomes load-bearing, because it is what the conversion uses to infer structure.

Code Connect is the strongest lever available on the Figma side. It maps a Figma component to the real component in your codebase, so the agent writes <Button variant="primary"> instead of reconstructing a button out of divs and padding. Where it is configured, output quality rises sharply.

The limit is exactly the mapping. Anything outside a mapped component is regenerated from scratch — layout wrappers, one-off sections, anything designed last week and not yet connected. A file with fifteen mapped components and a hand-built marketing section will produce excellent code for fifteen things and invented code for the section.

Here is the failure that survives a well-built file, bound variables and configured Code Connect. The generated screen has hard-coded colours where you have tokens, typography that is close to yours but overridden by a few pixels, and hand-written CSS where a utility existed. Nothing is badly wrong. Everything is slightly wrong.

The reason is that the server describes what exists, not what is intentional. A variable bound to a fill and a colour someone typed in by hand during a rush both arrive as a colour on a node. The agent has no way to tell a design token from an incidental value, so it treats them identically — and reproduces both faithfully, including the mistake.

The other half of the problem shows up the moment you ask for a screen that is not in the file. There is no selection to send. The agent falls back on inference, and inference produces a plausible screen belonging to a slightly different product.

Selection scope is a context budget decision. Selecting a whole page sends a large structured description that consumes the window before a line of code is written, and the agent ends up working from a compressed impression rather than a precise reading. One frame per request, confirmed before moving on, is both more accurate and — because the failure mode is a small correction rather than a rebuild — faster in practice.

Generate a screen from a Figma selection. Then ask for one that does not exist in the file — a settings page, a 404, an empty state. If the second screen is visibly a different product, the handoff moved your design and not your design system. That is not a Figma configuration problem and no amount of Code Connect will fix it; the missing piece is a set of rules the agent can read that are true across every screen, including the ones nobody has drawn yet. That argument is laid out in why your agent never got the rules.