Dev Mode MCP Server do Figma expõe tokens e componentes, não acessibilidade

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 → documentou oficialmente, em sua página de desenvolvedores, como 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 conecta arquivos de design a agentes de IA. A ideia central é simples de enunciar e complexa de avaliar: um agente lê o contexto de um arquivo Figma (variáveis, componentes, dados de layout) e usa isso para gerar código, ou para escrever de volta no canvas. A documentação é extensa sobre o que entra nesse fluxo. É silenciosa sobre o que não entra, e é exatamente esse silêncio que interessa a quem decide usar a ferramenta num fluxo real.

O que o servidor realmente coloca na mesa

O MCP (Model Context Protocol) é um padrão para agentes de IA acessarem fontes de dados externas. O servidor do Figma é uma implementação desse padrão voltada a design: ele expõe ferramentas que um agente pode chamar para ler ou escrever conteúdo em arquivos do Figma Design, FigJam e Figma Slides. Segundo a documentação, as capacidades centrais incluem:

• Gerar código a partir de um frame selecionado, útil para times de produto iterando em um fluxo específico;
• Extrair variáveis, componentes e dados de layout direto para o editor de código, algo que a própria documentação chama de "especialmente útil para sistemas de design e fluxos baseados em componentes";
• Recuperar recursos de diagramas do FigJam, levando ideias e mapas de arquitetura para o código;
• Recuperar recursos de arquivos do Make, ajudando na transição de protótipo para produção;
• Gerar design a partir da UI viva de um site ou app (produção, staging ou localhost), transformando elementos reais em camadas editáveis no Figma.

Esse último ponto inverte o fluxo tradicional: em vez de design virando código, código (ou melhor, a interface renderizada) vira design. É um recurso do servidor remoto, disponível só em clientes selecionados, segundo a documentação.

Code Connect: a diferença entre parecer e ser o componente

Gerar código a partir de um frame é a parte fácil de anunciar. A parte difícil é esse código bater com o que o time já usa em produção, e é aí que entra o Code Connect, citado na documentação como o mecanismo que "mantém o código gerado consistente com sua base de código" ao reutilizar os componentes reais do projeto em vez de recriar aproximações visuais.

Na prática, isso significa que a qualidade do código gerado depende diretamente de quanto o Code Connect está mapeado. Um design system com cada componente Figma ligado ao componente real em React↳React37 conteúdos7 erros com React moderno que só aparecem em produção; e como evitarDev (Back & Front) · abr 2026React Native 0.76: o futuro do desenvolvimento mobileDev (Back & Front) · out 2024Simplificando componentes com React HooksDev (Back & Front) · mar 2019Ver tudo em Dev (Back & Front) →, Vue ou o que for tende a receber código fiel. Um arquivo sem esse mapeamento gera componentes genéricos, que podem parecer certos visualmente e divergir estruturalmente do que o time mantém. A documentação não detalha o esforço dessa configuração, e vale considerar isso antes de prometer ao time que o MCP server "já gera o componente certo".

Dois servidores, dois níveis de acesso

A documentação descreve duas formas de conexão, com capacidades diferentes:

Figma for Government, segundo a mesma documentação, só suporta o servidor desktop, com limitações atuais na lista de ferramentas disponíveis. Entre os clientes que já integram escrita no canvas, a documentação lista Claude Code, Claude Desktop, Cursor, VS Code e Warp, cada um com plugin ou skill própria para guiar o agente no fluxo de criação.

O que não aparece em nenhuma linha da documentação

Percorrendo a página inteira (capacidades, configuração, skills, tabela de clientes) não há uma única menção a acessibilidade: nada sobre ARIA, ordem de foco, contraste calculado, texto alternativo ou navegação por teclado. Tudo gira em torno de variáveis, componentes e dados de layout, ou seja, propriedades visuais e estruturais do design.

Isso não é um descuido da documentação, é um limite do próprio arquivo Figma. Um frame guarda cor, espaçamento, hierarquia de camadas e, com Code Connect, o nome do componente real. Ele não guarda o que um leitor de tela deveria anunciar, qual elemento recebe foco primeiro num formulário, ou se um contraste que parece suficiente na tela passa no cálculo de WCAG. Pedir para o MCP server extrair isso é pedir para uma fonte extrair um dado que ela nunca teve.

Em resumo: o código que sai desse fluxo pode ser visualmente fiel e semanticamente vazio ao mesmo tempo. Acessibilidade não é opcional, é parte da definição de pronto, e nenhuma ferramenta de extração de design resolve isso sozinha: alguém do time precisa revisar aria-label, ordem de tabulação, hierarquia de headings e texto alternativo depois que o agente termina.

Fidelidade visual também tem limite

Um frame estático não carrega estados. Hover, foco, erro, carregamento e comportamento responsivo em diferentes larguras de tela dependem de o time ter desenhado essas variantes no Figma e de o agente ter acesso a elas. Se o design system só documentou o estado padrão, o código gerado também só vai cobrir o estado padrão, e cabe a quem revisa notar a lacuna antes que ela vire bug em produção.

A documentação aponta um caminho para reduzir essa ambiguidade: a skill figma-spec, que deixa o agente ler, criar e atualizar specs do time, compartilhando requisitos antes de começar a construir e registrando decisões conforme trabalha. O recurso está em beta aberta e escrever numa spec exige o servidor remoto com acesso de edição ao arquivo, segundo a documentação. É uma peça nova, ainda não testada em escala, que tenta colocar contexto de produto (não só visual) na mão do agente.

Quando vale a pena ligar o fio

O MCP server rende mais em times que já têm Code Connect configurado e um design system com variáveis e componentes bem nomeados: ali, extrair contexto para o editor de código é ganho real de velocidade. Rende menos em arquivos de exploração inicial, sem variantes de estado definidas e sem mapeamento de componentes, porque o agente vai preencher as lacunas com suposições.

Em qualquer um dos dois cenários, o código gerado chega pedindo duas revisões que a ferramenta não faz sozinha: acessibilidade, porque o Figma nunca guardou essa informação, e fidelidade de interação, porque um frame é uma foto e a interface real tem estados que a foto não mostra. Tratar o MCP server como um gerador de rascunho bem informado, e não como etapa final do fluxo, é o que separa ganho de retrabalho.

Fonte: Documentação oficial do Figma Dev Mode MCP Server