MCP Apps: Quando as Ferramentas de IA Ganham Interface — e o Chatbot Puro Acaba

Desde que os primeiros assistentes de IA chegaram ao mercado, a interação seguia um modelo básico: você digita, o modelo responde em texto. Às vezes com código, às vezes com markdown formatado — mas sempre texto plano dentro de uma caixa de chat.

Esse modelo chegou ao seu limite.

Em janeiro de 2026, a Anthropic lançou o MCP Apps — uma extensão oficial da spec do Model Context Protocol que permite que ferramentas retornem interfaces interativas renderizadas diretamente dentro da conversa. Calendários. Formulários de múltiplos passos. Dashboards de dados. Timelines visuais. Componentes de seleção complexa. Tudo dentro do chat, sem abrir outra aba.

Nove parceiros lançaram no dia 1: Amplitude, Asana, Box, Canva, Clay, Figma, Hex, monday.com e Slack. Salesforce já confirmou que está a caminho.

Isso não é uma feature nova no Claude. É uma mudança de paradigma na forma como agentes interagem com o mundo — e tem implicações diretas para como você vai projetar sistemas agênticos a partir de agora.

O Problema que o MCP Apps Resolve

Para entender o impacto, primeiro entenda a limitação que existia antes.

Quando um agente chama uma ferramenta e recebe dados de volta, ele precisava transformar esses dados em linguagem natural para te apresentar. Você pedia "mostre meu sprint atual" e o agente escrevia algo como:

"Você tem 12 tarefas no sprint atual. 4 estão concluídas (Deploy frontend, Migração DB, Review de segurança, Atualização de deps). 5 estão em progresso (Feature auth, Refactor API, Testes e2e, Design system, Documentação). 3 estão bloqueadas (Integração Stripe — aguardando credenciais; Notificações email — bloqueado por infraestrutura; Dashboard analytics — aguardando design aprovado)."

Funcional? Sim. Mas tente fazer triagem de prioridades em texto corrido. Tente arrastar uma tarefa de "bloqueada" para "em progresso" através de uma resposta de texto. Texto é uma representação pobre de dados estruturados e ações interativas.

O MCP Apps resolve isso na raiz: a ferramenta retorna uma interface, não dados brutos para o modelo interpretar.

Como Funciona Tecnicamente

A spec do MCP Apps (formalizada como SEP-1865) define que servidores MCP podem declarar UI resources — templates HTML pré-declarados que são renderizados em iframes sandboxed dentro do cliente.

A arquitetura tem três partes:

┌─────────────────────────────────────────────────────┐
│                   Cliente MCP (Claude)               │
│                                                     │
│  ┌─────────────────────┐  ┌───────────────────────┐ │
│  │   Conversa Normal   │  │    MCP App Frame      │ │
│  │                     │  │  (iframe sandboxed)   │ │
│  │  "Aqui está o seu   │  │  ┌─────────────────┐  │ │
│  │   sprint atual:"    │  │  │  [Kanban board  │  │ │
│  │                     │  │  │   interativo]   │  │ │
│  │                     │  │  │                 │  │ │
│  │                     │  │  │  Todo | Doing   │  │ │
│  │                     │  │  │  Done | Blocked │  │ │
│  └─────────────────────┘  └─────────────────────┘  │ │
└─────────────────────────────────────────────────────┘

A comunicação entre o iframe e o cliente acontece via JSON-RPC — o mesmo protocolo base do MCP. Ações do usuário dentro da interface (clicar num botão, preencher um campo, arrastar um item) geram chamadas de ferramenta que o agente processa e responde.

Por Que iframes, Não Componentes Nativos?

A escolha de iframes sandboxed não é acidente — é segurança por design. Componentes nativos de UI teriam acesso ao DOM do cliente e poderiam executar JavaScript arbitrário no contexto da aplicação. Um servidor MCP malicioso poderia, em tese, fazer XSS ou roubar dados.

Com iframes sandboxed e templates pré-declarados (não código dinâmico), o cliente pode revisar o template antes de renderizar. Se você usa o Claude com um servidor MCP de terceiros, o cliente verifica o template HTML declarado antes de exibir qualquer coisa. Sem injeção dinâmica de código.

