Eu Deixei Claude Usar Meu Telefone e Ele Testou Meu App

Sou o criador do Drengr, um servidor MCP que dá aos agentes de IA olhos e mãos em dispositivos móveis. Comecei este blog para compartilhar a engenharia por trás disso. Sem fingir ser um observador neutro escrevendo um artigo reflexivo — eu construí isso, e estou aqui para falar sobre.

A configuração: 90 segundos

Conectei um telefone Android ao meu MacBook. Abri o Claude Desktop. Adicionei uma linha à configuração do MCP:

{
  "mcpServers": {
    "drengr": {
      "command": "drengr",
      "args": ["mcp"]
    }
  }
}

Essa é toda a configuração. Sem Appium. Sem grid Selenium. Sem variáveis de ambiente apontando para Java homes e caminhos do Android SDK. Apenas npm install -g drengr, conecte o telefone e diga ao Claude o que fazer.

"Abra o YouTube e encontre um vídeo sobre servidores MCP"

Eu digitei isso no Claude. Aqui está o que aconteceu nos próximos 40 segundos:

1. Claude chamou drengr_look — obteve uma descrição em texto da tela inicial
2. Ele viu o YouTube na lista de aplicativos e chamou drengr_do para abri-lo
3. YouTube abriu. Claude chamou drengr_look novamente — obteve o feed inicial do YouTube como uma lista de elementos rotulados
4. Ele tocou na barra de pesquisa, digitou "servidores MCP" e pressionou buscar
5. Os resultados apareceram. Claude leu os títulos e tocou no vídeo mais relevante
6. O vídeo começou a tocar. Claude confirmou: "Encontrado e tocando 'MCP Server Explained' por IBM Technology"

Seis ações. Sem scripts. Sem seletores. Claude leu a tela, tomou decisões e executou ações — exatamente como um humano faria, exceto que levou 40 segundos em vez de 2 minutos.

O momento em que ficou interessante

Eu então perguntei: "Agora vá para Shorts e deslize por alguns."

Claude navegou até a aba Shorts, deslizou para cima três vezes, leu os títulos de cada short e me disse o que viu. Ele lidou com a rolagem vertical, o reprodutor de vídeo em tela cheia, os botões sobrepostos — tudo isso sem nenhuma configuração especial.

Esse é o tipo de interação que quebra estruturas de teste tradicionais. Shorts usa um renderizador personalizado, a árvore de UI é mínima, o comportamento de rolagem é não padrão. Um teste baseado em seletores precisaria de um manipulador personalizado para cada peculiaridade. Claude apenas... usou o aplicativo.

O que realmente está acontecendo por trás das câmeras

Claude não vê o telefone diretamente. Drengr fica entre:

Claude → chama ferramentas MCP → Drengr → fala com o dispositivo → Telefone

Drengr lida com as partes complicadas:

• Capturando a tela e analisando a árvore de UI em um formato que a IA pode ler
• Traduzindo "toque no elemento 3" na ordem correta da plataforma
• Relatando o que mudou após cada ação (o relatório de situação)
• Detectando se o aplicativo travou ou a UI ficou presa

Claude lida com as partes inteligentes:

• Olhando para a descrição da tela e decidindo o que fazer
• Adaptando-se quando algo inesperado acontece
• Sabendo quando a tarefa está completa

Essa separação é deliberada. A IA é o cérebro, Drengr são as mãos. Quando melhores modelos de IA surgirem, Drengr não precisa mudar — as mãos permanecem as mesmas, o cérebro fica mais inteligente.

As coisas que me surpreenderam

Ele se recupera de erros. Em um momento, Claude tocou no vídeo errado. Ele percebeu que o título não correspondia ao que esperava, pressionou voltar e escolheu o certo. Sem lógica de repetição, sem código de tratamento de erros — a IA apenas se adaptou.

Funciona entre aplicativos. Pedi ao Claude para "verificar minhas notificações" após o teste do YouTube. Ele pressionou o botão home, puxou a barra de notificações, leu as notificações e as resumiu. Nenhuma configuração específica do aplicativo necessária.

O modo texto é quase sempre suficiente. Em cerca de ~30 ações durante a sessão, Claude só precisou da captura de tela anotada duas vezes — ambas em telas com conteúdo renderizado de forma personalizada. O restante funcionou com a descrição em texto de ~300 tokens. Isso é 10x mais barato do que enviar imagens a cada passo.

O que ele não pode fazer (ainda)

Não vou fingir que isso substitui os testes manuais hoje. Alguns limites são reais:

• Velocidade — Cada passo leva de 2 a 3 segundos (tempo de ida e volta do LLM). Um testador humano pode tocar mais rápido. Mas o humano não pode executar 50 fluxos de teste em paralelo em uma fazenda de dispositivos.
• Verificação visual — Claude pode dizer se um elemento existe, mas não se "parece certo". Cor, alinhamento, espaçamento — isso precisa de olhos humanos ou uma ferramenta de regressão visual.
• Gestos complexos — Toques padrão, deslizes, toques longos e zooms com pinça funcionam. Mas padrões de multi-toque específicos de jogos ainda não estão disponíveis.

O ponto ideal hoje é o teste de regressão: "o fluxo de checkout ainda funciona após essa implantação?" Essa é a parte de 80% do tempo de QA que é gasta executando os mesmos fluxos a cada sprint. Deixe a IA lidar com isso e deixe os humanos focarem nos testes exploratórios.

Tente você mesmo

npm install -g drengr
drengr doctor          # verifique sua configuração
drengr setup --client claude-desktop  # gere a configuração do MCP

Conecte um dispositivo, abra seu cliente de IA e diga o que testar. A primeira vez que um agente de IA navega pelo seu aplicativo sem uma única linha de código de teste, você entenderá por que eu construí isso.