mcp-lab-agent
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| GROQ_API_KEY | No | API key for Groq LLM | |
| GEMINI_API_KEY | No | API key for Google Gemini | |
| OPENAI_API_KEY | No | API key for OpenAI | |
| OLLAMA_BASE_URL | No | Base URL for Ollama (default: http://localhost:11434) | |
| LEARNING_HUB_URL | No | URL of the Learning Hub | |
| QA_LAB_LLM_SIMPLE | No | Model for simple tasks | |
| QA_LAB_LLM_API_KEY | No | API key for custom LLM | |
| QA_LAB_LLM_COMPLEX | No | Model for complex tasks | |
| QA_LAB_LLM_BASE_URL | No | Custom LLM base URL (enterprise) | |
| LEARNING_HUB_PROJECT_ID | No | Project ID in the Learning Hub |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| read_fileA | Lê o conteúdo de QUALQUER arquivo do projeto por caminho. Use para specs, page objects, componentes, código fonte - qualquer formato. |
| detect_projectA | Analisa o projeto e identifica frameworks de teste, pastas, backend, frontend, ambiente (web/mobile) e hints para geração de testes. |
| web_eval_browserA | [Agente especializado: Browser] Abre a URL no navegador, captura screenshot, erros de console e requisições de rede. Inspirado em web-eval-agent. Requer: npm install playwright |
| qa_route_taskA | Recebe uma descrição da tarefa e retorna qual agente (conjunto de ferramentas) deve ser usado. Útil para encaminhar a ferramenta certa. |
| run_testsA | Roda testes do projeto. Suporta: Cypress, Playwright, WebdriverIO, Jest, Vitest, Mocha, Appium, Detox, Robot Framework, pytest, e mais. Detecta automaticamente. |
| read_projectA | Lê package.json, specs existentes (qualquer framework: Cypress, Playwright, WDIO, Robot, pytest, etc) e retorna contexto. Use includeContent para trazer código de exemplos. |
| generate_testsA | Gera spec em QUALQUER framework. Aceita referência de outro framework: leia com read_file e passe em referenceCode. Traduz automaticamente (ex: Robot→Playwright, Cypress→WDIO). |
| write_testB | Grava spec no disco. Suporta QUALQUER framework (Cypress, Playwright, WDIO, Appium, Robot, pytest, etc.). Detecta automaticamente pasta e extensão. |
| analyze_failuresB | Recebe output de testes e extrai falhas estruturadas. |
| por_que_falhouB | Traduz stack trace em explicação humana. Recebe output do terminal/log, lê o projeto e o teste (se path dado), e retorna: O que aconteceu, Por que falhou, O que fazer, Sugestão de correção, Conceito. Escalável e procedural. |
| suggest_fixB | Recebe análise de falhas e sugere correções (patch, refactor, etc.). |
| suggest_selector_fixA | Quando um teste falha por elemento não encontrado (seletor quebrado após mudança de UI), usa LLM para sugerir seletor alternativo mais resiliente. Prioriza data-testid, role, texto acessível. |
| map_mobile_elementsA | Gera estrutura/template de elementos para testes mobile. Aceita deep link, appPackage/appActivity (Android) ou bundleId (iOS). Retorna instruções para mapear elementos (Appium Inspector, uiautomator) e template para usar em generate_tests. Se elementsJsonPath fornecido, lê arquivo e formata para contexto. |
| analyze_file_methodsA | Lê um arquivo, faz varredura em todos os métodos/funções e retorna análise detalhada: método correto?, melhor forma de escrever?, falso positivo?, coerência?, itens faltando?, parâmetros faltando?, imports faltando?. Requer API key (Groq/Gemini/OpenAI). |
| create_bug_reportA | Gera um bug report estruturado a partir de falhas de teste. |
| get_business_metricsA | Retorna métricas: tempo até bug, custo por defeito (tempo estimado), cobertura por fluxo. Requer run_tests executados e opcionalmente qa-lab-flows.json. |
| list_test_filesA | Lista TODOS os arquivos de teste (qualquer framework: Cypress, Playwright, WDIO, Robot, pytest, Behave, etc.) com filtro opcional. |
| run_linterA | Roda ESLint, Prettier ou linter configurado no projeto. |
| install_dependenciesA | Roda npm install, yarn install ou pnpm install (detecta automaticamente). |
| qa_full_analysisB | [EXECUTOR + CONSULTOR] Análise completa em 1 comando: detecta, executa testes, analisa estabilidade, prevê problemas, calcula riscos por área e gera recomendações acionáveis priorizadas. Combina execução + inteligência. |
| qa_health_checkB | [DIAGNÓSTICO COMPLETO] Analisa tudo: frameworks detectados, testes existentes, cobertura, últimas falhas, aprendizados do agente, e dá uma nota de 0-100 para a saúde do QA. |
| qa_suggest_next_testA | [IA PROATIVA] Analisa o projeto e sugere qual teste criar a seguir (baseado em cobertura, fluxos críticos, gaps detectados). |
| qa_time_travelA | [VISUALIZAÇÃO] Mostra como o agente evoluiu ao longo do tempo: taxa de sucesso por semana, tipos de erros corrigidos, padrões aprendidos. |
| qa_learning_statsA | [MÉTRICAS] Retorna métricas de aprendizado do agente: quantos testes gerados, taxa de sucesso na primeira tentativa, correções aplicadas, etc. |
| get_learning_reportA | Gera relatório de evolução dos aprendizados: resumo por tipo, evolução no tempo e recomendações para aprimorar o código. |
| qa_compare_with_industryA | [BENCHMARK] Compara as métricas do seu projeto com benchmarks da indústria (cobertura, taxa de sucesso, tempo de execução). |
| qa_predict_flakyA | [PREDIÇÃO] Analisa testes existentes e prevê quais têm maior chance de se tornarem flaky (baseado em padrões: seletores frágeis, waits inadequados, dependências externas). |
| get_test_coverageB | Roda testes com coverage (Jest, Playwright, Cypress com plugin). |
| watch_testsB | Inicia testes em watch mode (Jest, Vitest). Útil para desenvolvimento. |
| qa_autoA | [AGENTE AUTÔNOMO] Loop completo: detecta projeto → gera teste → roda → se falhar: analisa, corrige, roda de novo → aprende com erros. Repete até passar ou atingir max_retries. |
| create_test_templateB | Gera template básico de teste (boilerplate) para o framework escolhido. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 31 tools
Multiple tools overlap significantly: run_tests/watch_tests/get_test_coverage all execute tests, generate_tests/create_test_template/write_test all create test content, and qa_full_analysis, qa_health_check, and qa_auto all perform broad analysis. Detailed descriptions help but boundaries remain unclear, risking misselection.
Naming is inconsistent: most tools use verb_noun (run_tests, read_file), but many use a qa_ prefix for meta-tools (qa_health_check, qa_learning_stats), and one tool is in Portuguese (por_que_falhou). The mix of imperative verbs and descriptive noun phrases creates no clear pattern.
At 31 tools, the set is heavy for the apparent scope. Many tools are meta-analytical (qa_time_travel, qa_learning_stats, get_learning_report) and could be consolidated. While some breadth is justified for a QA agent, the count feels inflated with redundancy.
The core QA lifecycle is covered: test creation (generate_tests, write_test), execution (run_tests), failure analysis (analyze_failures, por_que_falhou), fixing (suggest_fix), and reporting (create_bug_report). Minor gaps such as test deletion or explicit test versioning exist but are not critical for typical workflows.