A própria documentação do Figma mostra uma resposta de get_design_context com 351.378 tokens, contra um limite de 25.000. Este artigo explica o que infla a saída do Figma MCP, como medir cada chamada e sete correções, do get_metadata ao Code Connect, que mantêm as respostas pequenas.
Você cola um link do Figma no seu agente de programação, pede um único card de preços e a execução quebra com um erro sobre o tamanho da resposta. A própria página de solução de problemas do Figma mostra a mensagem exata: uma resposta de get_design_context com 351.378 tokens contra um teto de 25.000 tokens. Essa requisição ultrapassou o limite em quatorze vezes. E mesmo quando uma resposta passa raspando pelo limite, ela ainda ocupa sua janela de contexto, empurra para longe as instruções anteriores e é relida a cada turno que vem depois.
Este artigo mostra por que o servidor Figma MCP produz tanta saída, como ver quanto custa cada chamada e sete mudanças que reduzem esses números sem piorar a interface gerada. Os nomes das ferramentas e os limites vêm da documentação publicada pelo Figma. As recomendações de fluxo de trabalho vêm do que acontece quando arquivos de design grandes encontram janelas de contexto pequenas.
Um link de nó não retorna um único retângulo. get_design_context extrai o contexto de design das camadas selecionadas e o devolve como código, React com Tailwind por padrão, com outros frameworks disponíveis. Se você selecionar um frame de página inteira, toda camada aninhada vem junto: barras de navegação, cards, instâncias de ícones, estilos de texto, regras de auto layout, espaçamentos.
Uma landing page movimentada pode ter milhares de nós, e cada nó carrega um nome, um tamanho, preenchimentos, contornos, espaçamento interno e configurações de tipo. Transformado em código, tudo isso vira listas longas de classes e marcação profunda. Listas longas de classes são tokenizadas de forma ruim. Uma regra prática comum é cerca de quatro caracteres por token para prosa em inglês, e código e marcação densos costumam encaixar menos caracteres em cada token.
Quatro coisas tendem a inflar a resposta mais rapidamente:
Uma única solicitação de design costuma acionar várias ferramentas de leitura, e cada uma adiciona a própria carga. A referência de ferramentas do Figma as lista:
| Ferramenta | O que retorna | Tamanho relativo | Melhor uso |
|---|---|---|---|
get_metadata | Esboço XML esparso com IDs de camadas, nomes, tipos, posições e tamanhos | Pequeno | Mapear um frame grande antes de buscar qualquer coisa |
get_design_context | Estilo e estrutura da camada como código, React e Tailwind por padrão | Grande, cresce com a subárvore | Construir um componente ou uma seção |
get_screenshot | PNG da seleção para preservar a fidelidade do layout | Médio, tokens de imagem | Checagem visual do resultado |
get_variable_defs | Variáveis e estilos usados na seleção: cores, espaçamentos, tipografia | Pequeno a médio | Combinar tokens de design |
download_assets | Exportações em PNG, JPG, SVG ou PDF, ou as imagens originais | Depende dos assets | Salvar ícones e fotos como arquivos |
get_code_connect_map | Mapeamentos de ID de nó para componentes de código | Pequeno | Reutilizar componentes que você já publica |
A coluna de tamanho descreve o que cada ferramenta retorna em geral. As contagens reais dependem do seu arquivo, então meça antes de confiar em qualquer rótulo.
Os resultados das ferramentas permanecem na conversa. Suponha que uma leitura retorne 40.000 tokens: cada mensagem seguinte passa a carregar esse peso. O cache de prompt pode reduzir o preço de reler esse conteúdo, mas os tokens continuam ocupando a janela, então sufocam seus arquivos de origem, a saída de testes e as instruções. Sessões longas acabam acionando a compactação automática, que resume e apaga detalhes que você queria manter.
💡 Verificação rápida: se o agente ficar mais lento ou esquecer instruções anteriores logo após uma chamada ao Figma, culpe a resposta superdimensionada antes de culpar o modelo.
A maioria dos clientes mostra o quanto a janela está cheia. No Claude Code, o comando /context faz isso. Verifique o número antes e depois de cada chamada ao Figma. A diferença é o custo real daquela chamada, captura de tela incluída, e é o único número que importa para o seu arquivo.
Escolha um frame real e execute três chamadas em uma sessão nova, anotando o tamanho do contexto depois de cada uma:
get_metadata no frame completo.get_design_context no frame completo.get_design_context em um nó filho retirado dos metadados.Registre os resultados em uma tabela como esta:
| Chamada | Nó | Contexto adicionado | Observações |
|---|---|---|---|
get_metadata | Frame completo | Preencher | Só o esboço |
get_design_context | Frame completo | Preencher | Verificar o erro de tamanho |
get_design_context | Um filho | Preencher | Comparar com a linha acima |
Depois de alguns frames, você terá sua própria curva de custo, que vale mais do que qualquer número em um post de blog, este incluído. Minha regra prática: busque leituras pequenas o bastante para fazer cinco ou seis numa mesma sessão antes que a compactação entre em ação. Se uma única leitura consome um terço da janela, o nó é grande demais.
Em ordem aproximada de quanto costumam economizar.
O Figma indica get_metadata para designs muito grandes porque ele retorna um esboço XML esparso, sem estilos anexados. Leia o esboço, escolha a seção de que você realmente precisa e então chame get_design_context apenas nesse ID de nó.
Run get_metadata on this frame. Do not call get_design_context yet.
List the top level sections with their node IDs and wait for my pick.
O servidor trabalha a partir do nó que você seleciona ou linka. Linke o botão, não a página. Monte uma página do jeito que uma pessoa faria: cabeçalho, hero, preços, rodapé, cada um como uma solicitação própria.
Organize também o arquivo de origem. Camadas não usadas e grupos muito aninhados podem adicionar nós que a saída precisa descrever, então uma limpeza de dez minutos feita pelo designer costuma se pagar já na próxima leitura.
A documentação do Figma recomenda configurar o Code Connect para obter os melhores resultados de reaproveitamento de código. Os mapeamentos ligam um nó do Figma a um componente real do seu repositório, por meio de get_code_connect_map e add_code_connect_map. Em vez de reconstruir um botão a partir de estilos brutos a cada requisição, o agente pode apontar para o botão que você já publica. Isso significa menos código gerado e menos comentários na revisão.
Uma diferença para ficar de olho: o servidor desktop usa os mapeamentos que você seleciona, enquanto o servidor remoto precisa do parâmetro clientFrameworks definido com um rótulo específico, como React ou SwiftUI.
Quando os designers aplicam variáveis e estilos para cor, espaçamento e tipografia, get_variable_defs retorna os que são usados na seleção. Uma saída que referencia o nome de um token é melhor do que o mesmo código hexadecimal e o mesmo valor em pixels repetidos em centenas de elementos, e se alinha aos tokens que já estão na sua folha de estilos.
💡 Peça à equipe de design para vincular preenchimentos e espaçamentos a variáveis antes da primeira leitura via MCP. Isso leva alguns minutos para eles e poupa todas as solicitações seguintes.
React e Tailwind é a saída padrão. Se o seu projeto usa Vue, SwiftUI ou CSS puro, uma resposta em React precisa de uma segunda passada para ser convertida, e você paga pelas duas. Diga a stack no prompt e, no servidor remoto, defina clientFrameworks explicitamente. O mesmo vale para o estilo: informe se você usa Tailwind, módulos CSS ou uma biblioteca de componentes, porque misturar abordagens em uma só passada é como começam as reescritas.
Use download_assets para exportar ícones e fotos como arquivos para o repositório e depois referencie-os pelo caminho. Não faça o agente reler um nó de imagem para cada componente que mostra o mesmo logo. As exportações podem ser SVG para ícones e PNG ou JPG para fotos, então escolha o formato que seu build já usa. Quando os arquivos estiverem no repositório, os prompts seguintes precisam apenas do caminho do arquivo.
O Figma observa que as capturas de tela podem ser desativadas se os limites de tokens forem uma preocupação, embora recomende mantê-las ativas porque preservam a fidelidade do layout. Um meio-termo justo: mantenha-as na primeira construção de uma seção e desative-as em pequenas edições, como a troca de um rótulo ou um ajuste de espaçamento.
A mensagem de erro sugere aumentar MAX_MCP_OUTPUT_TOKENS, e a página de solução de problemas do Figma cita 50000 ou 100000 como valores de exemplo. No Claude Code, você define a variável nas configurações do ambiente e reinicia o aplicativo. Isso desbloqueia a chamada, mas não muda em nada quantos tokens a resposta contém. Um teto maior apenas deixa uma pilha maior entrar na janela.
Se o erro de tamanho continuar aparecendo depois que você busca uma única seção, o próprio nó é pesado. Divida-o: peça get_metadata para os filhos desse nó e depois busque-os um de cada vez. Se um componente ainda retornar demais, a causa costuma ser uma lista muito longa de instâncias ou uma camada cheia de texto, e a correção pertence ao arquivo do Figma, não ao prompt.
| Abordagem | Efeito no contexto | Quando faz sentido |
|---|---|---|
Aumentar MAX_MCP_OUTPUT_TOKENS | Nenhum, apenas deixa passar respostas maiores | Uma leitura pontual e rara que você não consegue dividir |
| Buscar nós filhos | Reduz bastante o tamanho da resposta | Padrão para qualquer coisa maior que uma seção |
| Desativar capturas de tela | Remove a carga de imagens | Pequenas edições |
| Code Connect | Reduz o código que o agente escreve | Qualquer projeto com biblioteca de componentes |
| Nova conversa por seção | Limpa cargas antigas | Sessões longas |
O arquivo de regras pode ser curto. Algo assim já basta:
Design to code rules
- Framework: React with Tailwind. Reuse components from src/components first.
- Colors and spacing: use the tokens in src/styles/tokens.css, never raw hex values.
- Figma: call get_metadata first on any frame larger than one section.
- Fetch one node per request. Do not re-pull a node that is already built.
Ele custa algumas dezenas de tokens por sessão e bloqueia os hábitos mais caros antes que eles comecem.
get_metadata e escolha um nó.Pegue uma página de preços com cabeçalho, três cards de planos, um FAQ e um rodapé. O caminho caro é um link para o frame inteiro e o prompt "construa esta página". O caminho enxuto fica assim:
get_metadata no frame da página retorna o esboço e os IDs dos nós.get_design_context para um card de plano, com capturas de tela ativadas.PlanCard com props para nome, preço e recursos.Três cards de planos, uma leitura de design. Em uma página inteira, essa diferença entre "uma leitura por seção" e "uma leitura para tudo" é de onde vem a maior parte da economia.
| Erro | Por que custa | Correção |
|---|---|---|
| Linkar a página inteira | A subárvore inteira volta | Linke uma seção |
Chamar get_design_context duas vezes no mesmo nó | A mesma carga entra duas vezes no contexto | Reutilize o primeiro resultado |
| Ler de novo para um ajuste pequeno | Uma carga nova para uma mudança de uma linha | Edite o código diretamente |
| Aumentar o teto por padrão | Leituras superdimensionadas viram normais | Mantenha o padrão, aumente só temporariamente |
| Ignorar o framework | Uma segunda passada de conversão | Defina a stack primeiro |
Algumas correções pertencem ao arquivo do Figma, não ao prompt. Peça ao time de design para dividir fluxos longos em uma seção por frame, nomear as seções pelo que elas são e manter componentes reutilizáveis em uma biblioteca, em vez de copiá-los entre páginas. Um arquivo organizado dá a get_metadata um esboço limpo para trabalhar, o que torna cada leitura seguinte menor e mais fácil de ler para o agente. Compartilhe também seus números do teste no mesmo frame. Ver uma leitura cair de enorme para modesta é a forma mais rápida de transformar custo de tokens em hábito de design.
Vários servidores da comunidade afirmam comprimir os dados do Figma em uma saída mais enxuta. Podem valer a pena, mas rode o teste no mesmo frame com eles antes de trocar, e confira o que deixam de fora. Uma resposta menor só é uma vitória se os detalhes de layout de que você precisa sobreviverem.
Uma execução de design para código envolve mais do que chamadas ao Figma. Boa parte do trabalho ao redor não precisa acontecer dentro do contexto do seu agente de programação, e é aí que os modelos da coleção Large Language Models do PicassoIA ajudam.
Imagens são outro lugar para economizar. Fotos de hero e imagens de placeholder não precisam passar pelo servidor do Figma. Gere-as a partir de um prompt com o Flux 2 Pro, o Seedream 4.5 ou o P-Image, e nada disso toca o contexto do seu agente de programação. Precisa de movimento para uma landing page? O Seedance 2.0 e o PicassoIA Video transformam um prompt ou uma imagem fixa em um clipe curto.
Sua próxima sessão de design para código vai andar mais rápido se as imagens estiverem prontas antes do primeiro prompt. Abra o Picasso IA, escreva uma descrição curta da cena e rode-a no Flux 2 Pro e no Seedream 4.5 lado a lado. Fique com a que se encaixa no seu layout e, se a página precisar de um hero em movimento, anime-a com o Seedance 2.0.
Teste alguns prompts hoje e veja quais você prefere. Todos os modelos estão listados em picassoia.com/en/all-models, então você pode testar quantos quiser.
Escolha seu idioma
