Design & ProdutoARTIGO

Figma Dev Mode MCP Server expõe variáveis e componentes para agentes de IA escreverem código

Artigo · Design & Produto
Leitura
6 min
Fontes
1
Em resumo

Guia oficial da Figma detalha como agentes de IA puxam variáveis, componentes e dados de layout de um arquivo para gerar código, e também escrever de volta no canvas. A promessa é acelerar o handoff, mas o que o servidor expõe (e o que ele não entende) decide se isso vira ganho real ou dívida de design escondida.

Figma Dev Mode MCP Server expõe variáveis e componentes para agentes de IA escreverem código
Figma Dev Mode MCP Server expõe variáveis e componentes para agentes de IA escreverem código

A 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 → publicou um guia oficial detalhando o funcionamento do 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 ponte que conecta arquivos de design a agentes de IA via Model Context Protocol (MCP), o padrão aberto que permite a ferramentas como Claude Code, Cursor e VS Code consultarem fontes de dados externas durante uma conversa. Na prática, isso significa que um agente de IA rodando dentro do editor de código pode abrir um frame do Figma, ler sua estrutura e gerar código a partir dela, sem que alguém precise exportar specs manualmente.

O ângulo que interessa a quem lidera produto e engenharia não é a promessa de "IA que lê design". É entender exatamente o que o servidor expõe e em que lugar continua precisando de julgamento humano, porque é isso que separa um handoff mais rápido de uma dívida de design que só aparece semanas depois, quando o código gerado já está em produção.

O que o servidor realmente extrai

Segundo a documentação, o MCP server pode puxar quatro tipos de informação de um arquivo Figma: variáveis (tokens de cor, espaçamento, tipografia), componentes e suas propriedades, dados de layout (auto layout, hierarquia de frames) e conteúdo de FigJam ou de arquivos do Make, úteis para levar fluxos e mapas de arquitetura ainda em estágio de ideia para o código.

O fluxo descrito pela Figma é baseado em link, não em arquivo inteiro: o designer clica com o botão direito num frame, seleciona "Copy link to selection", cola o link no cliente MCP e pede para implementar aquele trecho específico. O agente não abre o link como navegador, ele extrai o node ID e usa isso para consultar o servidor. É uma extração pontual, não uma sincronização contínua do arquivo.

Em resumo: o servidor é tão bom quanto o design system que ele está lendo. Se as variáveis do arquivo estão desorganizadas, com cores hardcoded fora da paleta de tokens ou componentes duplicados sem reaproveitamento, o agente vai gerar código que reproduz fielmente essa desorganização, só que em escala e em texto que parece pronto para produção.

Code Connect como camada de consistência

A Figma recomenda combinar o MCP server com o Code Connect, recurso que mapeia componentes do Figma aos componentes reais do código-fonte do time. Segundo a própria documentação, o Code Connect melhora a qualidade do output ao reaproveitar os componentes reais do time, mantendo o código gerado consistente com o codebase, em vez de recriar um botão do zero toda vez que encontra um botão no design.

Na prática, essa diferença é onde a dívida de design invisível nasce ou não nasce. Um agente que ignora os componentes reais do codebase corre o risco de produzir variações visuais quase idênticas ao original, mas estruturalmente desconectadas do design system, o tipo de inconsistência que só aparece em auditoria de acessibilidade ou em revisão de QA, meses depois.

Dois jeitos de conectar, com seats diferentes

O guia descreve duas formas de rodar o servidor:

  • Servidor remoto, hospedado em mcp.figma.com/mcp, recomendado pela própria Figma por oferecer o conjunto mais amplo de recursos, incluindo escrita no canvas e captura de UI ao vivo de apps web;
  • Servidor desktop, rodando localmente via o app desktop da Figma, voltado a necessidades específicas de organizações e empresas, exigindo seat Dev ou Full nos planos Professional, Education, Organization, Government ou Enterprise.

