Servidor MCP · Playwright · Claude · Gemini

Deixe seu agente de IA cuidar do seu QA.

tuxedo-qa é um servidor MCP que dá ao Claude, ao Gemini e a qualquer outro assistente compatível com MCP as ferramentas para escrever, rodar, autocorrigir e monitorar testes Playwright do seu app — com dashboard local, cofre de credenciais e página pública de status, sem precisar de pipeline de CI.

O que ele faz

Um único servidor MCP, conectado ao Claude, Gemini ou qualquer cliente compatível com MCP, expondo 16 ferramentas que cobrem todo o ciclo de vida de uma suíte de testes sintéticos.

✍️

Criação de testes em linguagem natural

Descreva um fluxo — seu agente de IA escreve a spec Playwright via create_test e salva direto na suíte.

🩹

Execução autocorretiva

run_until_pass roda o teste de novo aplicando correções automáticas (timeout, matching de URL, espera de rede) entre as tentativas; quando nenhuma regra resolve, devolve uma sugestão pro seu agente de IA corrigir via update_test.

⏱️

Monitoramento agendado

Anexe um schedule de 1h / 6h / 24h a qualquer teste pra rodar como monitor sintético, não só uma checagem pontual.

🔐

Cofre de credenciais

Conjuntos de credenciais nomeados (admin, user_comum, …) são salvos uma vez e injetados nas execuções — nunca colados nos prompts.

🛡️

Headers de bypass de proteção

Presets prontos pra Vercel Protection Bypass, Cloudflare Access e Basic Auth, pra testes alcançarem ambientes de staging protegidos.

📟

Dashboard local

Uma interface web sem configuração pra navegar pelos testes, editar specs, disparar execuções e gerenciar credenciais sem tocar na CLI.

📣

Alertas via webhook

Configure um webhook uma vez (Discord, Slack, ou um endpoint JSON genérico pra Teams/e-mail via Zapier) e toda execução posta o resultado (passou/falhou) direto no canal da sua equipe.

📊

Página pública de status

Transforme qualquer subconjunto de testes numa página de uptime compartilhável, com histórico das últimas 60 execuções, pra stakeholders que não precisam de acesso MCP.

🧑‍🤝‍🧑

Human-in-the-loop

Testes podem pausar no meio da execução e aguardar um valor fornecido por um humano (códigos de 2FA, OTPs) via um sinal simples baseado em arquivo.

🤖

Skill dedicada — /tuxedo-qa (Claude Code)

O instalador registra a skill tuxedo-qa globalmente — rode /tuxedo-qa em qualquer projeto (ou descreva o fluxo, ela aciona sozinha). Confere se já tem MCP registrado pro projeto e instala se não tiver, e já sabe as 16 ferramentas e as convenções de teste, sem precisar reexplicar nada a cada conversa.

Casos de uso

Feito pra times que querem cobertura de QA de verdade sem montar um pipeline de CI/CD de testes.

1

Smoke tests pós-deploy, direto do chat

Peça ao Claude ou Gemini pra rodar a suíte logo após um deploy — use pause_tests antes pra evitar alertas falsos, depois run_tests assim que estiver no ar.

2

Monitoramento sintético contínuo

Agende fluxos críticos (login, checkout, captura de lead) pra rodar a cada hora e detectar falhas via webhook antes que os clientes percebam.

3

Testes atrás de autenticação

Ambientes de staging protegidos por Vercel/Cloudflare Access ou Basic Auth ficam acessíveis via os presets de headers de proteção já embutidos.

4

Fluxos que precisam de um humano numa etapa

Etapas de 2FA por SMS/e-mail pausam o teste e aguardam um valor fornecido pelo seu agente de IA, retomando automaticamente.

5

Página de status pra stakeholders não-técnicos

Exponha um conjunto selecionado de testes como uma página pública de uptime — sem login no dashboard, sem precisar de cliente MCP pra ver.

Referência das ferramentas MCP

Tudo que o Claude, Gemini ou qualquer outro cliente MCP pode chamar assim que o servidor estiver conectado.

