Playwright MCP: como configurar e testar seu site com IA

O servidor Playwright MCP, da Microsoft, conecta agentes como Claude Code, Codex, Cursor e o agente do Copilot no VS Code ao Playwright, o framework de automação de navegadores. Minha recomendação: use essa conexão para verificações exploratórias e investigação de falhas. Depois, transforme as descobertas importantes em testes revisados e repetíveis.

Como o Playwright MCP funciona na prática

O agente recebe controles do navegador e uma descrição estruturada da página. MCP, sigla de Model Context Protocol, é a conexão que permite ao agente chamar essas ferramentas. O servidor executa as ações no navegador; o agente decide qual será a próxima.

Pense no snapshot de acessibilidade como o mapa de um prédio: ele identifica salas e portas pela função e pelo nome. Da mesma forma, o snapshot de uma página descreve botões, links, campos de texto e seus nomes acessíveis. Com essa estrutura, o agente pode escolher um alvo sem precisar adivinhar onde clicar em uma imagem. O fluxo padrão dispensa um modelo de visão. Visão geral da Microsoft

Antes de instalar, vale escolher a abordagem. A Microsoft agora também indica o Playwright CLI com skills para quem usa agentes de programação, enquanto apresenta o MCP como uma opção útil para manter o estado do navegador e inspecionar repetidamente a estrutura da página. Escolha o MCP quando essa interação contínua fizer sentido no seu fluxo de trabalho; compare com a opção via CLI se o agente já trabalha bem com comandos de shell. Nenhuma das escolhas, por si só, comprova que uma jornada do cliente passou no teste. Comparação da Microsoft entre MCP e CLI

Para conhecer o conjunto mais amplo de ferramentas, veja nossa seleção dos melhores servidores MCP para 2026.

Como instalar no Claude Code, Codex, Cursor ou VS Code

Você precisa do Node.js 18 ou superior e de um cliente compatível com MCP. Os comandos e as configurações abaixo reproduzem os exemplos do README da Microsoft. Escolha as instruções do seu cliente: são alternativas de instalação, não uma sequência para executar em todos os editores. Requisitos e instalação

Claude Code

Execute exatamente este comando:

claude mcp add playwright npx @playwright/mcp@latest

Codex

Execute exatamente este comando:

codex mcp add playwright npx "@playwright/mcp@latest"

Outra opção é adicionar o trecho abaixo a ~/.codex/config.toml:

[mcp_servers.playwright]
command = "npx"
args = ["@playwright/mcp@latest"]

Cursor

Siga o caminho de configuração manual do README: Cursor Settings -> MCP -> Add new MCP Server. Escolha um nome, selecione o tipo command e insira:

npx @playwright/mcp@latest

Use Edit para conferir a configuração ou adicionar argumentos. O README também oferece um botão de instalação no Cursor.

VS Code

Use o comando da CLI do VS Code exatamente como aparece abaixo:

code --add-mcp '{"name":"playwright","command":"npx","args":["@playwright/mcp@latest"]}'

O servidor fica disponível para o agente do GitHub Copilot no VS Code. O README da Microsoft também traz links para botões de instalação e para o guia de configuração de MCP no VS Code.

Configuração JSON padrão

Para clientes que usam a configuração JSON padrão do README, este é o exemplo exato:

{
  "mcpServers": {
    "playwright": {
      "command": "npx",
      "args": [
        "@playwright/mcp@latest"
      ]
    }
  }
}

Siga as instruções específicas do seu cliente, acima, para colocar a configuração no lugar certo. A alternativa do Codex usa TOML, não este JSON. Para escolher o agente que vai compor esse fluxo, veja agentes de programação com IA e testes no navegador.

Escolha o navegador e como o agente vai interagir com ele

Comece com a janela do navegador visível, um perfil isolado e snapshots. Adicione as opções à lista de argumentos do servidor, depois de @playwright/mcp@latest. As opções abaixo vêm da referência de configuração da Microsoft.

A diferença entre snapshot e visão está na forma de interagir. No fluxo padrão, use browser_snapshot para identificar os alvos. A ferramenta browser_take_screenshot captura evidências visuais, mas tirar uma captura de tela não habilita, por si só, cliques por coordenadas. Com --caps=vision, o README lista browser_mouse_click_xy, browser_mouse_down, browser_mouse_drag_xy, browser_mouse_move_xy, browser_mouse_up e browser_mouse_wheel. O cliente e o modelo precisam conseguir usar as imagens retornadas para raciocinar visualmente. Referência das ferramentas