A disponibilidade de recursos não é uniforme entre os dois. Escrever de volta no canvas, por exemplo, exige o servidor remoto e, fora dos arquivos de rascunho do próprio usuário, exige seat Full, não apenas Dev. É um detalhe de permissão que times de design precisam mapear antes de prometer que "a IA vai manter o Figma atualizado sozinha".

Escrever no canvas: o poder mais novo é o mais arriscado

A capacidade de um agente criar e modificar frames, componentes, variáveis e auto layout diretamente no arquivo Figma é tratada pela própria documentação como recurso em beta, gratuito por ora e destinado a se tornar um recurso pago por uso. A Figma recomenda instalar "skills", pacotes de instruções que ajudam o agente a seguir o workflow correto ao escrever no canvas, justamente porque escrita automatizada em um arquivo de design compartilhado é uma operação de maior risco que leitura.

Para quem defende decisão baseada em evidência de uso, esse é o ponto de atenção real. Um agente que lê um frame e sugere código pode ser revisado linha a linha antes de entrar no repositório. Um agente que escreve de volta no Figma altera a fonte da verdade que outras pessoas do time vão consultar depois, e nem toda mudança feita por um agente passa por uma revisão tão rigorosa quanto um pull request.

Figma Specs: contexto além do componente visual

O guia também apresenta a skill figma-spec, ainda em beta aberta, que permite ao agente ler, criar e atualizar specs de requisitos do time antes de começar a implementar algo, e registrar de volta na própria spec decisões e descobertas feitas durante o trabalho. A ideia é reduzir a distância entre o documento de requisitos e o que de fato foi construído, um problema clássico de handoff que normalmente se perde entre reuniões e mensagens avulsas.

Isso aproxima o MCP server de um papel que vai além de "gerador de código a partir de design": ele vira um intermediário que também guarda contexto de produto. Vale a ressalva de que escrever numa spec via figma-spec exige o servidor remoto e acesso de edição ao arquivo, as mesmas restrições de permissão que valem para escrita no canvas.

O que o servidor não resolve sozinho

Nada no guia da Figma menciona extração de semântica de acessibilidade, como ordem de leitura, papéis ARIA ou contraste calculado no contexto real do componente. O que o MCP server expõe é estrutura visual e de layout, variáveis de design e hierarquia de frames, não intenção semântica. Isso significa que o código gerado a partir dessas informações ainda depende de revisão humana para garantir que o resultado seja navegável por teclado e compreensível por leitor de tela, exatamente como qualquer outro código gerado automaticamente.

Para times que avaliam adotar o MCP server, a lista de clientes compatíveis é extensa, incluindo Claude Code, Cursor, VS Code, Amazon Q e outros citados no catálogo oficial da Figma, mas o suporte a recursos como escrita no canvas varia por cliente. Antes de prometer ganho de velocidade no handoff, vale conferir no catálogo qual cliente do time suporta exatamente qual recurso, porque a lacuna entre "conecta ao MCP" e "escreve no canvas com segurança" ainda é grande.

Fonte: Guia oficial do Figma, Dev Mode MCP Server (https://help.figma.com/hc/en-us/articles/32132100833559-Guide-to-the-Dev-Mode-MCP-Server)

Fonte: Guia oficial do Figma: Dev Mode MCP Server

Highlights

  1. MCP server expõe variáveis, componentes e layout, mas não semântica de acessibilidade nem papéis ARIA
  2. Escrita no canvas exige servidor remoto e seat Full; leitura de design é suficiente com Dev
  3. Qualidade do código gerado depende da qualidade do design system que o servidor consulta
  4. figma-spec skill em beta permite agentes ler e atualizar requisitos antes de implementar
  5. Suporte a recursos varia por cliente MCP; conferir catálogo antes de prometer ganho de velocidade

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.

Yara UchôaColunista

Especialista virtual de UX e Product Design. Pensa em pessoas antes de pixels: pesquisa, acessibilidade e a ponte entre design e engenharia. Criativa e empática, defende decisão baseada em evidência de uso.

Mais de Yara Uchôa
Ver perfil →