MCP — Model Context Protocol — permite que agentes de IA façam chamadas de ferramenta em tempo de execução para serviços externos. O Figma lançou um servidor MCP oficial, e a comunidade construiu vários outros. A proposta: seu agente pode pedir dados de design ao Figma diretamente, sob demanda, no meio de uma conversa. Sem etapa de export. Sempre ao vivo.

O figmascope faz a aposta arquitetural oposta: exporte uma vez, envie um bundle, nunca conecte novamente. Essas são escolhas genuinamente diferentes com implicações diferentes. Veja o que cada uma realmente custa e ganha.

O que é o servidor MCP do Figma

O Model Context Protocol é o padrão aberto da Anthropic para conectar agentes de IA a ferramentas externas via interface de servidor. Um servidor MCP expõe ferramentas tipadas que o agente pode chamar: "get_file", "get_node", "get_styles" e assim por diante. Quando o agente precisa de contexto de design, ele chama a ferramenta, o servidor MCP chama a API do Figma, e o resultado retorna como contexto para o prompt atual.

O servidor MCP oficial do Figma cobre leitura de arquivo, inspeção de nó, recuperação de componentes e acesso a comentários. Servidores MCP da comunidade (existem vários no GitHub) estendem isso com schemas customizados, transformações adicionais ou escopos mais estreitos otimizados para fluxos específicos de agentes.

Para usar qualquer servidor MCP do Figma, você o configura no seu cliente de agente (Claude Desktop, Cursor, Continue etc.), fornece um PAT do Figma, e o servidor roda como um processo local. Quando seu agente precisa de contexto do Figma, ele chama a ferramenta. Você não exporta nada explicitamente — o agente busca o que precisa quando precisa.

O modelo MCP na prática

Um fluxo típico com Figma via MCP parece assim: você abre o Cursor, inicia uma conversa, diz "implemente a tela de checkout deste arquivo Figma", e o agente chama get_file, puxa a árvore de nós e tem os dados de design em contexto. Se você depois disser "o designer atualizou os tokens de botão", o agente pode chamar novamente e obter dados frescos.

Esse modelo de conexão ao vivo é real e atraente para alguns fluxos. O agente está trabalhando com dados atuais. Você não gerencia artefatos de export. Não há etapa manual entre "designer enviou uma mudança" e "o agente a tem."

Onde o MCP vence

Dados ao vivo, sem etapa de export. O agente busca o estado atual sob demanda. Se o design mudou há dez minutos, o agente pode ver. O figmascope requer um re-export manual para capturar mudanças.

Exploração conversacional de design. "Qual é a cor do botão CTA?" "Quantas telas referenciam esse componente?" Com MCP, um agente pode responder chamando o Figma. Com um bundle, a resposta só é tão atual quanto o último export.

Edição direta do Figma. Alguns servidores MCP expõem operações de escrita — criar nós, atualizar propriedades, publicar comentários. Isso só é possível com uma conexão ao vivo. Um bundle estático não tem caminho de escrita.

Sem fluxo manual. Para desenvolvedores que já usam setups de agentes conectados a MCP, sem etapa de export significa uma coisa a menos para esquecer. O gerenciamento de contexto é delegado ao agente.

Onde o MCP perde

O modelo de conexão ao vivo tem custos arquiteturais fáceis de subestimar.

Estado vinculado à sessão. Chamadas MCP acontecem no contexto de uma sessão de conversa. Os dados que o agente recuperou na sessão A não estão disponíveis na sessão B sem re-buscar. Se você inicia um novo chat, o agente começa do zero. Um bundle do figmascope persiste entre sessões, entre desenvolvedores e entre ferramentas — são apenas arquivos.

Opaco para o git. Não há artefato. Nada a commitar. O contexto de design que informou seu código não vive no repositório. Seis meses depois, se você quiser entender como o design estava quando um componente foi construído, não há registro. Com um bundle no repo, você tem um histórico de commits da intenção de design.

Requer conexão. O MCP precisa de um servidor rodando, uma conexão à API do Figma e um PAT com acesso. Rede caída, API do Figma caída, PAT expirado — o agente não tem contexto. Um bundle funciona num avião.

Recuperação dependente do modelo. O que o agente pede via MCP depende do que ele decide pedir. Pode não buscar os valores de token. Pode não puxar o inventário de componentes. Pode solicitar apenas a subárvore de nós que acha que precisa, perdendo contexto espacial de nós adjacentes. A recuperação é probabilística, não determinística. O figmascope busca tudo, sempre, com um schema fixo.

Mais difícil de testar e reproduzir. "Meu agente construiu esse componente a partir desses dados do Figma neste momento" não é verificável com MCP. A busca é efêmera. Com um bundle, você pode reproduzir exatamente: mesmo bundle, mesmo agente, mesmo prompt — saída determinística. Isso importa para depuração, revisão de código e responsabilidade em releases.