Minha escolha inicial são os snapshots para formulários e navegação comuns. Recorra à inspeção visual quando a aparência importar ou quando a estrutura da página não descrever bem o controle. Um snapshot de acessibilidade oferece evidências úteis sobre a estrutura, mas não comprova que a aparência da página está correta.

Quais ferramentas usar nos testes de navegador

O conjunto principal de ferramentas cobre navegação, interação e coleta de evidências. A tabela agrupa as ferramentas básicas de automação e abas do README conforme a tarefa atribuída ao agente. Lista de ferramentas da Microsoft

As ações baseadas em snapshots usam uma referência de alvo extraída do snapshot da página ou um seletor que identifique um único elemento. Um seletor é uma forma de identificar um elemento na página. Atualize o snapshot depois de uma mudança relevante, em vez de presumir que o alvo anterior continua válido.

Os recursos adicionais precisam ser habilitados. A tabela de opções lista vision, pdf e devtools; as seções de ferramentas também documentam explicitamente config, network, storage e testing:

• PDF: --caps=pdf adiciona browser_pdf_save.
• Evidências para depuração: --caps=devtools inclui rastreamento de execução, vídeo, gravação de ações, anotações, destaque de elementos e retomada de uma execução pausada. Por exemplo, browser_start_tracing e browser_stop_tracing delimitam um rastreamento.
• Asserções: --caps=testing adiciona browser_generate_locator, browser_verify_element_visible, browser_verify_list_visible, browser_verify_text_visible e browser_verify_value. Uma asserção declara o que precisa ser verdadeiro.
• Simulação de rede: --caps=network adiciona browser_network_state_set, browser_route, browser_route_list e browser_unroute para simular situações sem conexão e requisições com respostas fictícias.
• Armazenamento: --caps=storage adiciona inspeção e edição de cookies, local storage e session storage, além de browser_storage_state e browser_set_storage_state.
• Configuração efetiva: --caps=config adiciona browser_get_config.

Esses são os grupos documentados no README, sem garantia de que todo cliente exponha todas as ferramentas de imediato. Se alguma estiver faltando, compare a lista de ferramentas do pacote instalado e os recursos habilitados com o README. Descrição completa das ferramentas

Três tarefas que fazem sentido para o negócio

Priorize jornadas em que uma falha impede uma venda ou bloqueia o contato de um cliente. Os fluxos abaixo são propostas de uso, não relatos de economia comprovada.

Verificar o caminho até o checkout

Quem desenvolve uma loja pode pedir ao agente que percorra o checkout como visitante em homologação, confirme que o item escolhido continua no carrinho, preencha dados fictícios de entrega e pare antes de qualquer pagamento real. O benefício é encontrar um erro que impede a compra antes do cliente.

Outra tarefa útil para a mesma equipe é verificar a recuperação após um erro: enviar dados de entrega incompletos, conferir se a mensagem é compreensível, corrigir os dados e verificar se o cliente consegue continuar. Testar apenas o caminho sem erros deixa de fora quem digita algo errado em um campo.

Conferir o site depois de um deploy

Quem está publicando uma alteração em uma landing page pode pedir ao agente que abra a versão publicada, siga a chamada principal para ação e verifique se ela leva à página de cadastro ou contato esperada. Peça evidências da página e as saídas relevantes do console ou de requisições que falharam.

Um desenvolvedor de agência pode então testar com uma área de visualização mais estreita e repetir a navegação. Isso pode revelar um menu encoberto ou um botão inacessível. A captura de tela precisa ser revisada; não funciona como certificado automático de qualidade visual.

Testar formulários com dados fictícios

Quem desenvolve um SaaS pode testar os campos obrigatórios, as mensagens de validação e o caminho de correção de um formulário de cadastro sem login, em ambiente local ou de homologação. Pare antes de criar uma conta real ou use um destino exclusivo para envios de teste.

Um desenvolvedor da área de operações pode preencher um formulário longo em homologação com dados fictícios, conferindo listas suspensas, campos condicionais e o upload de um arquivo de teste antes do envio para um endpoint simulado. Isso ajuda a revelar erros de mapeamento dos campos sem enviar registros de clientes nem acionar um fluxo real.

Exemplo de teste E2E: o checkout sem login trava antes do pagamento

