Dev Mode MCP Server do Figma: o que o designer precisa arrumar no arquivo para o agente de código ler direito

- Leitura
- 6 min
- Tabelas
- 1
- Fontes
- 1
Quando um agente de IA lê um arquivo do Figma pelo Dev Mode MCP Server, ele depende de nomes de camada, componentes e variáveis bem definidos, não da beleza da tela, para gerar código que faça sentido.
O que muda quando o agente "entra" no arquivo
O Dev Mode MCP↳MCP7 conteúdosArquitetura de Sistemas Cognitivos: Integração de RAG, MCP e LLMs no Ecossistema .NETDev (Back & Front) · abr 2026MCP: O que é e por que você vai ouvir falar disso em breve?AI · jul 2025Agentes de IA com LLMs de Código Aberto: Integração Prática com o Model Context Protocol (MCP)AI · ago 2025Ver tudo em AI → Server é a porta que o Figma↳Figma3 conteúdosFigma Dev Mode funciona mesmo? Testando na práticaDev (Back & Front) · mar 2025Claude Design: nova aposta da Anthropic contra Figma e MicrosoftProduto & UX · abr 2026A importância do HTML e CSS para quem trabalha com UI Design e Design SystemProduto & UX · dez 2024Ver tudo em Produto & UX → abre para agentes de IA lerem um arquivo de design e escreverem código, ou, na direção contrária, desenharem de volta no canvas. Segundo o guia oficial do Dev Mode MCP Server, o recurso está disponível para contas Starter, Professional, Education, Organization, Government e Enterprise, desde que o cliente de IA conste no catálogo de MCP do Figma.
A proposta parece simples: copiar o link de um frame, colar no cliente MCP (Claude Code, Cursor, VS Code com extensão, entre outros) e pedir para o agente implementar aquilo. Na prática, o que o agente recebe depende diretamente de como o arquivo foi montado. Um frame batizado de "Frame 47", com camadas chamadas "Rectangle 12" e "Group 8", devolve ao agente exatamente isso: geometria sem significado. É aí que entra o trabalho que cabe ao designer, não ao agente.
Como a extração de contexto funciona por trás do link
A documentação descreve a extração de contexto como algo baseado em link: o designer clica com o botão direito no frame ou camada, escolhe Copy link to selection e cola o endereço no cliente MCP. O cliente não abre o link como um navegador abriria; ele extrai o ID do nó que o servidor MCP usa para identificar sobre qual objeto buscar informação.
A partir desse ID, o servidor devolve ao agente três tipos de material, segundo o próprio guia: variáveis, componentes e dados de layout. É essa tríade que vira prompt de código. Quando esses três elementos estão bem construídos no arquivo, o agente tem o que precisa para gerar algo próximo do componente real. Quando não estão, ele preenche as lacunas com suposição, e suposição de IA sobre design vira componente genérico, com nome e estrutura que não batem com o restante do código.
Nomenclatura de camada não é estética, é dado de entrada
A documentação do Dev Mode MCP Server não lista uma convenção obrigatória de nomes, mas o próprio mecanismo que ela descreve explica por que a nomenclatura pesa: o agente não vê a tela como um humano vê. Ele lê a árvore de camadas e os metadados que ela carrega, então o nome da camada é informação, não decoração.
Um botão chamado Button/Primary/Default entrega ao agente categoria, variante e estado numa frase só. O mesmo botão chamado "Frame 231" entrega zero disso: o agente precisa inferir a partir de geometria, cor e posição, e é na inferência que o erro entra. Isso vale tanto para componentes quanto para camadas soltas dentro de um frame complexo. A régua prática que se extrai do funcionamento do MCP:
- Nomeie por função, não por aparência (
Button/Primaryem vez de "Blue Rectangle") - Use hierarquia consistente nos nomes de variantes (
Status=Error,Size=Small) em vez de texto livre - Evite nomes herdados do padrão do Figma ("Rectangle 1", "Frame 99", "Group") em qualquer camada que vá virar código
- Mantenha grupos e frames com propósito único: uma camada que mistura header, ícone e texto solto sem nome próprio obriga o agente a adivinhar onde cada coisa termina
Componentes, variáveis e auto layout são a munição real
A extração de contexto, segundo a documentação, é "especialmente útil para design systems e fluxos baseados em componentes". Isso não é um detalhe: é o recorte de quem o recurso foi pensado para atender. Arquivos com instâncias de componentes bem publicados e variáveis nomeadas (cor, espaçamento, raio) dão ao agente algo equivalente a um design token já mapeado, pronto para virar variável CSS↳CSS31 conteúdosArquitetura CSS: CSS FuncionalDev (Back & Front) · set 2019Entendendo posicionamento com CSS de uma vez por todasDev (Back & Front) · jul 2025Sites que combinam estética e usabilidade: reflexos da evolução do CSSDev (Back & Front) · fev 2025Ver tudo em Dev (Back & Front) → ou prop de componente.
Arquivos sem design system, feitos à mão livre com formas soltas, forçam o agente a reconstruir visualmente algo que nunca existiu como estrutura. Auto layout entra no mesmo pacote: a documentação cita que agentes com permissão de escrita conseguem criar e atualizar frames, componentes, variáveis e auto layout usando o design system como fonte de verdade.
usando seu design system como fonte de verdade
Guia do Dev Mode MCP Server, Central de Ajuda do Figmausing your design system as the source of truth
Um frame sem auto layout não carrega informação de como os elementos se comportam quando o conteúdo muda de tamanho. O agente até gera algo visualmente parecido, mas sem a lógica de responsividade que o design realmente tinha. É a diferença entre código que parece a tela e código que se comporta como a tela.
Code Connect: o atalho que evita reinventar o componente
A documentação cita o Code Connect como a peça que mantém o código gerado "consistente com seu codebase", ao reutilizar os componentes reais do projeto. Sem essa ligação, cada vez que o agente encontra um botão no Figma, ele decide sozinho se gera HTML puro, um componente novo ou tenta adivinhar o nome do componente existente no repositório.
Com Code Connect configurado, a resposta já está mapeada: o botão do Figma aponta para Button do design system do time, com as props corretas. Isso reduz a chance de o agente inventar um componente paralelo ao que já existe, duplicando lógica. O efeito prático é menos revisão de pull request corrigindo componente reinventado do zero.
Figma Specs: contexto que sobrevive ao primeiro prompt
Outro recurso citado no guia, ainda em beta aberta, é a skill figma-spec, que permite ao agente ler, criar e atualizar specs do time antes de começar a trabalhar. A ideia é que requisitos e decisões fiquem registrados no próprio arquivo, em vez de se perderem na conversa com o agente. Escrever numa spec exige o servidor remoto e acesso de edição ao arquivo.
Isso muda o fluxo de handoff: em vez de o designer explicar o contexto de novo a cada sessão de IA, a spec vira memória persistente que o agente consulta e atualiza. Para times que já documentam decisões de design, é ganho direto. Para quem nunca manteve esse hábito, o recurso não resolve sozinho a falta de disciplina de documentação.
Remoto ou desktop: a escolha também afeta o que o agente enxerga
A documentação separa dois jeitos de conectar o servidor, e a escolha entre eles não é só operacional.
| Aspecto | Servidor remoto | Servidor desktop |
|---|---|---|
| Instalação | Direto no endpoint hospedado pelo Figma, sem app desktop | Roda localmente via app desktop do Figma |
| Recursos | Conjunto mais amplo, recomendado para a maioria | Voltado a necessidades específicas de organização/enterprise |
| Escrita no canvas | Suportada (requer seat Full) | Não é o foco do recurso |
| Figma for Government | Não suportado | Único modo suportado |
Escrever no canvas é gratuito durante o período de beta e passará a ser um recurso pago por uso, segundo o guia. Isso significa que times que hoje usam a escrita bidirecional, com o agente criando frames e variáveis direto no Figma, devem acompanhar quando essa cobrança entrar em vigor, porque muda o cálculo de custo de usar o MCP server em escala.
Quando não vale a pena ligar o MCP no arquivo
Nem todo arquivo justifica o esforço de arrumação. Um protótipo descartável, feito para validar uma ideia numa reunião e sem pretensão de virar produto, não precisa de nomenclatura rigorosa nem de variáveis: o custo de organizar tudo supera o ganho de ter um agente lendo aquilo.
O mesmo vale para arquivos legados que ninguém pretende manter como design system vivo. Forçar nomenclatura e componentização num arquivo que será substituído em semanas é trabalho que não volta. O MCP server compensa justamente onde o design system já é, ou está virando, fonte de verdade para código, que é exatamente o recorte que a própria documentação do Figma assume ao falar em workflows baseados em componentes.
Fonte: Central de Ajuda do Figma — Guia do Dev Mode MCP Server
Este artigo foi escrito por Yara Uchôa, colunista de UX e product design. Conteúdo produzido por agente de IA da redação iMasters, sob revisão editorial humana. Saiba como produzimos no expediente.
Design system nasce no código, não no Figma: o fluxo com MCP de Christine Vallaure
A designer Christine Vallaure inverteu o fluxo tradicional: em vez de traduzir Figma em código, ela gera a biblioteca Figma a partir do código real, usando MCP para manter os dois lados sincronizados.

















