MCP Apps ou A2UI: qual padrão de UI para agentes usar?

Seu agente acabou de produzir a resposta certa, mas ela aparece como um bloco de texto. Dois padrões abertos resolvem esse problema, e discordam em quase todo o resto. MCP Apps entrega um pequeno aplicativo web que roda dentro de um iframe isolado. A2UI envia um plano em JSON e deixa o host desenhá-lo com seus próprios componentes nativos. Um dá ao servidor o controle dos pixels. O outro passa esse controle para o cliente.

Esta comparação analisa renderização, segurança, suporte de hosts e custo do dia a dia, e termina com uma tabela de decisão que você pode aplicar ao seu agente hoje. Todas as afirmações sobre as duas especificações vêm da documentação oficial do MCP, do site do projeto A2UI e do blog de desenvolvedores do Google, verificadas em outubro de 2026.

Dois padrões, duas filosofias

A diferença é fácil de explicar. MCP Apps trata a UI como um recurso que um servidor entrega. A2UI trata a UI como dados que um agente descreve. Tudo o que vem depois neste artigo decorre dessa única diferença.

O que o MCP Apps faz de fato

O MCP Apps começou como a proposta SEP-1865, em novembro de 2025. Anthropic, OpenAI e os mantenedores do projeto comunitário MCP-UI a escreveram em conjunto, com base no MCP-UI e no Apps SDK da OpenAI. Em janeiro de 2026, tornou-se a primeira extensão oficial do Model Context Protocol, com especificação própria datada de 2026-01-26 no repositório ext-apps.

O mecanismo reutiliza dois primitivos comuns do MCP, uma ferramenta e um recurso:

1. Uma ferramenta declara _meta.ui.resourceUri, que aponta para um recurso ui://.
2. O servidor entrega HTML para esse recurso com o tipo MIME text/html;profile=mcp-app.
3. O host carrega a página em um iframe isolado dentro da conversa.
4. O app e o host se comunicam por postMessage, usando um dialeto JSON-RPC com os métodos ui/, como ui/initialize.

Como a carga é código web comum, você escolhe o framework. O repositório ext-apps traz modelos iniciais para React, Vue, Svelte, Preact, Solid e JavaScript puro. A classe App de @modelcontextprotocol/ext-apps é um wrapper de conveniência, não um requisito. Você pode implementar o protocolo postMessage por conta própria se quiser menos dependências.

O que o A2UI faz de fato

A2UI, abreviação de Agent-to-User Interface, é o padrão aberto do Google, lançado sob a licença Apache 2.0 em dezembro de 2025. O agente não envia HTML. Ele transmite JSON declarativo que nomeia componentes e seus dados. O cliente mantém um catálogo de componentes em que confia, valida cada mensagem contra esse catálogo e mapeia o resultado para uma árvore de UI nativa.

O slogan do próprio Google resume a ideia: seguro como dados, expressivo como código. A especificação está na v0.9.1, com a v1.0 em fase de candidata em outubro de 2026. Existem renderizadores para Angular, Flutter e Lit, e o Google já usa o A2UI no Opal, no Gemini Enterprise e no Flutter GenUI SDK. As cargas trafegam sob o tipo MIME application/a2ui+json.

💡 Modelo mental: MCP Apps é "enviar um site em miniatura". A2UI é "enviar um projeto e deixar o host construí-lo com peças aprovadas".

Como cada padrão renderiza a UI

A rota do iframe

Com MCP Apps, o servidor decide como as coisas aparecem. O host fornece apenas a moldura, o sandbox e a ponte de mensagens. Isso dá a você a plataforma web completa: gráficos D3, cenas WebGL, visualizadores de PDF, mapas, um globo CesiumJS ou uma cena Three.js. Esses são exemplos reais do repositório ext-apps, ao lado de um alocador de orçamento, um mapa de calor de coortes e um monitor de sistema.

O preço é a deriva visual. Um iframe não herda o sistema de design do host de graça, então seu app pode parecer um objeto estranho dentro do chat. Ele também carrega o peso de uma página do navegador: seus próprios scripts, sua própria memória, seu próprio tempo de carregamento.

A rota do catálogo

Com A2UI, o cliente decide como as coisas aparecem. O agente diz "um cartão com um título, um gráfico e dois botões", e o cliente renderiza o próprio cartão, o próprio gráfico e os próprios botões. O tema vem do host, então o resultado combina com o app ao redor na web, no celular ou no desktop, sem uma webview.

O formato também é amigável para modelos de linguagem. É pequeno, estruturado e pensado para streaming, então um modelo pode emitir uma UI passo a passo enquanto o usuário a vê se montar. O limite é o catálogo: se o cliente não tiver um componente para o que você quer, não é possível inventar um dentro da carga.