Dê ao agente uma tarefa com limites claros e exija evidências para a conclusão. Este é um exemplo ilustrativo de ponta a ponta, com um defeito assumido de propósito. Não é o relato de um teste em uma loja real.

A aplicação do exemplo tem um carrinho para visitantes, um formulário de entrega e uma página de pagamento. Por engano, o formulário envia o campo de código postal como postal, enquanto o backend espera postalCode. Use um cenário de teste local ou de homologação, sem login, com dados fictícios e sem conexão com um sistema de pagamento real.

Passe estas instruções ao agente, substituindo a URL entre colchetes pela do seu cenário de teste:

O isolamento deve ser definido na configuração do servidor com --isolated; escrever isso apenas no prompt não configura o servidor.

Neste exemplo, o corpo da requisição contém postal, e a resposta aponta a ausência de postalCode. Isso sustenta a hipótese de um erro de mapeamento. Ainda assim, o desenvolvedor deve inspecionar a serialização do formulário e o contrato do backend antes de declarar que a causa raiz foi corrigida.

Exemplo ilustrativo de relatório do agente:

O próximo passo é corrigir o mapeamento e executar novamente os caminhos com dados inválidos e válidos. Depois de confirmar o comportamento, peça ao agente um rascunho de teste de regressão em Playwright, revise as asserções e adicione o teste ao executor que sua equipe já usa. Essa última etapa faz parte do seu processo de engenharia; a conversa via MCP, sozinha, não constitui uma suíte de regressão.

Onde os testes falham e até onde o agente pode chegar

As verificações mais frágeis partem de um objetivo vago ou de um ambiente inseguro. “Confira o checkout” deixa o agente inventar os critérios de sucesso. Já “Confirme que dados válidos de entrega levam à página de pagamento, sem enviar o pagamento” define algo que pode ser revisado.

Considere estes limites práticos:

• Estrutura ambígua da página: Controles sem nome e interfaces que dependem muito de canvas tornam o mapa estrutural menos útil. Minha recomendação é corrigir os rótulos acessíveis nas aplicações que você controla e recorrer a evidências visuais quando a estrutura não bastar.
• Mudanças de estado: Uma nova renderização, um popup ou uma transição demorada podem invalidar a próxima suposição do agente. Inspecione o estado resultante e aguarde o texto ou a transição esperados antes de continuar.
• Conflitos de perfil: Um perfil persistente só pode atender a uma instância de navegador por vez. A Microsoft recomenda sessões isoladas ou valores distintos de --user-data-dir para clientes simultâneos que compartilham um workspace.
• Diferenças entre ambientes: A implementação Docker do README aceita apenas Chromium em modo headless. Não presuma que todas as opções de navegador da tabela geral da CLI funcionam nesse contêiner.
• Cobertura incompleta: Chegar a uma página não comprova que todas as validações, os navegadores, os dispositivos ou os resultados no backend funcionam. Uma captura de tela também não prova que um pedido foi armazenado corretamente. Esses são limites do fluxo de verificação proposto.

As restrições de perfil e Docker estão documentadas no README da Microsoft.

Trate o acesso ao navegador como acesso real. A Microsoft afirma explicitamente que o Playwright MCP não constitui uma barreira de segurança. O perfil padrão mantém o estado do navegador; a extensão opcional para Chrome/Edge pode se conectar a abas existentes e sessões com login ativo. Para as tarefas deste artigo, use uma sessão isolada, sem cookies importados nem conexão com o navegador do dia a dia. Comportamento dos perfis e da extensão

O agente pode solicitar páginas acessíveis a partir do ambiente do navegador. Dependendo da rede, isso pode incluir servidores de desenvolvimento e serviços internos, além de sites públicos. Regras de origem não substituem o isolamento de rede: --allowed-origins e --blocked-origins não restringem redirecionamentos e, explicitamente, não constituem uma barreira de segurança. Já --allowed-hosts diz respeito à verificação do host nas requisições recebidas pelo servidor MCP, não a uma lista de sites que o navegador pode visitar. Configuração e segurança

O acesso a arquivos exige o mesmo cuidado. Por padrão, a configuração documentada restringe os arquivos às raízes do workspace e bloqueia a navegação por file://, enquanto --allow-unrestricted-file-access flexibiliza essas regras. A Microsoft descreve as verificações de arquivos como proteções auxiliares, não como isolamento seguro. Um ponto ainda mais sensível: browser_run_code_unsafe executa JavaScript no processo do servidor, com o alcance de acesso desse processo. Controle essa ferramenta pelas permissões do cliente e restrinja o ambiente do servidor. Esquema de configuração e ferramentas