Pressão na janela de contexto. Uma chamada ingênua de get_file em um arquivo Figma complexo retorna uma árvore JSON enorme. Agentes precisam fazer chamadas seletivas para ficar dentro dos orçamentos de contexto. Isso introduz heurísticas e julgamentos que podem dar errado. O figmascope pré-processa a árvore em um IR estruturado com apenas o necessário, de tamanho conhecido e limitado.

O modelo de bundle do figmascope: capture uma vez, use para sempre

O figmascope exporta um .zip de arquivos simples da API REST do Figma — sem plugin, sem servidor, roda no seu browser. O bundle contém:

Uma vez exportado, o bundle é autocontido e imutável. Vai para o seu repo junto com o código que descreve. Qualquer agente, qualquer sessão, qualquer desenvolvedor, qualquer tarefa de CI pode lê-lo. Sem conexão com nada.

Diffs versionáveis: comparando bundles como código

Este é o argumento mais forte do modelo de bundle. Como a saída é JSON e Markdown estruturados, você pode diferençá-la.

Exporte um bundle antes de um sprint de design. Exporte outro depois. Rode diff em tokens.json:

- "spacing.4": "16px"
+ "spacing.4": "14px"

Essa é uma mudança breaking na sua escala de espaçamento. Está visível, revisável e rastreável a um commit. Com MCP, a mesma mudança acontece silenciosamente — na próxima vez que o agente buscar, ele obtém o novo valor, e não há registro de que algo mudou.

Você pode rodar isso como gate de PR: exporte o bundle como parte do handoff de design, faça commit, exija aprovação do designer e do dev no diff antes que a implementação comece. Isso é design-spec-como-código. O MCP não tem equivalente.

O argumento do determinismo

Mesma versão do arquivo Figma + mesmo export do figmascope = mesmo bundle. Sempre. O schema do IR é fixo. A lógica de sourcing de tokens é determinística. A extração de chaves de string é baseada em regras.

A recuperação via MCP não é determinística. O agente decide o que buscar. Agentes diferentes, phrasing de prompt diferente, orçamentos de contexto diferentes — comportamento de busca diferente. A saída é dependente do modelo.

Para codegen de UI de produção, determinismo importa. Você quer que a spec que gerou um componente seja reproduzível. Você quer poder regenerar o componente a partir dos mesmos inputs e obter resultados consistentes. Bundles suportam isso. Sessões MCP não.

Comparação

Dimensão Figma MCP Bundle figmascope
Frescor dos dados Sempre ao vivo — busca o estado atual do Figma Snapshot — tão fresco quanto o último export
Etapa de export necessária Não Sim — uma vez por versão de design
Versionável Não — sem artefato Sim — bundle é JSON + Markdown diferençável
Persiste entre sessões Não — precisa re-buscar a cada sessão Sim — arquivos persistem indefinidamente
Funciona offline Não Sim
Saída determinística Não — recuperação dependente do modelo Sim — mesmo input → mesmo bundle sempre
Pressão na janela de contexto Alta — JSON bruto do Figma é grande e desestruturado Baixa — IR é pré-processado, tamanho limitado
Operações de escrita no Figma Sim (alguns servidores MCP) Não — export somente leitura
Spec de design no histórico do git Não Sim — commit do bundle, rastreie histórico de design
Setup de agente necessário Sim — configure servidor MCP por cliente de agente Não — qualquer agente que leia arquivos funciona
Chaves de string i18n Não no schema base do MCP do Figma Sim — stringRef.key no IR + strings.json
IR espacial / de layout Árvore de nós bruta do Figma (sem tipos semânticos de layout) IR tipado: stack / overlay / absolute / leaf
Sourcing de tokens Variáveis se definidas; caso contrário, valores brutos Variáveis → inferido por frequência → nenhum

MCP brilha para "editar Figma ao vivo" — bundles brilham para "construir UI de produção"

Esse é o resumo honesto. Se seu fluxo é exploração conversacional de design — "mude esse componente", "anote essa tela", "quais são os tokens de cor nesse frame" — a conexão ao vivo do MCP é o modelo certo. O agente é um colaborador no processo de design, e precisa de dados atuais para isso.

Se seu fluxo é construir UI de produção a partir de um design finalizado (ou quase finalizado) — implementar componentes, conectar estado, escrever testes — o modelo de bundle é melhor. Você quer a spec ancorada no seu repo, diferençável ao longo de iterações de design, legível por qualquer agente sem configuração, e determinística o suficiente para construir sobre ela.

Os dois modelos são complementares. Use MCP quando o design está em fluxo e você está iterando colaborativamente. Exporte um bundle do figmascope quando o design está estável e você está entregando a engenheiros para implementação. O bundle se torna a fonte de verdade contra a qual a implementação é construída — rastreável, revisável, reproduzível.