FerramentaO que faz
create_testCria um novo arquivo de teste Playwright a partir do código gerado. Fica em modo sandbox (não roda sozinho, sem alertar webhook) até ser validado manualmente.
list_testsLista todos os testes com o último status conhecido; filtra por status ou limite.
read_testLê o conteúdo de um arquivo de teste.
update_testAtualiza script (com dry-run — edição ruim é rejeitada e o código anterior é restaurado), nome de exibição, descrição, schedule, credencial, estado (ativo/inativo) ou validação de um teste.
delete_testApaga um teste e seu histórico permanentemente. Prefira desativar via update_test.
run_testsRoda todos os testes ou um arquivo específico; respeita o estado de pausa; notifica o webhook configurado.
run_until_passRoda um teste repetidamente, aplicando correções entre tentativas, até passar ou atingir o limite de tentativas.
get_statusStatus geral da suíte, ou detalhe de falha e sugestões de correção por teste.
pause_testsPausa toda a suíte por até 60 minutos — retoma automaticamente.
set_webhookConfigura a URL do webhook (Discord, Slack, ou JSON genérico) usada nas notificações de execução.
create_credentialCria ou atualiza um conjunto de credenciais nomeado (campos chave-valor).
list_credentialsLista os conjuntos de credenciais salvos com valores mascarados.
delete_credentialApaga um conjunto de credenciais nomeado.
start_pair_debugAbre um navegador visível pra você seguir um fluxo manualmente, gravando console, rede, erros e navegações com timestamp.
get_pair_debug_contextRetorna a linha do tempo gravada até agora na sessão de pair-debugging ativa.
stop_pair_debugEncerra a sessão de pair-debugging e devolve a linha do tempo completa mais um rascunho de teste Playwright.

Skills

O que são Skills e por que a /tuxedo-qa é uma.

O que são Skills?

Skills são pacotes de contexto especializado que descrevem regras de negócio do tuxedo-qa, padrões técnicos oficiais, convenções de teste por tipo de fluxo (login, checkout, WhatsApp, CRM) e boas práticas pra credenciais e 2FA. São consumidas diretamente por IDEs e ferramentas de AI coding como Claude Code — a skill /tuxedo-qa já confere se o MCP está instalado pro projeto atual, oferece pra instalar se não estiver, e escreve/roda/corrige teste seguindo essas convenções sem precisar reexplicar nada a cada conversa.

🎯

Contexto Preciso

Informação atualizada e específica sobre as ferramentas MCP, convenções de teste e o modelo de sandbox/validação do projeto.

📐

Padronização

Testes gerados seguem sempre as mesmas convenções oficiais — helper de credenciais, geração de CPF/CNPJ, `requestInput()` pra 2FA — em vez de reinventar a cada conversa.

Aceleração

Menos ida-e-volta reexplicando o toolkit, mais regra direta — a skill já sabe as 16 ferramentas e quando usar cada uma.

🤖

IA-friendly

Estrutura pensada pra consumo automático por agentes — auto-aciona pelo contexto do pedido, ou via /tuxedo-qa explícito.

🛡️

Menos Erros

Checklist de pré-voo (identidade de teste, serviços externos reais, credenciais) reduz interpretação errada antes de qualquer teste ser escrito.

Filosofia

1

Explícitas

Sem regra implícita ou achismo — o checklist de pré-voo e as convenções de teste estão escritos por extenso na skill, não inferidos.

2

Auditáveis

Texto claro, versionado no próprio repositório (.claude/skills/tuxedo-qa/SKILL.md) e revisável como qualquer outro arquivo do projeto.

3

Modulares

Cada seção da skill resolve um problema específico — setup, convenções de código, checklist por tipo de fluxo, sandbox — sem depender uma da outra.

4

IA-first

Escrita pensando em consumo automático por um agente, com gatilhos de invocação (description/when_to_use) explícitos.

5

Human-readable

É markdown puro — também dá pra ler direto, sem precisar de um agente pra traduzir.

6

Fonte única de verdade

Uma skill só, versionada junto do código — evita divergência entre o que o agente sabe e o que o projeto realmente faz.

Como começar

Roda inteiramente na sua máquina em Bun — sem etapa de build, o servidor executa o TypeScript direto da fonte. Um servidor MCP local mais um dashboard opcional.

Instalar