Capturas de tela, textos da página, saídas do console e corpos de requisições podem expor dados ao agente. Use registros fictícios e endpoints exclusivos para testes. Pare antes de uma cobrança, mensagem, criação de conta ou outro envio com efeitos reais, a menos que aquela ação específica tenha sido autorizada deliberadamente.

Playwright MCP, Chrome DevTools MCP ou Browserbase?

Escolha de acordo com a tarefa e com o local em que o navegador precisa rodar. Esses produtos têm funções em comum, mas ocupam papéis diferentes e não são intercambiáveis.

A Microsoft também oferece --cdp-endpoint para conectar a um endpoint de navegador. Por isso, a interface usada pelo agente e o local em que o navegador roda são decisões separadas. Browserbase não é outro nome para o servidor da Microsoft. Nossa seleção dos melhores navegadores para agentes de IA aborda essa escolha mais ampla.

Quanto custa e duas oportunidades de negócio

A comparação de custos que importa é entre seu processo atual de verificação e o fluxo automatizado completo. O repositório do Playwright MCP usa licença Apache; instalá-lo não fornece o modelo do agente, recursos computacionais, cenários de teste nem revisão humana.

Faça a conta com os seus valores:

• Antes: horas de verificação manual × custo total da sua hora de trabalho, mais as assinaturas de ferramentas de teste que já utiliza.
• Depois: uso do agente + infraestrutura de navegador + revisão humana + manutenção dos cenários e testes.

Como referência concreta de hospedagem, o Browserbase anuncia o plano Developer por $20/mês com 100 horas de navegador, seguido de $0.12 por hora de navegador. Esses valores, em USD, cobrem a infraestrutura de navegador, não o custo completo de um teste de checkout feito por um agente. Preços do Browserbase

A oportunidade mais promissora: um serviço de testes de aceitação a cada release

Uma pequena agência pode oferecer a revisão de jornadas de clientes previamente combinadas após cada deploy do contratante. A versão mínima útil recebe uma URL de homologação e uma lista de critérios de aceitação, executa os caminhos permitidos sem login e entrega um relatório revisado, com evidências e lacunas de cobertura explícitas. O cliente paga para que alguém assuma a responsabilidade pela verificação da release.

O sinal de demanda é modesto: as estimativas de palavras-chave em inglês para os Estados Unidos, obtidas no DataForSEO em outubro de 2026, mostram 110 buscas mensais por “automated browser testing” e 10 por “checkout testing”. São buscas, não compradores. Elas sustentam a ideia de testar um serviço focado com clientes atuais antes de investir em um produto de software mais amplo.

O desafio é a manutenção: mudanças nas jornadas, asserções ambíguas e falsos alarmes podem consumir as horas que você esperava economizar. O diferencial que se sustenta está em uma lista útil de critérios de aceitação e em uma triagem confiável, não em instalar o mesmo servidor MCP público disponível a qualquer pessoa.

Segunda oportunidade: um verificador de formulários em homologação

Uma agência web pode criar um verificador que preencha formulários com valores fictícios, provoque erros de campos obrigatórios e confirme que o envio corrigido chega a um destino simulado. Comece pelos formulários dos sites que a agência já mantém e por um relatório que permita ao desenvolvedor reproduzir o resultado.

O mesmo conjunto de dados do DataForSEO, em inglês para os Estados Unidos, estima 10 buscas mensais por “website form testing”. Isoladamente, é um sinal fraco para aquisição de clientes. Minha posição é vender isso como complemento à manutenção de sites e validar a recorrência da demanda antes de criar um produto separado.

O desafio está no sistema que recebe os dados. Uma página que parece indicar sucesso não prova que o lead chegou ao destino. O MVP precisa de um endpoint de teste ou de outra forma autorizada de confirmar o recebimento, além das evidências do navegador.

Dúvidas comuns na configuração

Para colocar em prática na segunda-feira: escolha a jornada sem login mais próxima de gerar receita, escreva o resultado esperado e o ponto em que o teste deve parar e peça ao agente de programação que você já usa para verificá-la em homologação. Revise as evidências com o desenvolvedor responsável pelo fluxo antes de ampliar o escopo.

Se você quer um fluxo de verificação no navegador adaptado ao seu processo de release, desenvolvemos agentes de IA para fluxos de trabalho de negócios.