MCP Playwright: o servidor Model Context Protocol publicado pela Microsoft para o Playwright (repositório oficial). Permite a um agente de IA controlar um navegador lendo a árvore de acessibilidade das páginas, sem captura de ecrã nem modelo de visão. O agente pode abrir uma URL, clicar, preencher um formulário e ler o que aparece.
Cada vez mais equipas de QA confiam os seus testes de regressão a um agente como o Claude, ligado ao MCP Playwright. Para explorar uma aplicação ou reproduzir um bug, a ferramenta é notável. Para um teste repetido a cada release, falta-lhe uma propriedade: refazer exatamente o mesmo percurso, porque o agente volta a decidir cada ação em cada execução. O Delta-QA MCP distribui os papéis de outra forma. O seu agente cria o cenário em linguagem simples; depois, o Delta-QA repete-o de forma idêntica, sem LLM, e compara cada release com a referência.
O essencial numa página (definição, automação sem código, grelha de escolha de uma ferramenta): Testes de regressão automatizados, sem código.
O seu agente de IA já sabe navegar no seu site. Ligue-o ao Delta-QA: ele escreve o cenário, o Delta-QA repete-o a cada release e fotografa cada etapa. Testar o Delta-QA grátis →
Por que o MCP Playwright seduz tanto as equipas de QA
O MCP Playwright transforma um pedido em linguagem simples em ações reais num navegador. Um testador escreve « verifica se o formulário de contacto recusa um e-mail inválido », e o agente abre a página, introduz os dados, valida e depois relata o resultado. Não há script para escrever nem seletor para procurar: é isso que explica a sua rápida adoção.
Os números confirmam-no. O pacote @playwright/mcp passou de 2,2 milhões de downloads npm em setembro de 2025 (npm) para 29,3 milhões em setembro de 2026 (npm). O seu repositório GitHub aproxima-se das 38 000 estrelas. Os downloads incluem também as instalações automáticas, pelo que o indicador é imperfeito. Já a tendência é clara: treze vezes mais downloads num ano.
Os seus pontos fortes são reais. As suas ferramentas atuam sobre a árvore de acessibilidade da página, o que a Microsoft apresenta como uma execução determinística das ferramentas, sem as ambiguidades das abordagens por captura de ecrã. A Microsoft recomenda-o para a automação exploratória e para as tarefas em que o agente deve manter o contexto do navegador. Reproduzir um bug reportado, verificar uma página após uma correção, descobrir uma funcionalidade: nestas tarefas pontuais, poupa um tempo considerável.
O MCP Playwright é, portanto, uma excelente ferramenta de exploração. Resta saber se pode ser a sua rede de segurança a cada release. Para o funcionamento do próprio protocolo, veja Playwright e o MCP (Model Context Protocol).
Um teste repetido por um agente não é um teste de regressão
Um teste de regressão só tem valor se repetir o mesmo percurso, com as mesmas verificações, a cada release. É isso que permite atribuir uma diferença à release, e não ao teste. Um agente controlado por um LLM volta a decidir cada ação em cada execução: o mesmo prompt pode produzir outro caminho e, portanto, outro veredito.
Não é um defeito do Playwright, é a natureza dos LLM. Em setembro de 2025, o laboratório Thinking Machines submeteu 1000 vezes o mesmo pedido ao modelo Qwen3-235B, com temperatura zero, o ajuste tido como o mais estável. Obteve 80 respostas diferentes (Thinking Machines Lab). As ferramentas do MCP Playwright são executadas de forma determinística; a decisão de as chamar, em que ordem e sobre que elemento, não é.
Para uma equipa de QA, isto tem três consequências concretas:
- Uma falha não diz quem mudou. Quando a repetição falha, nada indica se o site regrediu ou se o agente seguiu outro caminho.
- Um sucesso não prova que o percurso foi o mesmo. O agente pode chegar à página final por um desvio e concluir que tudo funciona.
- Cada execução custa tempo e tokens. O agente volta a raciocinar em cada etapa. A Microsoft lembra que o MCP carrega, no contexto do modelo, esquemas de ferramentas e árvores de acessibilidade de grande volume (README do MCP Playwright).
O Playwright tem a sua própria resposta: fixar o percurso em código. Os seus agentes de teste exploram a aplicação, redigem um plano e depois transformam-no em ficheiros Playwright Test que um terceiro agente repara quando deixam de funcionar. É o caminho certo para uma equipa de desenvolvimento que versiona e mantém o seu código de teste. Para uma equipa de QA que não programa, equivale a herdar ficheiros TypeScript, seletores e asserções para manter.
Delta-QA MCP: o agente cria o cenário, o Delta-QA repete-o
O servidor MCP do Delta-QA conserva o que o agente faz melhor, compreender um pedido em linguagem simples, e retira-lhe o que faz mal, repetir de forma idêntica. O seu agente cria o cenário e escreve as etapas. O Delta-QA repete-as num navegador próprio, no seu site real, fotografa cada etapa e só valida o que realmente funcionou.
O servidor expõe oito ferramentas, que o agente descobre sozinho. Seis delas bastam para criar um teste, por esta ordem:
list_workspaces: o agente escolhe o espaço de trabalho onde criar o teste.create_scenario: cria o cenário a partir de um nome e de uma URL inicial; a etapa 1, abrir a página, é definida pelo Delta-QA.set_scenario_steps: escreve as etapas do percurso, entre catorze gestos (clique, digitação, seleção, tecla, scroll, navegação…), cada uma dirigida a um elemento da página.capture_scenario: o Delta-QA repete o cenário no seu navegador, no site real, e tira uma foto por etapa.get_capture_result: o agente lê o veredito. Uma falha aponta a etapa a corrigir; o agente corrige-a e volta a lançar a repetição.activate_scenario: depois de uma repetição bem-sucedida, o agente valida o cenário e a captura passa a ser a referência.
Nada é validado com base na palavra do agente. Um agente pode escolher o seletor errado ou afirmar que um percurso funciona: enquanto o Delta-QA não tiver repetido todas as etapas com sucesso, o cenário continua a ser um rascunho. O detalhe das ferramentas, dos papéis e das chaves está na página Servidor MCP do Delta-QA.
| MCP Playwright | Delta-QA MCP | |
|---|---|---|
| Quem executa o percurso | O agente, ação a ação, em cada execução | O Delta-QA, a partir das etapas escritas uma vez pelo agente |
| Papel do LLM na repetição | Decide cada ação | Nenhum: o LLM só intervém na criação |
| O que fica depois da sessão | O histórico da conversa, ou ficheiros de teste para manter | Um cenário no Delta-QA, legível e editável sem código |
| Prova do resultado | O relato do agente e as suas capturas | Uma foto por etapa e um veredito que aponta a etapa que falhou |
| Release seguinte | Nova execução do agente, ou código a fazer evoluir | Repetição idêntica, comparada com a referência |
| Ponto forte | Exploração, reprodução de bugs, verificações pontuais | Testes de regressão repetidos a cada release, sem código |
Deixe o seu agente escrever os cenários e fique com uma repetição idêntica. O Delta-QA repete cada etapa no seu site real e só valida o que realmente funcionou. Testar o Delta-QA grátis →
Exemplo: criar o teste do percurso de início de sessão com o Claude Code
Ligar o Claude Code ao Delta-QA exige uma chave de API e um único comando. Depois, descreva o percurso como o faria a um colega. O agente escreve o cenário, o Delta-QA repete-o e guarda a prova, etapa a etapa.
- Crie a sua conta gratuita e o seu espaço de trabalho no Delta-QA.
- Crie uma chave de API em Configurações, separador Espaço de trabalho, secção Chaves de API. Dê-lhe um nome, o papel « Pode editar » para um agente que escreve cenários e uma expiração de 30 dias, 90 dias ou um ano. A chave só é mostrada uma vez, com o comando já pronto.
- Cole o comando num terminal, substituindo
dqa_…pela sua chave:
claude mcp add --transport http delta-qa https://api.delta-qa.com/api/mcp --header "Authorization: Bearer dqa_…"
- Descreva o percurso no Claude Code, em linguagem simples. Por exemplo: « Cria um teste de regressão do percurso de início de sessão em
https://staging.example.com. Introduz o e-mail da conta de teste e a palavra-passe, valida e verifica se o painel de controlo aparece. » - Deixe o agente trabalhar. O agente cria o cenário, escreve as etapas e pede ao Delta-QA que as repita. Se uma etapa falhar, por exemplo um botão não encontrado na etapa 4, o veredito aponta-a: o agente corrige e volta a lançar a repetição.
- Valide. Quando a repetição tem sucesso, o agente ativa o cenário: a sua captura passa a ser a referência.
A palavra-passe, marcada como valor sensível, é cifrada assim que chega, digitada na repetição e mascarada nas fotos: nem o próprio agente consegue voltar a lê-la. A chave de API só atua no espaço de trabalho a que pertence, com as permissões do seu papel, e pode ser revogada de imediato a partir do mesmo ecrã.
Depois, o QA retoma o controlo no Delta-QA
Uma vez validado, o cenário criado pelo agente passa a ser um cenário Delta-QA como os outros. Aparece no seu espaço de trabalho, legível e editável sem código, como se tivesse sido gravado ao navegar. O papel do agente termina aí: repetir, comparar e decidir cabem ao QA, com todas as ferramentas do Delta-QA.
A cada release:
- Repetir com um clique: o cenário executa-se sozinho, em Chrome, Firefox e WebKit, nas larguras de ecrã que escolher.
- Comparar: o relatório mostra a referência e a versão atual lado a lado, com as diferenças destacadas e classificadas (crítica, aviso, menor). A IA determinística do Delta-QA, não um LLM, atribui sempre o mesmo veredito à mesma diferença.
- Decidir: valide a alteração como nova referência ou abra o bug a partir do relatório.
O relatório contém o que um programador precisa para corrigir: a etapa em causa, a captura de referência, a captura atual e as zonas que diferem. Estes elementos transmitem-se tal como estão ao programador, ou ao seu agente de programação, que parte de uma diferença precisa em vez de uma descrição aproximada. Depois da correção, uma nova repetição do mesmo cenário confirma que a regressão desapareceu.
O seu agente escreve o cenário, o Delta-QA guarda a prova. Crie a sua chave de API e peça ao Claude Code que escreva o seu primeiro teste de regressão. Testar o Delta-QA grátis →
FAQ
O que é o MCP Playwright?
O MCP Playwright é o servidor Model Context Protocol publicado pela Microsoft para o Playwright. Permite a um agente de IA como o Claude controlar um navegador real, lendo a árvore de acessibilidade das páginas: abrir uma URL, clicar, digitar, ler um conteúdo. O agente atua a partir de instruções em linguagem simples, sem script.
É possível fazer testes de regressão com o MCP Playwright?
Para uma verificação pontual, sim. Para um teste repetido a cada release, o agente volta a decidir cada ação em cada execução, pelo que duas execuções podem seguir dois caminhos. É então preciso fixar o percurso: em código Playwright Test que a equipa mantém, ou numa ferramenta que o repita de forma idêntica, como o Delta-QA.
É preciso saber programar para usar o servidor MCP do Delta-QA?
Não. O utilizador descreve o percurso em linguagem simples, o agente escreve as etapas e o Delta-QA repete-as. O cenário aparece depois no Delta-QA, legível e editável sem código, como um cenário gravado ao navegar.
O LLM intervém quando o Delta-QA repete o teste?
Não. O agente só intervém na criação do cenário. As repetições são executadas pelo navegador do Delta-QA e comparadas com a referência pela IA determinística do Delta-QA, não um LLM: a mesma entrada dá sempre o mesmo veredito.
Que agentes se podem ligar ao Delta-QA?
O Claude Code liga-se com um único comando. Qualquer cliente MCP que aceite um servidor remoto « Streamable HTTP », com um cabeçalho de autenticação, também se pode ligar.
O servidor MCP está incluído na conta gratuita?
Sim. As chaves de API e o servidor MCP existem em todos os planos, incluindo a conta gratuita. O que o agente aciona é contabilizado na quota do seu plano, como se o tivesse iniciado pessoalmente.