Playwright MCP vs Tap vs Browserbase — onde vivem as credenciais
Se você avaliou servidores MCP para automação de navegador, viu três opções credíveis: Playwright MCP da Microsoft, Browserbase + Stagehand e Tap. Eles parecem substitutos. Eles não são.
Mesmo espaço de ferramenta. Três produtos diferentes.
Cada um responde a uma pergunta diferente. O eixo arquitetônico que os separa: onde o navegador realmente roda, e quais credenciais ele vê?
| Onde o navegador roda | Logado / cookies | Tokens por execução | Limite de confiança | |
|---|---|---|---|---|
| Playwright MCP | Playwright local (headless ou --extension) |
△ --extension reutiliza seu Chrome; headless = nenhum |
Por chamada (LLM em tempo de execução) | Sua máquina |
| Browserbase + Stagehand | Nuvem do Browserbase | ✗ credenciais devem ser enviadas | Por chamada (LLM em tempo de execução) | Nuvem do Browserbase |
| Tap | Seu próprio Chrome (extensão) | ✓ usa sua sessão ao vivo | 0 (reprodução determinística) | Nada sai da máquina |
Tokens: a arquitetura, não a engenharia
Para "raspar as 30 principais histórias do HN como JSON", ferramentas de extração em tempo de execução chamam um LLM a cada invocação. Medimos ~9.600 tokens/chamada em um loop de extração ingênuo.
Tap compila um plano determinístico de 11 operações uma vez com IA, e então reproduz a zero tokens. Em 100 consultas entre eventos de desvio, isso é 849× mais barato do que re-extrair toda vez.
Essa vantagem só existe porque a carga de trabalho se repete. Para pesquisa de uma única vez, a extração em tempo de execução é a ferramenta certa. A matemática de amortização do Tap precisa de "Eu vou rodar isso novamente" para estar na mesa.
Credenciais: a dimensão onde eles param de ser substitutos
Para trabalho não autenticado (HN, Wikipedia, docs) — escolha pelo preço. Não importa.
Para qualquer coisa atrás de um login, isso domina tudo o mais:
-
Playwright MCP headless: sem cookies. A flag
--extension(recente, boa) se conecta ao seu Chrome real — fecha a maior parte da lacuna de autenticação. - Browserbase + Stagehand: seus cookies vão para a nuvem deles. Custo real que algumas equipes aceitam (SaaS multi-tenant com requisitos de isolamento), custo real que outras não aceitarão (fundador solo; credenciais restritas pelo SOC2).
- Tap: nada sai da máquina. O navegador É seu. Os cookies SÃO seus cookies. O servidor MCP orquestra, mas nunca os vê.
Como escolher (uma pergunta cada)
- O trabalho precisa de uma sessão logada? Não → Playwright MCP. Sim → continue.
- É aceitável enviar essas credenciais para uma nuvem de terceiros? Sim → Browserbase + Stagehand. Não → continue.
- Fluxo de trabalho de uma única vez ou repetido? Uma vez → Playwright MCP
--extension. Repetido → Tap.
Inverso: cada um perde onde os outros ganham.
- Tap perde em pesquisa de site novo de uma única vez — tempo de autoria > extração em tempo de execução.
- Playwright MCP perde em cargas de trabalho repetidas contra sites em desvio — re-pague tokens de extração para sempre, absorva falhas silenciosas.
- Browserbase perde quando credenciais não podem legal ou operacionalmente sair da máquina.
Versão completa com os dados de custo de token + aprofundamento em manuseio de desvio: Playwright MCP vs Tap vs Browserbase →
Instalação do Tap: brew install LeonTing1010/tap/taprun. Grátis durante v0.x.
As empresas brasileiras que utilizam automação de navegador precisam entender as diferenças entre essas ferramentas para escolher a mais adequada. A escolha impacta diretamente na segurança e eficiência dos processos de scraping e automação. A decisão sobre onde as credenciais são geridas pode afetar a conformidade e a privacidade dos dados.