Um comando só — clona e registra no Claude Code e/ou Gemini CLI automaticamente (instale o Bun antes, se ainda não tiver: curl -fsSL https://bun.sh/install | bash):

curl -fsSL https://raw.githubusercontent.com/jonathan-ponciano/sts-tools-mcp-tuxedo-qa/main/install.sh | bash

Instala em ~/tuxedo-qa (mude com TUXEDO_QA_DIR=/outro/caminho). Rodar de novo atualiza — seguro de repetir.

Instalação local

git clone https://github.com/jonathan-ponciano/sts-tools-mcp-tuxedo-qa.git
cd tuxedo-qa
bun install

Configuração

Claude Code:

claude mcp add tuxedoqa --scope user -- bun "$(pwd)/src/index.ts"

Gemini CLI (sem -- antes do comando):

gemini mcp add tuxedoqa bun "$(pwd)/src/index.ts" --scope user

Gemini CLI / Claude Code / Antigravity / opencode via config JSON:

{
  "mcpServers": {
    "tuxedoqa": {
      "command": "bun",
      "args": ["/caminho/absoluto/para/tuxedo-qa/src/index.ts"]
    }
  }
}

Antigravity / Cursor (chave mcp.servers):

{
  "mcp.servers": {
    "tuxedoqa": {
      "command": "bun",
      "args": ["/caminho/absoluto/para/tuxedo-qa/src/index.ts"]
    }
  }
}

Lista completa das 16 ferramentas disponíveis e o que cada uma faz logo abaixo.

(Opcional) iniciar o dashboard local

bun run dashboard
# → http://localhost:3131

Monitorando mais de um app/cliente?

Uma instalação só serve vários projetos isolados, com um dashboard só pra ver todos — veja a seção detalhada abaixo.

Rode /tuxedo-qa ou descreva o fluxo pro seu agente

"Crie um teste Playwright que faz login no staging e confere se o dashboard carrega" — o Claude ou Gemini chama create_test, salva a spec, e pode rodar na hora com run_tests. No Claude Code, /tuxedo-qa já confere a instalação e conhece as convenções do projeto sozinho.

(Opcional) ver o navegador rodando

Por padrão todo teste roda headless (sem janela). Pra acompanhar visualmente o que está acontecendo, passe PWHEADED=1 antes do comando — funciona rodando direto, pelo dashboard, ou disparado pelo Claude/Gemini:

PWHEADED=1 bun run test

Múltiplos projetos, um dashboard só

Uma instalação do tuxedo-qa serve quantos apps/clientes você quiser — cada um completamente isolado, todos visíveis num dashboard único.

🔌

Uma conexão MCP por projeto

Cada projeto tem seu próprio servidor MCP registrado (ex: tuxedoqa-fretebras). O Claude/Gemini conectado ali só enxerga e mexe nos testes daquele projeto — impossível misturar com outro por acidente.

🗂️

Dados isolados de verdade

Testes, credenciais, schedule e histórico de cada projeto ficam em projects/<slug>/, separados fisicamente dentro da instalação. Nada é compartilhado entre projetos.

📊

Um dashboard vê todos

O dashboard não pertence a nenhum projeto específico — ele lista todos com um seletor pra trocar de contexto, e o scheduler monitora todos ao mesmo tempo, cada um no seu próprio horário.

Registrar um novo projeto

Rode o instalador de novo passando um slug — ele reaproveita a mesma instalação, só registra uma nova conexão MCP:

TUXEDO_QA_PROJECT=fretebras bash install.sh
TUXEDO_QA_PROJECT=xtagger bash install.sh

Isso registra tuxedoqa-fretebras e tuxedoqa-xtagger como servidores MCP separados, cada um isolado em projects/fretebras/ e projects/xtagger/.

Usar cada projeto pelo Claude/Gemini

Escolha a conexão MCP certa pra cada conversa — tuxedoqa-fretebras quando o assunto for o Fretebras, tuxedoqa-xtagger pro xtagger. Cada uma só vê o próprio projeto.

Ver e gerenciar tudo num dashboard só

Suba o dashboard uma vez (sem precisar de TUXEDO_QA_PROJECT nenhum):

npm run dashboard

A aba Monitor mostra todos os projetos juntos (testes, uptime, o que tá rodando agora). Clicar num projeto ali — ou no seletor no topo — troca o contexto do resto do dashboard pra aquele projeto.

Monitoramento automático, por projeto

O scheduler roda dentro do dashboard e verifica todos os projetos a cada minuto. Se um tem teste agendado a cada 1h e outro a cada 6h, cada um roda no seu próprio horário, de forma independente — enquanto o dashboard estiver de pé.

Sem TUXEDO_QA_PROJECT, tudo funciona no modo padrão — um projeto só, sem namespace, exatamente como antes.