Integrating Figma with Claude: Code Connect, the Figma MCP server, and the design-to-code flow
Design specs used to travel from Figma to code as screenshots and guesswork. Now there's a structured pipe — Figma's MCP server plus Code Connect — that lets an AI agent read a design as data instead of as a picture. Here's what that actually means, and where it still falls short.
1. The gap this closes: screenshots vs. structured design data
Before this kind of integration existed, "AI-assisted design-to-code" mostly meant one thing: paste a screenshot of a Figma frame into a chat and ask a model to recreate it in code. That works up to a point, but the model is guessing — it infers spacing, color values, and component boundaries from pixels, the same way a human would eyeballing a mockup. Small inconsistencies (an 8px vs 10px gap, a slightly-off shade of gray) get baked in because the model never had access to the actual underlying values.
A Figma MCP (Model Context Protocol) server changes that by giving the agent structured access to the file itself — layout data, variables, styles, component metadata — instead of forcing it to reverse-engineer that information from an image. It's the difference between describing a house from a photo and being handed the blueprint.
2. What the Figma MCP server actually exposes
MCP itself is a general standard (covered in a previous IA Watch lesson) for letting an AI application talk to external systems through a common protocol, instead of everything being pasted into a prompt by hand. Figma ships an MCP server that speaks this protocol specifically for design files. Once connected, an agent like Claude can call tools that return:
Design context — the layout, sizing, and structure of a selected frame or node, translated into something closer to code (positions, auto-layout rules, constraints) instead of raw pixels.
Variables and styles — the design tokens behind the file: color variables, spacing scales, typography styles — the same values a design system would define.
Metadata — component names, instance relationships, which node is a variant of which component.
Screenshots — still available as a fallback/visual check, but now paired with the structured data rather than being the only source of truth.
Code Connect mappings — the piece that turns "this is a button-shaped rectangle" into "this is literally your <Button /> component" (more on this below).
Why this matters: an agent that can read variables and constraints directly produces code that references your actual design tokens (var(--spacing-4), a theme color) instead of hardcoding whatever value it guessed from a screenshot — which is exactly the kind of drift that makes a codebase's CSS harder to maintain over time.
3. Code Connect: telling the agent which real component to use
Structured layout data alone still leaves a gap: the MCP server can tell an agent "this is a component called Button, in the state 'primary/large'" — but it doesn't automatically know that your codebase already has a Button component at src/components/Button.tsx with a variant and size prop. Without that link, the agent would just generate a new, disconnected chunk of HTML/CSS that happens to look like your button.
Code Connect closes that gap. It's a small template file (.figma.tsx/.figma.js, or the equivalent for other stacks) that explicitly maps a Figma component to the real code component and its props. Once that mapping exists for a piece of your design system, the MCP server can hand the agent the actual import statement and prop values to use — not a re-implementation, but a reference to the component that already exists and is already tested, themed, and accessible.
Without Code Connect
With Code Connect
Agent infers a button from shape, color, and text — writes new markup/CSS from scratch.
Agent is told: this node maps to <Button variant="primary" size="lg"> from your own component library.
Output drifts from your design system over time — every generation is a fresh guess.
Output stays consistent with your design system because it reuses the same components everywhere.
Works reasonably for one-off landing pages with no existing component library.
Pays off specifically when there's a real design system on both sides (Figma library + code component library) to connect.
4. The end-to-end workflow, step by step
Set up the MCP server. Typically via the Figma desktop app (the browser version doesn't support the desktop MCP server) or a plugin that exposes MCP server settings alongside the relevant agent skills.
Connect the agent (Claude Code, Cowork, or another MCP-aware client) to that server as an MCP tool source.
Select a frame or component in Figma — this becomes the scope the agent will read from.
The agent requests design context — layout, variables, and (if configured) Code Connect mappings for that selection.
Write or update Code Connect files for the components in your library that don't have a mapping yet, so future runs resolve to real components instead of guesses.
The agent generates code that uses your actual tokens and components where mappings exist, and reasonable approximations where they don't.
Review like any other AI-generated diff — this shortens the trip from design to a rough implementation, it doesn't remove the need for a human check on the result.
5. It goes both ways: code-to-design too
The same bridge works in reverse. An agent can take an existing page or component built in code and push it into Figma as native, editable nodes — using the same design tokens and library components rather than a flattened image. This is useful when code was written first (a quick prototype, an internal tool) and a designer now needs an editable Figma version to iterate on, or when a team wants Figma to stay in sync with what's actually shipped rather than drifting into its own stale version of the truth.
6. Pros, cons, and where it breaks down
Pros
Generated code references real design tokens and real components instead of reinventing them per generation.
Cuts a lot of the manual "eyeball the Figma frame and translate spacing by hand" work in the handoff.
Bidirectional — keeps design and code from drifting apart in either direction if used consistently.
Cons / limits
The payoff is proportional to how mature your design system already is. A messy, inconsistent Figma file with no shared components produces messy, inconsistent output — the tool amplifies what's already there, in either direction.
Code Connect mappings have to be written and maintained by someone; they don't appear automatically the first time.
Running more than one MCP server that touches the same Figma data at once tends to confuse the agent and produce inconsistent results — pick one integration path per project.
It still requires review. Structured data reduces guessing, but doesn't guarantee the generated code matches your actual conventions, accessibility requirements, or performance constraints.
7. How this compares to other design-to-code approaches
Approach
What it's good for
Main weakness
Screenshot-to-code (no MCP)
Fast, zero setup — paste an image, get a rough draft.
Model is guessing at every value; drifts from your real design tokens and components.
Figma MCP + Code Connect
Precise reuse of existing tokens/components; scales well once set up.
Setup and maintenance cost; only pays off with an organized design system.
Manual developer handoff (specs, redlines, a designer writing notes)
Full human judgment on every detail; no tooling dependency.
Slow, repetitive, and exactly the kind of work that scales badly across many screens.
Design token pipelines (e.g. exporting tokens as JSON, transforming them into code variables) without an AI agent involved
Keeps colors/spacing/typography in sync automatically.
Doesn't generate layout or component code — only the token values, not the assembly.
In practice, these aren't mutually exclusive — a token pipeline keeping values in sync, plus Code Connect mapping components, plus an agent assembling layout from structured context, is a reasonable combination rather than a choice between one and the others.
8. A generic worked example
Imagine a generic internal dashboard project. The design team ships a new "Settings" screen in Figma, built entirely from existing library components: a page header, a couple of form sections, and a save button — all already mapped via Code Connect from earlier work.
A developer selects the Settings frame in Figma and asks the agent to implement it.
The agent pulls layout data (a two-column grid, specific spacing) and resolves each component instance to its Code Connect mapping — the header becomes <PageHeader title="Settings" />, the button becomes <Button variant="primary">Save</Button>, and so on.
The only genuinely new code is the layout wiring and any copy/text specific to this screen — the components themselves are reused, not reinvented.
A developer reviews the diff, adjusts anything that doesn't match project conventions, and ships it — faster than building the screen from a static screenshot, but still with a human in the loop.
9. The actual takeaway
The core idea: the value of Figma-to-Claude integration scales with how much structure already exists on both sides — a real Figma component library, and a real code component library, connected explicitly through Code Connect. Without that structure, it's not much better than pasting a screenshot. With it, it turns design handoff from "translate this by hand" into "point the agent at the frame and review the diff."
Share:
Newsletter
Learn what AI is creating for you. Don't get lost.
Get notified when a new deep dive or lesson goes up. No spam, just new posts.
Semana 4 · Lição 17
Integrando o Figma com o Claude: Code Connect, o MCP do Figma e o fluxo design-to-code
Specs de design costumavam viajar do Figma pro código como print e chute. Agora existe um canal estruturado — o MCP do Figma mais o Code Connect — que deixa um agente de IA ler um design como dado, não como imagem. Eis o que isso significa de fato, e onde ainda falha.
1. A lacuna que isso fecha: print vs. dado estruturado de design
Antes desse tipo de integração existir, "design-to-code com IA" geralmente significava uma coisa: colar um print de um frame do Figma num chat e pedir pro modelo recriar aquilo em código. Isso funciona até certo ponto, mas o modelo está chutando — ele infere espaçamento, valores de cor e limites de componente a partir de pixels, do mesmo jeito que um humano faria olhando um mockup. Pequenas inconsistências (um gap de 8px em vez de 10px, um tom de cinza levemente errado) acabam entrando porque o modelo nunca teve acesso aos valores reais por trás.
Um servidor MCP (Model Context Protocol) do Figma muda isso ao dar ao agente acesso estruturado ao próprio arquivo — dados de layout, variáveis, estilos, metadados de componente — em vez de forçá-lo a fazer engenharia reversa dessa informação a partir de uma imagem. É a diferença entre descrever uma casa a partir de uma foto e receber a planta.
2. O que o MCP do Figma realmente expõe
O MCP em si é um padrão geral (visto numa lição anterior de IA Watch) pra deixar uma aplicação de IA falar com sistemas externos por um protocolo comum, em vez de tudo ser colado manualmente num prompt. O Figma disponibiliza um servidor MCP que fala esse protocolo especificamente pra arquivos de design. Uma vez conectado, um agente como o Claude pode chamar ferramentas que retornam:
Contexto de design — o layout, tamanho e estrutura de um frame ou node selecionado, traduzido pra algo mais parecido com código (posições, regras de auto-layout, constraints) em vez de pixels crus.
Variáveis e estilos — os design tokens por trás do arquivo: variáveis de cor, escalas de espaçamento, estilos de tipografia — os mesmos valores que um design system definiria.
Metadados — nomes de componente, relações de instância, qual node é variante de qual componente.
Screenshots — ainda disponíveis como verificação visual/fallback, mas agora acompanhados do dado estruturado em vez de serem a única fonte de verdade.
Mapeamentos do Code Connect — a peça que transforma "isso é um retângulo com formato de botão" em "isso é literalmente o seu componente <Button />" (mais sobre isso abaixo).
Por que isso importa: um agente que lê variáveis e constraints diretamente produz código que referencia seus tokens de design reais (var(--spacing-4), uma cor de tema) em vez de fixar qualquer valor que ele tenha chutado a partir de um print — que é exatamente o tipo de deriva que torna o CSS de uma base de código mais difícil de manter com o tempo.
3. Code Connect: dizendo ao agente qual componente real usar
Só o dado estruturado de layout ainda deixa uma lacuna: o servidor MCP pode dizer ao agente "isso é um componente chamado Button, no estado 'primary/large'" — mas ele não sabe automaticamente que sua base de código já tem um componente Button em src/components/Button.tsx com props variant e size. Sem esse vínculo, o agente simplesmente geraria um pedaço novo e desconectado de HTML/CSS que por acaso se parece com seu botão.
O Code Connect fecha essa lacuna. É um arquivo de template pequeno (.figma.tsx/.figma.js, ou o equivalente pra outros stacks) que mapeia explicitamente um componente do Figma pro componente de código real e suas props. Uma vez que esse mapeamento existe pra uma peça do seu design system, o servidor MCP pode entregar ao agente o import e os valores de prop reais a usar — não uma reimplementação, mas uma referência ao componente que já existe e já é testado, temado e acessível.
Sem Code Connect
Com Code Connect
Agente infere um botão a partir de forma, cor e texto — escreve markup/CSS novo do zero.
Agente é informado: esse node mapeia pra <Button variant="primary" size="lg"> da sua própria biblioteca de componentes.
Resultado se afasta do seu design system com o tempo — cada geração é um chute novo.
Resultado permanece consistente com seu design system porque reusa os mesmos componentes em todo lugar.
Funciona razoavelmente pra landing pages pontuais sem biblioteca de componentes existente.
Compensa especificamente quando existe um design system real dos dois lados (biblioteca no Figma + biblioteca de componentes no código) pra conectar.
4. O fluxo de ponta a ponta, passo a passo
Configurar o servidor MCP. Geralmente via o app desktop do Figma (a versão de navegador não suporta o servidor MCP desktop) ou um plugin que expõe as configurações do servidor MCP junto com as agent skills relevantes.
Conectar o agente (Claude Code, Cowork, ou outro cliente compatível com MCP) a esse servidor como fonte de ferramenta MCP.
Selecionar um frame ou componente no Figma — isso se torna o escopo de onde o agente vai ler.
O agente pede contexto de design — layout, variáveis e (se configurado) os mapeamentos do Code Connect pra essa seleção.
Escrever ou atualizar arquivos de Code Connect pros componentes da sua biblioteca que ainda não têm mapeamento, pra que execuções futuras resolvam pra componentes reais em vez de chutes.
O agente gera código que usa seus tokens e componentes reais onde existe mapeamento, e aproximações razoáveis onde não existe.
Revisar como qualquer outro diff gerado por IA — isso encurta o trajeto do design até uma implementação inicial, não elimina a necessidade de uma checagem humana no resultado.
5. Funciona nos dois sentidos: código pra design também
A mesma ponte funciona ao contrário. Um agente pode pegar uma página ou componente já construído em código e publicá-lo no Figma como nodes nativos e editáveis — usando os mesmos design tokens e componentes de biblioteca em vez de uma imagem achatada. Isso é útil quando o código foi escrito primeiro (um prototipo rápido, uma ferramenta interna) e agora um designer precisa de uma versão editável no Figma pra iterar, ou quando um time quer que o Figma se mantenha sincronizado com o que realmente está no ar em vez de derivar pra sua própria versão desatualizada da verdade.
6. Prós, contras e onde quebra
Prós
Código gerado referencia tokens de design e componentes reais em vez de reinventá-los a cada geração.
Corta boa parte do trabalho manual de "olhar o frame do Figma e traduzir espaçamento na mão" no handoff.
Bidirecional — evita que design e código se afastem em qualquer direção, se usado de forma consistente.
Contras / limites
O ganho é proporcional a quão maduro já é o seu design system. Um arquivo Figma desorganizado e inconsistente, sem componentes compartilhados, produz saída desorganizada e inconsistente — a ferramenta amplifica o que já existe, nos dois sentidos.
Os mapeamentos do Code Connect precisam ser escritos e mantidos por alguém; eles não aparecem automaticamente na primeira vez.
Rodar mais de um servidor MCP que toca no mesmo dado do Figma ao mesmo tempo tende a confundir o agente e produzir resultados inconsistentes — escolha um caminho de integração por projeto.
Ainda exige revisão. Dado estruturado reduz o chute, mas não garante que o código gerado bata com suas convenções reais, requisitos de acessibilidade ou restrições de performance.
7. Como isso se compara a outras abordagens de design-to-code
Abordagem
Pra que serve bem
Principal fraqueza
Print-pra-código (sem MCP)
Rápido, zero configuração — cola uma imagem, recebe um rascunho.
Modelo está chutando cada valor; se afasta dos seus tokens e componentes reais.
MCP do Figma + Code Connect
Reuso preciso de tokens/componentes existentes; escala bem depois de configurado.
Custo de configuração e manutenção; só compensa com um design system organizado.
Handoff manual de desenvolvedor (specs, redlines, um designer escrevendo notas)
Julgamento humano completo em cada detalhe; nenhuma dependência de ferramenta.
Lento, repetitivo e exatamente o tipo de trabalho que escala mal em muitas telas.
Pipelines de design token (ex: exportar tokens como JSON, transformá-los em variáveis de código) sem um agente de IA envolvido
Não gera código de layout ou componente — só os valores dos tokens, não a montagem.
Na prática, essas abordagens não são mutuamente exclusivas — um pipeline de tokens mantendo valores sincronizados, mais o Code Connect mapeando componentes, mais um agente montando o layout a partir de contexto estruturado, é uma combinação razoável em vez de uma escolha entre uma e as outras.
8. Um exemplo prático genérico
Imagine um projeto genérico de dashboard interno. O time de design entrega uma tela nova de "Configurações" no Figma, construída inteiramente a partir de componentes de biblioteca já existentes: um cabeçalho de página, algumas seções de formulário e um botão de salvar — todos já mapeados via Code Connect em trabalhos anteriores.
Um desenvolvedor seleciona o frame de Configurações no Figma e pede pro agente implementá-lo.
O agente puxa o dado de layout (uma grade de duas colunas, espaçamentos específicos) e resolve cada instância de componente pro seu mapeamento do Code Connect — o cabeçalho se torna <PageHeader title="Settings" />, o botão se torna <Button variant="primary">Save</Button>, e assim por diante.
O único código genuinamente novo é a montagem do layout e qualquer texto específico dessa tela — os componentes em si são reusados, não reinventados.
Um desenvolvedor revisa o diff, ajusta o que não bater com as convenções do projeto, e publica — mais rápido do que construir a tela a partir de um print estático, mas ainda com um humano no processo.
9. O ponto principal
A ideia central: o valor da integração Figma-Claude escala com quanta estrutura já existe dos dois lados — uma biblioteca de componentes real no Figma, e uma biblioteca de componentes real no código, conectadas explicitamente via Code Connect. Sem essa estrutura, não é muito melhor que colar um print. Com ela, transforma o handoff de design de "traduza isso na mão" pra "aponte o agente pro frame e revise o diff".
Compartilhar:
Newsletter
Saiba o que a IA está criando pra você. Não fique por fora.
Seja avisado quando eu postar uma imersão ou lição nova. Sem spam, só posts novos.