Dev Mode MCP Server do Figma: como configurar acesso sem vazar o design system

O problema que todo time de produto conhece: o design está pronto no 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 →, mas a tradução para código passa por inspeção manual de espaçamentos, cores, nomes de tokens e componentes. Cada desenvolvedor interpreta o arquivo de um jeito, e o resultado se afasta do design system. 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 do Figma ataca exatamente esse ponto ao permitir que um agente de IA leia o arquivo de design direto de dentro do editor de código, em vez de o desenvolvedor traduzir tudo na mão.

Segundo a documentação oficial do Figma, o servidor usa o Model Context Protocol (MCP), o mesmo padrão que ferramentas como Claude, Cursor e VS Code adotaram para conectar agentes a fontes de dados. Na prática, o Figma deixa de ser uma imagem que o dev olha em outra aba e passa a ser uma fonte estruturada que o modelo consulta: variáveis, componentes, layout e hierarquia de camadas chegam ao contexto do LLM.

O que o servidor entrega de fato

O MCP Server do Figma não é só "gerar código a partir de um print". Ele expõe um conjunto de capacidades que vale separar, porque cada uma muda uma etapa diferente do fluxo:

• Gerar código a partir de frames selecionados. Você seleciona um frame no Figma e pede ao cliente MCP que o transforme em código. É o caso de uso mais direto para quem está construindo uma nova tela.
• Extrair contexto de design. Variáveis, componentes e dados de layout entram no IDE. É aqui que mora o valor para design systems: o agente lê os tokens reais, não valores hardcoded que ele adivinhou.
• Escrever no canvas. Com o servidor remoto, o agente cria e modifica conteúdo nativo do Figma (frames, componentes, variáveis, auto layout) usando o design system como fonte da verdade.
• Capturar UI ao vivo. Dá para pegar a interface renderizada de uma aplicação (produção, staging ou localhost) e trazê-la de volta ao Figma como camadas editáveis.
• Puxar recursos de FigJam e de arquivos Make. Fluxos, diagramas e protótipos viram contexto para a geração de código.

O acesso a um nó específico é baseado em link. O caminho descrito na documentação é simples: selecionar a camada no Figma, usar Copiar link para a seleção, e colar essa URL no cliente MCP. O agente não navega até a URL; ele extrai o node ID embutido no link, e é esse identificador que diz ao servidor qual objeto retornar. Vale entender esse detalhe porque ele define o grão do acesso, o agente enxerga o que você aponta, não o arquivo inteiro por padrão.

Remoto ou desktop, e por que a escolha importa

Há dois modos de conexão, e a diferença tem impacto direto em governança.

A documentação recomenda o servidor remoto como padrão por ter mais funcionalidades. Mas para times com política restritiva de tráfego externo, o desktop é o que mantém o processamento na máquina do desenvolvedor, ao custo de perder escrita no canvas e captura de UI. Essa é a primeira decisão de governança que um time brasileiro precisa tomar antes de habilitar qualquer coisa: onde o conteúdo do arquivo pode trafegar.

Outro ponto do texto oficial que merece atenção: o recurso está em beta e gratuito agora, mas o Figma avisa que vai virar cobrança baseada em uso. Ou seja, quem desenhar o fluxo hoje precisa contar que o custo entra na conta depois, e dimensionar quem realmente precisa de acesso.

Skills: reduzindo o improviso do agente

O servidor expõe ferramentas individuais, mas ferramenta solta não garante bom resultado. É aí que entram os Skills, instruções em nível de agente que orientam qual ferramenta usar, em que ordem, e como aplicar o resultado. A documentação cita fluxos que os Skills empacotam:

• Conectar componentes de design a componentes de código via Code Connect.
• Gerar regras de design system alinhadas ao codebase.
• Traduzir designs em código pronto para produção.

Skills não adicionam capacidade nova nem substituem a conexão MCP; eles reduzem setup e adivinhação. Estão disponíveis por cliente (Claude Code, Codex, Cursor, VS Code, entre outros), pela Figma Community e por contribuições no repositório community-resources no GitHub.

A peça que fecha a fidelidade ao design system é o Code Connect. Sem ele, o agente gera markup que parece o componente. Com ele, o código gerado reutiliza os componentes reais do seu codebase, o botão gerado é o seu , não uma div estilizada que imita um botão. Para quem mantém biblioteca compartilhada, essa diferença é o que separa código descartável de código que entra no repositório.

Governança: o acesso é parte da definição de pronto

O ângulo que mais interessa a quem lidera produto no Brasil não está na demo bonita, e sim em quem pode ler o quê. Algumas leituras práticas a partir do que a documentação estabelece:

O acesso segue as permissões do Figma. O agente atua sob a conta conectada. Se um desenvolvedor tem acesso a um arquivo com componentes proprietários, o agente também tem. A régua de permissão de arquivos e projetos continua sendo a sua primeira barreira, não algo que o MCP resolve sozinho.

Escrita no canvas é poder de escrita. Habilitar o servidor remoto significa que o agente pode criar e alterar frames, variáveis e componentes. Em um design system compartilhado, isso pede cuidado: um prompt mal calibrado pode mexer em biblioteca que várias equipes consomem. Restringir escrita a arquivos de trabalho, e não às bibliotecas publicadas, é uma proteção sensata.

Captura de UID ao vivo cruza a fronteira produção/design. O recurso de mandar a interface de produção ou staging de volta para o Figma é potente para alinhamento, mas move telas reais (possivelmente com dados) para o ambiente de design. Vale definir se localhost é o único ambiente permitido nesse fluxo.

O caminho que faz sentido para um time é começar pelo servidor remoto com acesso restrito a um subconjunto de arquivos, validar a qualidade do código gerado com Code Connect ligado, e só então ampliar. Nada disso está automatizado: a documentação entrega as ferramentas e as instruções por cliente, mas a política de quem acessa qual arquivo é decisão do time.

O que fica em aberto

A documentação é um panorama de alto nível e remete a artigos específicos para instruções e exemplos de prompt (Claude Code, Codex, Cursor, Gemini CLI, VS Code e Xcode têm guias próprios). O que ela não resolve, e cada time precisa medir, é a fidelidade real do código gerado em componentes complexos, o comportamento em arquivos grandes, e o custo quando o beta virar cobrança por uso.

Para UX e design, o ganho concreto é reduzir a tradução manual que sempre degradou a consistência entre design e implementação. Mas a lição de sempre continua valendo: acessibilidade, tokens semânticos e nomeação de componentes precisam estar corretos no arquivo, porque o agente vai reproduzir o que encontrar, inclusive os erros. Design que já era argumentado e bem estruturado vira código melhor; arquivo bagunçado vira código bagunçado mais rápido.

Fonte: Documentação do Figma – Guide to the Dev Mode MCP Server