MCP Server com Playwright: a IA testa o seu sistema no navegador

Dá para pedir a um agente de IA que abra o navegador, use o seu sistema como um usuário e conte o que aconteceu. Basta ligar um MCP Server de navegador ao agente. Abaixo configuro o Playwright MCP no Amazon Q CLI, peço um cadastro de tarefa, deixo a IA achar e corrigir um erro 500 e repito o teste com tela de iPhone.

O que o MCP Server muda no agente

MCP Server é uma ponte entre o agente de IA e uma operação que você quer executar. Pode ser conversar com o banco relacional, ou, no fim de uma tarefa, mandar o resultado por WhatsApp. Se quiser ver o conceito com outro exemplo, o post do Amazon Q CLI mostra o /mcp listando um servidor de Postgres.

Aqui a ponte é com o navegador. Antes de configurar, pedi ao agente, sem nenhum MCP: "vá até o site da UOL e tire um print para mim". A resposta foi que ele não tem a capacidade de navegar em sites nem de tirar screenshots; só trabalha com arquivos locais, comandos bash e chamadas de API da AWS.

O Playwright MCP resolve isso. Na página dele aparecem as ferramentas: navegar, clicar, fechar o navegador, arrastar e várias outras.

1Configure o Playwright MCP

O projeto de teste é a aplicação BIA, em Node com React e banco PostgreSQL, que sobe com Docker. No Amazon Q, a configuração de MCP fica numa pasta .amazonq na raiz do projeto, num arquivo mcp.json. Colei nele a "configuração padrão" que a página do Playwright MCP traz:

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

Com o Amazon Q já instalado, abri o agente com o comando abaixo. Ele inicia o MCP Server a partir do arquivo e avisa que o servidor foi inicializado:

q

Repeti o pedido da UOL, agora pedindo que o print ficasse na raiz do projeto. O agente abriu uma janela de navegador, pediu autorização para cada passo, tirou o screenshot da página inteira, com rolagem, e moveu o arquivo para a raiz do projeto.

2Peça o teste do seu sistema

Subi o projeto com o Docker Compose da raiz e conferi em localhost:3001. Depois derrubei tudo, inclusive os dados do banco, e subi de novo. O cenário era proposital: a aplicação precisa de um migrate para funcionar, e eu não rodei. O cadastro de tarefa, feito à mão, não funciona.

Com o MCP ligado, pedi ao agente:

navegue até o meu sistema que está rodando na porta 3001 e cadastre uma tarefa para mim

Ele abriu o sistema, preencheu o título e a data, marcou o checkbox "importante" e clicou no botão. Cada ação pediu a minha autorização. O relatório veio em seguida: o sistema respondeu com erro 500 na API, na listagem e no cadastro de tarefas. O agente apontou como suspeita a conectividade com o PostgreSQL e listou o que verificar: banco parado, problema de conexão e migrations não executadas.

3Deixe a IA investigar e corrigir

Dei uma pista a ele: investigue se o problema está nas migrations e tente cadastrar de novo. Ele rodou a migration, voltou ao navegador e repetiu o cadastro. Preencheu o título, a data, marcou como importante e salvou.

O resumo final trouxe a causa (o erro 500 vinha da falta da tabela no banco), o comando executado e a tarefa cadastrada. Na tela, o texto era este:

Tarefa cadastrada:
- Título: "Preparar apresentação do projeto BIA"
- Data: 06/09/2025
- Importante: Sim (marcada com estrela)

Resumo da solução:
1. Identifiquei que o erro 500 era causado pela falta da tabela no banco
2. Executei as migrations: docker compose exec server bash -c 'npx sequelize db:migrate'
3. A migration "20210924000838-criar-tarefas" foi aplicada com sucesso
4. Cadastrei a nova tarefa sem problemas

Foi isso que me interessou: o agente fez o trabalho de quem testa a tela, trouxe o erro e, com uma dica minha, resolveu a causa e testou de novo.

4Teste com a tela de um iPhone

Para ver a experiência no celular, o Playwright MCP aceita um arquivo de configuração, indicado pela opção --config na linha de comando. O esquema dele, na página do repositório, mostra o que pode entrar no JSON.

Criei uma pasta configs dentro de .amazonq, com o arquivo playwright.json, e passei o caminho relativo dele nos args do mcp.json, depois do pacote:

"args": ["@playwright/mcp@latest", "--config", "<caminho-relativo>/playwright.json"]

Em vez de escrever o JSON à mão, entreguei o esquema ao agente e pedi: gere um config seguindo este esquema, populado com as configurações do iPhone 16. Ele criou o arquivo:

Saí do Amazon Q, abri de novo para ele carregar o MCP e pedi:

navegue até o meu sistema, na porta 3001, e cadastre uma tarefa representando um teste de tela do iPhone e retorne um print para mim

Abriu um navegador separado, com a resolução do iPhone, cadastrou a tarefa "Teste de tela do iPhone" e tirou o print. Como o agente não o salvou onde eu queria, pedi: coloque o screenshot na raiz do meu projeto. A configuração que fiz vale só para esta sessão; dá para deixá-la predefinida.

Onde isso entra na sua rotina

A ideia é incorporar o teste num fluxo: você implementa a funcionalidade e, no fim, pede ao agente que teste em várias resoluções. Dá para usar o Chrome em modo headless, sem abrir uma janela. O que mais me ajudou foi não ter de repetir à mão o cadastro de tarefa a cada mudança.

Checklist

• Crie a pasta .amazonq na raiz do projeto e o arquivo mcp.json com o servidor playwright.
• Abra o agente com q e confirme que o MCP Server foi inicializado.
• Peça uma navegação simples, como o print de um site, para provar que o MCP funciona.
• Peça o cadastro de uma tarefa no seu sistema local e leia o relatório do agente.
• Autorize, uma a uma, as ações do navegador que o agente pedir.
• Se aparecer erro, dê uma pista ao agente, como "veja se são as migrations", e peça para ele testar de novo.
• Para o celular, crie um playwright.json com o esquema do repositório e passe-o com --config.

O MCP Server dá ao agente a capacidade que ele não tinha, e você continua sendo quem decide o que testar e o que aprovar.