<!-- Exemplo de template pré-declarado (simplificado) -->
<mcp-app-template id="sprint-board">
  <style>/* estilos declarados e auditáveis */</style>
  <div class="kanban">
    <column data-status="todo">{{#each todoTasks}}<task-card>{{title}}</task-card>{{/each}}</column>
    <column data-status="doing">{{#each doingTasks}}<task-card>{{title}}</task-card>{{/each}}</column>
    <column data-status="done">{{#each doneTasks}}<task-card>{{title}}</task-card>{{/each}}</column>
  </div>
  <script>
    // Apenas comunicação via postMessage com o host
    document.querySelectorAll('.task-card').forEach(card => {
      card.addEventListener('click', () => {
        parent.postMessage({ type: 'tool_call', tool: 'open_task', args: { id: card.dataset.id }}, '*');
      });
    });
  </script>
</mcp-app-template>

O Que os 9 Parceiros Lançaram

O que foi para produção no dia do lançamento não são demos conceituais — são integrações reais com ferramentas que devs e tech leads usam todo dia:

Asana — Visualização de projetos, sprints e tarefas como boards interativos dentro da conversa. Você pode criar subtarefas, mudar status e reatribuir responsáveis sem sair do chat.

Figma — Renderização de frames e componentes do Figma diretamente no chat. Perfeito para contexto de design em conversas com agentes de desenvolvimento — o agente pode "ver" o design sem você copiar screenshots.

Slack — Threads e canais relevantes aparecem como interface navegável. Você pode reagir, responder e marcar mensagens como lidas sem trocar de janela.

Amplitude — Dashboards de produto com gráficos interativos. Ao invés do agente descrever métricas em texto, você vê o funil de conversão diretamente na conversa.

Hex — Notebooks analíticos com resultados visuais. Para quem faz análise de dados, isso é enorme: a interface de notebook aparece dentro do contexto agêntico.

Canva — Edição visual de templates dentro da conversa. O agente sugere um design, você ajusta dentro do chat.

Clay — Enriquecimento e visualização de listas de contatos de forma interativa.

Box — Navegação de arquivos e visualização de documentos.

monday.com — Boards de projetos com atualização em tempo real.

O denominador comum: todos são ferramentas onde a interface importa — onde texto puro degrada a experiência e a capacidade de tomar ação.

As Implicações para Quem Constrói Sistemas Agênticos

1. A UX do agente passa a ser responsabilidade do desenvolvedor do servidor

Até agora, a "interface" de um sistema agêntico era basicamente o chat do cliente. O servidor MCP expunha ferramentas, o cliente renderizava a resposta em markdown, e você não tinha muito controle sobre como o output aparecia para o usuário.

Com MCP Apps, o servidor define a experiência. Se você está construindo um servidor MCP para o sistema de CI/CD da sua empresa, você pode retornar uma visualização do pipeline com status em tempo real, não um JSON que o modelo vai tentar descrever em prosa.

Implicação prática: A experiência do usuário de sistemas agênticos vai diferenciar produtos. Dois servidores MCP que expõem o mesmo Jira vão ter experiências completamente diferentes se um usa MCP Apps e o outro não.

2. O loop de ação fica dentro da conversa

Um dos maiores atritos em sistemas agênticos hoje é o "pulo" entre contexto (conversa) e ação (ir pra ferramenta, fazer a coisa, voltar). Com MCP Apps, ações complexas acontecem dentro da conversa.

Antes:
→ Agente: "Encontrei 3 PRs aguardando review. Quer que eu abra o GitHub?"
→ Usuário: [abre GitHub, revisa PRs, aprova ou rejeita, volta ao chat]
→ Usuário: "Ok, aprovei o #1247 e #1248. O #1249 precisei de ajustes..."

Depois:
→ Agente: "Encontrei 3 PRs aguardando review." [renderiza lista com diff resumido, botões de approve/request changes]
→ Usuário: [aprova #1247 e #1248 diretamente, adiciona comentário no #1249, tudo no chat]
→ Agente: [processa as ações] "Feito. #1247 e #1248 aprovados, comentário adicionado no #1249."

Menos fricção = mais tasks concluídas por sessão. Para sistemas Freelance Agentic, isso amplifica a produtividade de forma não-linear.

3. Sistemas multi-agente ficam mais observáveis

Um problema crônico em sistemas multi-agente é entender o que está acontecendo. Os agentes trabalham, geram texto, você lê logs... e fica difícil ter uma visão do estado do sistema em tempo real.

Com MCP Apps, um servidor de observabilidade pode retornar um dashboard ao vivo do estado dos agentes — quais estão rodando, quais esperando, onde estão os gargalos — renderizado diretamente na sessão do Regente.

O Que Ainda Não Funciona (e É Importante Saber)

MCP Apps é promissor, mas vale ser honesto sobre as limitações atuais:

Suporte de clientes ainda limitado. ChatGPT, Claude, goose e VS Code suportam a spec. Cursor, Windsurf e outros IDEs agênticos ainda estão implementando. Se parte do seu workflow usa um cliente que não suporta, você não vai ver as UIs — vai receber o fallback em texto.

Complexidade de desenvolvimento aumentou. Criar um servidor MCP agora pode envolver criar templates de UI, não só lógica de ferramenta. Para equipes que não têm experiência com frontend, isso pode ser uma barreira.

Performance de iframes. Iframes sandboxed têm overhead. Para interfaces simples, é imperceptível. Para dashboards com muitos dados ou animações, pode ser perceptível.

Ecossistema de componentes ainda immaturo. Não existe (ainda) uma biblioteca padrão de componentes para MCP Apps como existe no React ecosystem. Cada servidor precisa construir os seus ou aguardar que surjam bibliotecas da comunidade.

Como Isso Se Conecta com MCP Sendo Padrão Aberto

Não é coincidência que a spec do MCP Apps (SEP-1865) foi desenvolvida colaborativamente entre times da OpenAI e da Anthropic. Quando um protocolo tem governança aberta, extensões como o MCP Apps nascem como padrão, não como feature proprietária de um cliente.

O modelo goose do Block já implementa MCP Apps. O VS Code também. Como exploramos na semana passada, o padrão aberto sob a AAIF garante que extensões como essa sejam desenvolvidas para o ecossistema inteiro, não para um único vendor.

O Que Fazer Esta Semana

Se você já tem servidores MCP nos seus projetos, vale começar a explorar onde MCP Apps faz sentido. A pergunta certa é: em quais ferramentas a interface importa mais do que texto?

Candidatos óbvios:

• Qualquer ferramenta com dados estruturados (tabelas, kanban, timelines)
• Fluxos de aprovação com múltiplas opções
• Visualizações de estado de sistemas complexos
• Inputs que são difíceis de fazer via linguagem natural (selecionar itens, reordenar, filtrar)

O SDK do MCP Apps está disponível no repositório oficial do protocol. A documentação ainda está evoluindo, mas os exemplos dos parceiros lançadores são bons pontos de partida.

O chatbot puro não vai morrer amanhã. Mas os sistemas agênticos que terão tracção em 2026 vão ser aqueles que combinam o poder do raciocínio dos LLMs com interfaces que permitem ação eficiente. MCP Apps é o protocolo que une esses dois mundos.

Qual ferramenta do seu stack você primeiro integraria com MCP Apps? O sistema que vem à minha mente imediatamente é qualquer coisa de observabilidade — ver o estado dos agentes em tempo real dentro da sessão de desenvolvimento seria um ganho enorme de contexto.

Referências Técnicas

Spec e Documentação

• MCP Apps: Bringing UI Capabilities to MCP Clients — MCP Blog Oficial
• MCP Apps: Extending servers with interactive user interfaces — Spec original (novembro 2025)
• MCP Apps are here: Rendering interactive UIs in AI clients — WorkOS, análise técnica detalhada

Análises e Cobertura

• Anthropic extends MCP with a UI framework — The New Stack
• Claude supports MCP Apps, presents UI within chat window — The Register
• Anthropic and OpenAI Join Forces to Standardize Interactive AI Interfaces — Inkeep

Posts Relacionados

• MCP Virou Padrão Aberto da Indústria — AAIF e o que muda
• Freelance Agentic: 1 Dev, 10 Agentes — Como sistemas agênticos funcionam na prática
• A Guerra dos Agentes Autônomos em 2026 — Panorama do ecossistema