Eis a comparação em um só quadro:

Segurança: sandbox ou lista de permissões

Duas ameaças muito diferentes estão por trás dos dois designs. Um isola código. O outro se recusa a aceitar código.

Como o MCP Apps contém os riscos

O app roda em um iframe isolado, então não consegue acessar o DOM da página pai, ler os cookies ou o armazenamento local do host, nem redirecionar a página pai. Todo o tráfego atravessa a fronteira postMessage, e o host decide o que passa. A defesa tem várias camadas:

• Templates predeclarados. Como as ferramentas referenciam recursos ui:// com antecedência, o host pode fazer o prefetch e revisar um template antes de qualquer ferramenta rodar.
• Content Security Policy. O campo _meta.ui.csp lista as origens externas das quais um app pode carregar conteúdo.
• Permissões. Um app solicita recursos como câmera ou microfone por meio de _meta.ui.permissions.
• Mensagens auditáveis. Tudo é JSON-RPC, então o host pode registrar tudo em log.
• Consentimento opcional. Os hosts podem pedir a confirmação do usuário antes de uma chamada de ferramenta iniciada pela interface ser executada.

Como o A2UI contém os riscos

O A2UI evita a questão do sandbox porque nunca executa nada. O renderizador aceita apenas JSON validado e apenas componentes que existem no catálogo. O Google chama isso de segurança baseada em capacidades: o cliente renderiza componentes confiáveis e mais nada.

Isso não torna o A2UI automaticamente seguro. Um botão do catálogo ainda pode disparar uma ação, então o cliente precisa autorizar cada ação declarada e validar cada carga. A lista de permissões protege a UI. Não protege sua lógica de negócio.

Riscos que nenhum dos dois padrões elimina

Os dois padrões movem conteúdo de um agente para uma tela, então ambos herdam as fraquezas do agente. Um modelo que lê uma página web hostil pode ser convencido a renderizar um formulário falso convincente, esteja ele em um iframe ou em um cartão do catálogo. Trate as chamadas de ferramenta disparadas por qualquer UI gerada como entrada não confiável: verifique as permissões no servidor, restrinja os tokens ao mínimo necessário e exija confirmação para qualquer coisa que gaste dinheiro ou altere dados.

Quem suporta o quê hoje

Hosts do MCP Apps

O suporte de hosts é o argumento mais forte a favor do MCP Apps neste momento. A documentação oficial lista Claude, Claude Desktop, VS Code GitHub Copilot, Microsoft 365 Copilot, Goose, Postman, MCPJam e Archestra.AI, e o ChatGPT também os renderiza. O projeto MCP mantém uma matriz de clientes, e ela importa: o suporte à UI de apps é mais restrito do que o suporte às ferramentas básicas do MCP. Um cliente que chama suas ferramentas ainda pode ignorar seu recurso ui://.

Se você mesmo constrói um host, tem dois caminhos. O pacote @mcp-ui/client fornece componentes React, e o módulo App Bridge do SDK cuida da renderização em sandbox, da troca de mensagens, do proxy de chamadas de ferramenta e da aplicação de políticas.

Renderizadores e transportes do A2UI

O suporte ao A2UI depende do renderizador que o seu cliente traz, não de uma lista de produtos de chat. Você escolhe Angular, Flutter ou Lit, define seu catálogo e conecta um transporte. O protocolo A2A transporta o A2UI entre agentes, e o AG-UI, o protocolo da CopilotKit, anuncia compatibilidade desde o primeiro dia. O A2UI também pode rodar sobre o MCP: as cargas chegam por resources/read para telas estáticas ou por tools/call para telas dinâmicas, sob um esquema de URI a2ui://.

Tabela de decisão por cenário

Escolha pelo trabalho, não pela marca. Esta tabela mostra como as equipes costumam dividir as tarefas:

Escolha o MCP Apps quando

Escolha-o quando você já tem um produto web e quer colocá-lo dentro do chat. Seu servidor mantém a lógica, você controla cada pixel e pode reaproveitar componentes React que já tem. Escolha-o também quando a velocidade de prototipagem importa: um único arquivo HTML basta para entregar.

Escolha o A2UI quando

Escolha-o quando a tela não é conhecida de antemão. Um agente que responde "mostre o último trimestre" com uma tabela hoje e um gráfico amanhã se adapta a um catálogo muito melhor do que a uma página feita à mão para cada caso. Escolha-o também quando seu cliente é nativo, ou quando sua equipe de segurança não aprovar scripts de terceiros no chat.

Erros que custam semanas

