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.
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.
Descreva um fluxo — seu agente de IA escreve a spec Playwright via create_test e salva direto na suíte.
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.
Anexe um schedule de 1h / 6h / 24h a qualquer teste pra rodar como monitor sintético, não só uma checagem pontual.
Conjuntos de credenciais nomeados (admin, user_comum, …) são salvos uma vez e injetados nas execuções — nunca colados nos prompts.
Presets prontos pra Vercel Protection Bypass, Cloudflare Access e Basic Auth, pra testes alcançarem ambientes de staging protegidos.
Uma interface web sem configuração pra navegar pelos testes, editar specs, disparar execuções e gerenciar credenciais sem tocar na CLI.
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.
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.
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.
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.
Feito pra times que querem cobertura de QA de verdade sem montar um pipeline de CI/CD de testes.
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.
Agende fluxos críticos (login, checkout, captura de lead) pra rodar a cada hora e detectar falhas via webhook antes que os clientes percebam.
Ambientes de staging protegidos por Vercel/Cloudflare Access ou Basic Auth ficam acessíveis via os presets de headers de proteção já embutidos.
Etapas de 2FA por SMS/e-mail pausam o teste e aguardam um valor fornecido pelo seu agente de IA, retomando automaticamente.
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.
Tudo que o Claude, Gemini ou qualquer outro cliente MCP pode chamar assim que o servidor estiver conectado.
| Ferramenta | O que faz |
|---|---|
create_test | Cria 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_tests | Lista todos os testes com o último status conhecido; filtra por status ou limite. |
read_test | Lê o conteúdo de um arquivo de teste. |
update_test | Atualiza 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_test | Apaga um teste e seu histórico permanentemente. Prefira desativar via update_test. |
run_tests | Roda todos os testes ou um arquivo específico; respeita o estado de pausa; notifica o webhook configurado. |
run_until_pass | Roda um teste repetidamente, aplicando correções entre tentativas, até passar ou atingir o limite de tentativas. |
get_status | Status geral da suíte, ou detalhe de falha e sugestões de correção por teste. |
pause_tests | Pausa toda a suíte por até 60 minutos — retoma automaticamente. |
set_webhook | Configura a URL do webhook (Discord, Slack, ou JSON genérico) usada nas notificações de execução. |
create_credential | Cria ou atualiza um conjunto de credenciais nomeado (campos chave-valor). |
list_credentials | Lista os conjuntos de credenciais salvos com valores mascarados. |
delete_credential | Apaga um conjunto de credenciais nomeado. |
start_pair_debug | Abre um navegador visível pra você seguir um fluxo manualmente, gravando console, rede, erros e navegações com timestamp. |
get_pair_debug_context | Retorna a linha do tempo gravada até agora na sessão de pair-debugging ativa. |
stop_pair_debug | Encerra a sessão de pair-debugging e devolve a linha do tempo completa mais um rascunho de teste Playwright. |
O que são Skills e por que a /tuxedo-qa é uma.
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.
Informação atualizada e específica sobre as ferramentas MCP, convenções de teste e o modelo de sandbox/validação do projeto.
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.
Menos ida-e-volta reexplicando o toolkit, mais regra direta — a skill já sabe as 16 ferramentas e quando usar cada uma.
Estrutura pensada pra consumo automático por agentes — auto-aciona pelo contexto do pedido, ou via /tuxedo-qa explícito.
Checklist de pré-voo (identidade de teste, serviços externos reais, credenciais) reduz interpretação errada antes de qualquer teste ser escrito.
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.
Texto claro, versionado no próprio repositório (.claude/skills/tuxedo-qa/SKILL.md) e revisável como qualquer outro arquivo do projeto.
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.
Escrita pensando em consumo automático por um agente, com gatilhos de invocação (description/when_to_use) explícitos.
É markdown puro — também dá pra ler direto, sem precisar de um agente pra traduzir.
Uma skill só, versionada junto do código — evita divergência entre o que o agente sabe e o que o projeto realmente faz.
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.
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.
git clone https://github.com/jonathan-ponciano/sts-tools-mcp-tuxedo-qa.git
cd tuxedo-qa
bun install
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.
bun run dashboard
# → http://localhost:3131
Uma instalação só serve vários projetos isolados, com um dashboard só pra ver todos — veja a seção detalhada abaixo.
/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.
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
Uma instalação do tuxedo-qa serve quantos apps/clientes você quiser — cada um completamente isolado, todos visíveis num dashboard único.
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.
Testes, credenciais, schedule e histórico de cada projeto ficam em projects/<slug>/, separados fisicamente dentro da instalação. Nada é compartilhado entre projetos.
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.
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/.
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.
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.
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.