agent-browser ou mare-browser? Aqui está como eu realmente escolho.

Se você está construindo aplicativos web com um agente de IA, você encontra a mesma barreira rapidamente: o modelo pode escrever o código, mas não pode ver o que o código faz em um navegador real. Ele não pode clicar no botão, assistir ao login falhar, ler o erro do console ou verificar o que a API realmente retornou. É codificação às cegas.

É isso que a automação do navegador corrige. Você dá ao agente um navegador real que ele pode controlar — abrir uma página, preencher um formulário, clicar, ler o DOM, observar a rede — então o ciclo deixa de ser "IA escreve código, você testa, você descreve o bug, IA adivinha" e se torna "IA escreve código, IA testa, IA lê a falha, IA corrige". Para desenvolvimento e teste, essa é a diferença entre um assistente e um par real.

A maneira como você conecta isso é um servidor MCP — um pequeno programa que expõe ações do navegador como ferramentas que seu agente pode chamar. Ambas as ferramentas neste post são exatamente isso:

• agent-browser é a ferramenta de automação de navegador da Vercel para agentes — um CLI nativo rápido com um enorme conjunto de recursos e um modo MCP. Pense em "fazer quase qualquer coisa em um navegador, em qualquer lugar."
• mare-browser-mcp é meu servidor MCP leve, voltado para depuração, construído sobre o Playwright. Pense em "dar ao agente os mesmos sinais do DevTools que eu olharia pessoalmente."

Então, qual você instala? Alguém me perguntou na semana passada: "O agent-browser da Vercel tem 36.000 estrelas. Por que você ainda está trabalhando no seu pequeno navegador MCP?"

Uma pergunta justa. E a resposta honesta é mais interessante do que "o meu é melhor", porque não é. Eles nem são realmente o mesmo tipo de ferramenta.

Então, em vez de fingir que há um vencedor, deixe-me contar como eu realmente decido qual deles usar. Porque eu uso ambos.

Primeiro, sejamos honestos sobre o agent-browser

agent-browser é excelente. Eu não vou fazer a coisa de menosprezar um concorrente com elogios vagos. É um CLI nativo em Rust, apoiado pela Vercel, com mais de cem colaboradores e uma lista de recursos que é genuinamente intimidadora:

• Um instantâneo da árvore de acessibilidade com referências estáveis (@e1, @e2) — que é a maneira correta de deixar um LLM apontar para elementos
• Localizadores semânticos (find role, find label, find testid)
• Aba, quadros, diálogos, gravação HAR, rastreamento, profiler
• Introspecção do React DevTools e Web Vitals
• Simulação de rede, cookies, cofre de autenticação, um servidor MCP com perfis de ferramentas
• Suporte ao simulador iOS e um conjunto de provedores de navegador em nuvem (Browserbase, Kernel e amigos)
• Diferença visual + instantânea

Se você me desse uma folha em branco e dissesse "escolha a ferramenta de automação de navegador de propósito geral mais capaz para agentes", eu apontaria para o agent-browser e não me sentiria em conflito sobre isso.

Então, por que mare-browser-mcp existe?

Porque amplitude e adequação são coisas diferentes

mare é pequeno de propósito. É um servidor MCP baseado em Playwright com cerca de uma dúzia de ferramentas, e todo o conjunto é voltado para um trabalho: depurar um aplicativo web que você está ativamente construindo, com um agente de IA ao seu lado.

É isso. Esse é o nicho. Não faz iOS. Não faz navegadores em nuvem. Não faz arquivos HAR. E nunca vai ter mais recursos do que um projeto da Vercel — sou uma pessoa, e não estou tentando.

O que ele tem é um centro de gravidade diferente. A ferramenta principal é browser_debug, que retorna o console, as requisições de rede (com cargas úteis, corpos de resposta, códigos de status e tempos), a URL atual, o título e quaisquer diálogos — em uma única chamada. Quando você está depurando seu próprio aplicativo, essa única chamada é basicamente todo o jogo. (Eu escrevi uma peça separada sobre por que a telemetria supera capturas de tela, então não vou rehashar aqui.)

No agent-browser, essa mesma informação está espalhada por console, errors, network requests, e network request <id>. Nada de errado com isso — é um design mais granular e mais geral. Mas para meu ciclo, uma chamada supera quatro.

Então aqui está a decisão real

Eu parei de pensar nisso como "qual ferramenta é melhor" e comecei a pensar sobre o que estou realmente fazendo naquela hora.

Use o agent-browser quando:

• Você precisa de um navegador em algum lugar que não seja seu laptop — CI, serverless, um provedor em nuvem
• Você está testando em um Safari móvel real ou em dispositivos emulados
• Você está fazendo automação ampla: muitas abas, manipulação de quadros, rastreamentos gravados, diferenças de regressão visual
• Você quer introspecção do React fiber ou Web Vitals de forma nativa
• Você quer uma ferramenta madura, bem equipada, com uma cadência de lançamentos e uma grande comunidade por trás dela
• Você está raspando ou automatizando em muitos sites e quer furtividade, proxies, listas de permissão de domínio

Use o mare quando:

• Você está construindo um aplicativo web e depurando-o localmente com um agente
• O bug é "o botão não faz nada" e a resposta real é um 401 com o nome de campo errado no corpo da requisição
• Você quer que o modelo olhe para cargas úteis de rede e erros do console, não capturas de tela
• Você quer uma superfície de ferramenta pequena e legível que o modelo não se perca
• Você faz login uma vez manualmente (ele roda com interface gráfica por padrão) e depois deixa o agente trabalhar na sua sessão real
• Você quer abrir browser_eval e investigar o estado de window ou estilos computados

Note que essas listas mal se sobrepõem. Esse é o ponto. Uma é uma faca suíça. A outra é uma chave de fenda que eu afiei para se encaixar em um único parafuso que eu giro quarenta vezes por dia.

A lacuna honesta que eu acabei de fechar

Por um tempo, havia um lugar onde o mare era genuinamente pior, não apenas menor — e vale a pena admitir porque é o tipo de bug que mente para você silenciosamente.

O mare também tem instantâneas baseadas em referência (browser_snapshot lhe dá e1, e2, ...), mas até recentemente essas referências eram resolvidas através de um caminho CSS gerado como #list > li:nth-of-type(3) > button. Pense nisso como direções: "a terceira casa na segunda rua." Se a página re-renderizasse entre a instantânea e o clique — uma linha inserida, uma lista reordenada, React reconciliando — essa "terceira casa" poderia agora ser uma casa diferente. E o mare clicaria nela. Com confiança. Sem te avisar.

Para uma ferramenta de depuração, essa é a pior falha possível: não gera erro, engana.

Eu acabei de reescrevê-la para que cada referência esteja fixada no exato elemento que foi capturado (via um atributo único no próprio nó). Agora click e3 ou atinge aquele elemento ou falha de forma clara e te diz para re-snapshottar. Não pode mais flutuar silenciosamente. O agent-browser já acertou isso com seu sistema de referência; o mare também acertou agora.

Estou te contando isso em parte porque é uma melhoria real, e em parte porque eu acho que "aqui está onde minha ferramenta estava errada e aqui está como eu consertei" é mais confiável do que uma tabela de recursos.

Você pode usar ambos

Isso não é uma luta de galo. Ambos são servidores MCP. Ambos podem ser registrados com o mesmo agente ao mesmo tempo. Eu realmente uso o mare para o ciclo interno de construir algo — o ciclo apertado de escrever-testar-ler-corrigir no localhost.