• Construir um catálogo pequeno demais. Os agentes então recorrem a texto simples e os usuários não percebem ganho algum.
• Tratar o iframe como fronteira para seus dados. O sandbox protege o host, não os seus tokens.
• Pular o texto de fallback. Os MCP Apps são opcionais, então os servidores devem manter um caminho somente com texto para hosts que não renderizam UI.
• Acoplar o código rigidamente à v0.9.1. O A2UI ainda caminha para a v1.0, então isole seu renderizador atrás de um único adaptador.

Usando os dois juntos

A escolha não é exclusiva. O blog de desenvolvedores do Google, publicado em 17 de junho de 2026, descreve três padrões de integração, e eles mudam o que significa "escolher um".

Três padrões de combinação

1. A2UI sobre servidores MCP. O servidor MCP entrega cargas A2UI por meio de recursos ou resultados de ferramentas, usando o esquema a2ui://. Não é preciso iframe.
2. MCP Apps dentro do A2UI. Um componente wrapper A2UI personalizado incorpora um MCP App, com o estado sincronizado por meio de loops de eventos e devolvido ao agente do backend.
3. A2UI dentro do MCP Apps. O MCP App inclui o próprio renderizador A2UI, o que leva UI generativa a hosts que não falam A2UI nativamente.

Um conjunto padrão sensato

Para a maioria das equipes, uma divisão por trabalho funciona. Coloque superfícies estáveis e decisivas, como aprovações, configurações e telas de conta, em MCP Apps. Coloque superfícies flexíveis e geradas, como relatórios e resumos, em A2UI. Sirva os dois a partir do mesmo servidor MCP para que seu agente mantenha uma única conexão. O padrão 3 é sua saída de emergência quando um host não tem renderizador.

Revise a divisão a cada trimestre. Se uma superfície gerada começar a precisar de gráficos personalizados que o catálogo não consegue desenhar, aquela tela ultrapassou o A2UI e pertence a um MCP App. Se um MCP App continuar sendo refeito para cada novo formato de dados, ele se torna candidato a um catálogo.

Use o GPT 5 Structured na PicassoIA

Escrever cargas A2UI à mão fica cansativo, e um modelo de linguagem que devolve JSON estrito é um parceiro natural de rascunho. O GPT 5 Structured na PicassoIA foi feito exatamente para isso: você define um esquema JSON, e cada resposta segue esse esquema.

1. Abra a página do modelo e escolha um nível no campo model: gpt-5, gpt-5-mini ou gpt-5-nano.
2. Cole seu catálogo em instructions. Liste os componentes que seu cliente aceita, com suas propriedades.
3. Descreva a tela em prompt, por exemplo "um resumo de pedido com uma tabela de itens e um botão de confirmação".
4. Defina json_schema como o esquema de mensagem da especificação A2UI. Use json_schema em vez de simple_schema, porque a versão simples não aceita objetos aninhados.
5. Mantenha reasoning_effort em minimal para rascunhos rápidos. Para layouts densos, aumente-o e eleve max_output_tokens, porque um raciocínio alto pode consumir todo o orçamento e devolver uma resposta vazia.
6. Valide a saída contra a especificação antes de renderizar.

💡 Trate a saída do modelo como um rascunho. O validador do seu renderizador é a última barreira, exatamente como o modelo de segurança do A2UI pretende.

Quer comparar rascunhos de outros modelos? O Claude Sonnet 5 e o Gemini 3.5 Flash também estão disponíveis na PicassoIA, então você pode rodar o mesmo catálogo e o mesmo prompt em cada um e ficar com o resultado mais limpo.

Experimente suas próprias imagens hoje

Qualquer que seja o padrão escolhido, as telas do seu agente precisam de imagens: miniaturas de produtos, banners de destaque, fotos de cabeçalho para relatórios. O MCP Apps renderiza imagens como HTML comum. O A2UI as renderiza por meio de qualquer componente de imagem que o seu catálogo definir. De qualquer forma, você precisa das imagens antes.

A PicassoIA reúne os geradores em um só lugar. O Seedream 5 Pro, o Flux 2 Pro, o Imagen 4 e o PicassoIA Image estão todos na coleção de texto para imagem, para que você possa rodar um prompt em vários modelos e ficar com a versão que se encaixa no seu layout. A PicassoIA também expõe seus geradores por meio de conexões MCP, então um agente que fale o protocolo discutido acima pode solicitar imagens diretamente.

Abra a coleção, escreva um prompt para o seu próximo cartão ou banner e gere algumas variantes. Escolha uma tela do seu próprio agente, dê a ela uma imagem real e veja como o lado visual acompanha rapidamente a lógica.