bugAgent

oficial

Conecte o bugAgent a qualquer cliente de IA compatível com MCP. Registre, classifique e gerencie bugs, solicitações de funcionalidades e muito mais diretamente do seu assistente de codificação de IA. Sem troca de contexto, sem copiar e colar — basta descrever o problema e o bugAgent cuida do resto.

Ver em bugagent.comExperimente este MCPPatrocinado

O que você pode fazer com bugAgent MCP?

Registrar relatórios de bugs — Peça ao seu assistente para criar um relatório de bug com classificação automática em 19 tipos, incluindo configurações de severidade e prioridade.
Listar e filtrar relatórios — Use list_bug_reports para consultar bugs por projeto, severidade, status, tipo ou texto de busca, com paginação de até 100 resultados.
Escolher o próximo bug para trabalhar — Deixe seu assistente chamar pick_next_bug para obter o bug não atribuído de maior prioridade (S1→S3, mais antigo primeiro) para sua equipe.
Reivindicar bugs atomicamente — Use claim_bug para transicionar um bug para em andamento sem condições de corrida e atribuí-lo a você, evitando trabalho duplicado.
Gerenciar suítes e casos de teste — Crie suítes de teste, execute suítes de regressão e liste casos de teste com falha dos últimos 7 dias.

Documentação

Conecte o bug Agent a qualquer cliente de IA compatível com MCP.

Registre, classifique e gerencie bugs, solicitações de recursos e muito mais diretamente do seu assistente de codificação com IA. Sem troca de contexto, sem copiar e colar — basta descrever o problema e o bug Agent cuida do resto.

Clientes MCP externos são separados do Assistente de IA do painel do bug Agent. O assistente do painel fica desativado por padrão em todos os planos e requer ativação explícita no workspace; seu bloqueio ai_assistant não desativa o MCP ou integrações. Autenticação MCP, escopos, permissões de workspace/projeto e permissões específicas de ferramentas continuam valendo.

Primeiros Passos

O bug Agent executa o servidor MCP hospedado para que clientes de IA possam criar, consultar e gerenciar relatórios de bugs, solicitações de recursos, melhorias e muito mais através do Model Context Protocol. Os clientes se conectam diretamente ao endpoint HTTP Streamable hospedado.

Obtenha sua chave de API

Crie uma conta gratuita; novos proprietários de workspace são levados diretamente à configuração da chave de API. Usuários recorrentes podem gerar uma chave em Configurações → Desenvolvedores → Chaves de API.

Configure seu cliente de IA

Adicione o bug Agent como um servidor MCP na configuração do seu cliente (veja a configuração abaixo).

Comece a registrar bugs

Descreva um bug em linguagem natural e o bug Agent classifica, enriquece e armazena automaticamente.

# Create a bug report
"File a bug: Login button is unresponsive on iOS Safari.
Steps: tap login, nothing happens. Expected: navigate to
dashboard. Severity: high."

# bugAgent auto-classifies as UI bug, severity high

# File a feature request
"Feature request: Add dark mode toggle to the
settings page. Users have asked for this in surveys."

# Auto-classified as feature-request, severity medium

Configuração

Recomendado: Streamable HTTP hospedado

Conecte-se diretamente a https://mcp.bugagent.com/mcp. Não há nada para instalar ou manter rodando localmente. Adicione sua chave de API do workspace como um token bearer:

{
  "mcpServers": {
    "bugagent": {
      "type": "http",
      "url": "https://mcp.bugagent.com/mcp",
      "headers": {
        "Authorization": "Bearer ba_live_YOUR_KEY_HERE"
      }
    }
  }
}

💡

Substitua ba_live_YOUR_KEY_HERE pela sua chave de API real de Configurações → Desenvolvedores.

Ponte stdio opcional

Use a ponte publicada somente quando um cliente exigir stdio e não puder se conectar a um servidor HTTP remoto. Execute-a sob demanda com npx -y bugagent-mcp:

{
  "mcpServers": {
    "bugagent": {
      "command": "npx",
      "args": ["-y", "bugagent-mcp"],
      "env": {
        "BUGAGENT_API_KEY": "ba_live_YOUR_KEY_HERE"
      }
    }
  }
}

Conecte-se ao Servidor

O servidor MCP do bug Agent está ativo em https://mcp.bugagent.com/mcp via transporte Streamable HTTP. Conecte-se a partir de qualquer um dos oito clientes abaixo — escolha o que se adequa ao seu fluxo de trabalho.

Para uma configuração pequena pronta para copiar, orientação sobre chaves com escopo e prompts iniciais seguros, use o quickstart MCP público.

🔑

Obtenha sua chave de API primeiro. Entre em Configurações → Desenvolvedores, clique em Criar Chave de API, selecione os escopos que seu cliente precisa e copie o valor (começa com ba_live_). Você só o verá uma vez, então cole-o em um local seguro. Clientes MCP listam apenas as ferramentas concedidas por esses escopos. Os exemplos de conexão abaixo usam esta chave; prompts que exigem OAuth/sessão interativa ou um direito de plano pago são identificados separadamente.

Opção 1 — MCP Inspector (Interface Web, recomendado para testes iniciais)

A ferramenta oficial da Anthropic. Inicia uma interface web local onde você pode navegar por cada ferramenta, preencher parâmetros e ver respostas. Zero configuração, sem necessidade de IDE.

macOS (Terminal)

npx @modelcontextprotocol/inspector

Windows (PowerShell ou CMD)

npx @modelcontextprotocol/inspector

Na interface do navegador que abrir:

Tipo de Transporte: selecione Streamable HTTP
URL: https://mcp.bugagent.com/mcp
Tipo de Conexão: selecione Proxy (o padrão — o Inspector faz proxy através de um processo Node local para contornar o CORS do navegador)
Abra Configurações do Servidor → Cabeçalhos Personalizados e adicione:
- Nome do Cabeçalho: X-Api-Key
  - Valor: ba_live_YOUR_KEY_HERE (sem prefixo Bearer)
Clique em Conectar. O painel esquerdo lista as ferramentas do bug Agent permitidas pelos escopos da chave de API que você selecionou.
Clique em qualquer ferramenta (ex.: list_bug_reports), preencha os parâmetros, clique em Executar Ferramenta. A resposta aparece à direita.

Pré-requisitos: MCP Inspector v2 requer Node.js 22.19 ou posterior. Instale uma versão atual do Node.js em nodejs.org se você não tiver.

Se o Inspector retornar invalid_client, ele está tentando uma conexão OAuth salva em vez de autenticação por chave de API. Remova o servidor salvo (ou limpe o estado OAuth armazenado), adicione-o novamente e use o cabeçalho personalizado X-Api-Key acima. Não coloque uma chave ba_live_ em um campo OAuth client_id.

Opção 2 — Claude Desktop (Mac + Windows)

Se você usa o aplicativo Claude Desktop, pode adicionar o bug Agent como um servidor MCP permanente. Com uma chave de API do workspace, o Claude recebe apenas as ferramentas permitidas pelos escopos dessa chave. OAuth delegado expõe o catálogo interativo completo.

macOS

Abra o Claude Desktop → barra de menu Claude → Configurações → Desenvolvedor → Editar Configuração. Isso abre ~/Library/Application Support/Claude/claude_desktop_config.json.

Adicione a entrada do bug Agent sob mcpServers:

{
  "mcpServers": {
    "bugagent": {
      "type": "http",
      "url": "https://mcp.bugagent.com/mcp",
      "headers": {
        "Authorization": "Bearer ba_live_YOUR_KEY_HERE"
      }
    }
  }
}

Salve o arquivo e saia completamente do Claude Desktop (Cmd+Q, não apenas feche a janela).
Reinicie o Claude Desktop. O ícone de martelo de ferramentas na parte inferior da entrada de chat deve agora mostrar as ferramentas do bug Agent.
Experimente: digite “Liste meus 5 relatórios de bugs mais recentes” — o Claude chamará list_bug_reports automaticamente.

Windows

Abra o Claude Desktop → Arquivo → Configurações → Desenvolvedor → Editar Configuração. Isso abre %APPDATA%\Claude\claude_desktop_config.json (tipicamente C:\Users\YourName\AppData\Roaming\Claude\claude_desktop_config.json).
Adicione o mesmo bloco JSON mostrado na seção macOS.
Salve o arquivo e saia completamente do Claude Desktop pela bandeja do sistema (clique com o botão direito no ícone do Claude → Sair) e reinicie.
O ícone de martelo de ferramentas mostrará as ferramentas do bug Agent.

Opção 3 — Claude Code (CLI)

Se você usa o Claude Code pelo terminal (a versão CLI do Claude), registre o servidor do bug Agent com um comando. Funciona de forma idêntica em macOS, Linux e Windows.

claude mcp add --transport http bugagent https://mcp.bugagent.com/mcp \
  --header "Authorization: Bearer ba_live_YOUR_KEY_HERE"

Em seguida, reinicie sua sessão do Claude Code. Verifique se está conectado:

claude mcp list

Você deve ver bugagent na lista com um ponto verde. Comece com um prompt compatível com chave de API: “Liste meus 5 relatórios de bugs abertos mais recentes.”

Conectado, mas algumas ferramentas estão faltando?

Verifique a contagem de ferramentas do servidor em /mcp, não apenas as ferramentas já carregadas na conversa. O Claude Code pode descobrir ferramentas sob demanda usando a busca de ferramentas. Peça para ele buscar no bugAgent por list_test_cases, list_test_suites ou get_test_run_plan. Veja a documentação de busca de ferramentas do Claude Code.

O catálogo é filtrado pelos escopos da chave de API. Leituras de casos de teste precisam de test_cases:read; leituras de suíte/execução precisam de test_runs:read. Solicite apenas os escopos de escrita que você realmente precisa. Compare o tools/list autenticado com o mesmo endpoint e chave do seu cliente; descoberta anônima ou uma chave diferente não é uma comparação válida. Verifique se há uma configuração no nível do projeto substituindo sua conexão no nível do usuário e reconecte ou reinicie após alterações de credenciais.

Se o catálogo autenticado do servidor incluir uma ferramenta, mas o cliente ainda não conseguir descobri-la, registre a versão do cliente, versão do servidor, nomes/contagens de ferramentas e quaisquer erros de esquema, com credenciais e dados do cliente removidos. Uma sessão iniciada com ENABLE_TOOL_SEARCH=false claude pode distinguir descoberta adiada de problemas de carregamento, mas carrega todas as definições de ferramentas e usa mais contexto; use-a apenas como diagnóstico temporário. Não amplie permissões ou divida endpoints apenas para aumentar uma contagem de ferramentas.

Para remover depois:

claude mcp remove bugagent

Opção 4 — OpenAI Codex CLI

Se você usa o OpenAI Codex CLI, exporte sua chave de API e adicione o bug Agent a ~/.codex/config.toml.

Registro permanente (adicionar à configuração)

[mcp_servers.bugagent]
url = "https://mcp.bugagent.com/mcp"
bearer_token_env_var = "BUGAGENT_API_KEY"

Defina a chave de API

export BUGAGENT_API_KEY="ba_live_YOUR_KEY_HERE"

Inicie ou reinicie o Codex a partir desse ambiente. O Codex resolve chamadas de ferramentas automaticamente a partir do seu prompt em linguagem natural. Experimente: “Liste meus bugs abertos ordenados por severidade.”

Opção 5 — Cursor (Mac + Windows)

O Cursor tem suporte MCP integrado. Com uma chave de API de workspace com escopo apropriado, o assistente de IA dentro do Cursor pode registrar bugs, listar relatórios e executar fluxos de automação suportados sem sair do seu editor. Varreduras de segurança, desempenho e exploração exigem OAuth delegado e acesso ao plano aplicável.

Abra o Cursor → Configurações (Cmd+, no Mac / Ctrl+, no Windows) → MCP na barra lateral esquerda.
Clique em + Adicionar novo servidor MCP.
Selecione o tipo de transporte HTTP.
Preencha:
- Nome: bugagent
  - URL: https://mcp.bugagent.com/mcp
  - Nome do cabeçalho: Authorization
  - Valor do cabeçalho: Bearer ba_live_YOUR_KEY_HERE
Clique em Salvar. O Cursor mostra um indicador verde quando conectado.
Abra o chat do Cursor (Cmd+L / Ctrl+L) e digite “Crie um relatório de bug intitulado ‘Login quebrado’ com severidade alta.” O Cursor invocará create_bug_report.

Alternativa: O Cursor também lê ~/.cursor/mcp.json (Mac) ou %USERPROFILE%\.cursor\mcp.json (Windows). Adicione o mesmo formato JSON mostrado na seção Claude Desktop.

Opção 6 — VS Code com extensão Continue (Mac + Windows)

Se você prefere VS Code, a extensão Continue suporta servidores MCP nativamente.

Instale a extensão Continue do marketplace do VS Code.
Abra a configuração do Continue: Paleta de Comandos (Cmd+Shift+P / Ctrl+Shift+P) → Continue: Abrir config.json. O arquivo está em:
- macOS: ~/.continue/config.json
  - Windows: %USERPROFILE%\.continue\config.json

Adicione uma entrada mcpServers:

{
  "mcpServers": [
    {
      "name": "bugagent",
      "type": "streamable-http",
      "url": "https://mcp.bugagent.com/mcp",
      "requestOptions": {
        "headers": {
          "Authorization": "Bearer ba_live_YOUR_KEY_HERE"
        }
      }
    }
  ]
}

Salve. O Continue recarregará automaticamente e mostrará as ferramentas do bug Agent na barra lateral.
Abra o painel de chat do Continue e experimente: “Liste meus 5 relatórios de bugs abertos mais recentes.”

Outras extensões VS Code com capacidade MCP: Cline, Roo Code e Windsurf (fork) seguem padrões de configuração JSON semelhantes com uma chave mcpServers e transporte HTTP.

Opção 7 — Hosts com suporte a OAuth (Claude.ai web mostrado como exemplo)

Alguns hosts MCP autenticam via OAuth 2.0 e pedem um client_id e client_secret estáticos antecipadamente em vez de aceitar uma chave de API bearer. Gere um par de credenciais de conector no painel do bug Agent e cole-o no formulário de conector do host. O par identifica o cliente MCP; após o consentimento, a execução de ferramentas usa o usuário conectado e o workspace ativo do bug Agent desse usuário. O passo a passo abaixo usa o aplicativo web Claude.ai como o exemplo mais comum.

OAuth vinculado a recurso. O identificador de recurso protegido é https://mcp.bugagent.com/mcp. Hosts cientes de padrões o descobrem a partir de /.well-known/oauth-protected-resource/mcp e o enviam como o parâmetro RFC 8707 resource. O bug Agent emite tokens opacos vinculados a esse recurso, cliente OAuth, usuário conectado e escopos concedidos; um token não pode ser reproduzido contra outro serviço ou resgatado por outro cliente.

No bug Agent: abra Configurações → Desenvolvedores → Conectores MCP. Clique em Gerar conector, dê um nome que descreva o host (ex.: “Claude.ai (trabalho)”), cole o URI de redirecionamento que seu host MCP exige (para o aplicativo web Claude.ai é https://claude.ai/api/mcp/auth_callback — verifique a documentação de conectores do seu host para outros) e escolha Confidencial para o método de autenticação. Copie o client_id e client_secret mostrados uma vez na tela de sucesso.
Nas configurações de conector/OAuth do seu host MCP, cole:
- URL do servidor: https://mcp.bugagent.com/mcp
  - ID do Cliente + Segredo do Cliente: do passo 1
  - URL de Autorização: https://mcp.bugagent.com/authorize
  - URL de Token: https://mcp.bugagent.com/token
  - Recurso protegido / audiência, quando solicitado: https://mcp.bugagent.com/mcp Para Claude.ai especificamente: vá para claude.ai/customize/connectors e clique em Adicionar conector MCP.
Salve. O host redireciona você para o bug Agent para entrar (Google ou e-mail/senha — qualquer método que você use para o painel) e aprovar o consentimento, então completa o handshake OAuth.
Gerencie e revogue conectores gerados na mesma página de Configurações. A revogação é imediata — a próxima solicitação desse conector retorna invalid_client.

Nota: Claude Code, Cursor, VS Code e MCP Inspector não precisam deste fluxo — eles lidam com registro dinâmico de cliente (RFC 7591) automaticamente e autenticam via chave de API como mostrado acima. O formulário de Conectores MCP é apenas para hosts que exigem credenciais OAuth estáticas.

Os valores de acesso e atualização OAuth são exibidos apenas ao host. Eles são opacos, rotacionados na atualização e armazenados pelo bug Agent apenas como hashes unidirecionais; a credencial de atualização de identidade upstream é criptografada em repouso. Nunca copie um token OAuth em uma solicitação de API REST ou em outro servidor MCP.

Opção 8 — HTTP direto com curl (Terminal)

Se você quiser testar o servidor diretamente sem nenhum cliente, ou integrá-lo a um script, você pode acessar o endpoint HTTP com curl. O protocolo MCP é JSON-RPC 2.0 sobre Streamable HTTP.

macOS / Linux

# Set your API key as a variable
export BUGAGENT_API_KEY="ba_live_YOUR_KEY_HERE"

# 1. Initialize the MCP connection
curl -N -s https://mcp.bugagent.com/mcp \
  -H "Authorization: Bearer $BUGAGENT_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Accept: application/json, text/event-stream" \
  -d '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2024-11-05","capabilities":{},"clientInfo":{"name":"curl-example","version":"1.0.0"}}}'

# 2. List tools visible to this key
curl -N -s https://mcp.bugagent.com/mcp \
  -H "Authorization: Bearer $BUGAGENT_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Accept: application/json, text/event-stream" \
  -d '{"jsonrpc":"2.0","id":2,"method":"tools/list"}'

# 3. Call a tool — list 5 reports from a specific project
curl -N -s https://mcp.bugagent.com/mcp \
  -H "Authorization: Bearer $BUGAGENT_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Accept: application/json, text/event-stream" \
  -d '{
    "jsonrpc":"2.0",
    "id":3,
    "method":"tools/call",
    "params":{
      "name":"list_bug_reports",
      "arguments":{"project":"bugagent","limit":5}
    }
  }'

Windows (PowerShell)

# Set your API key
$env:BUGAGENT_API_KEY = "ba_live_YOUR_KEY_HERE"

# Use Invoke-RestMethod (PowerShell's curl equivalent)
$headers = @{
  "Authorization" = "Bearer $env:BUGAGENT_API_KEY"
  "Content-Type" = "application/json"
  "Accept" = "application/json, text/event-stream"
}

# 1. Initialize
$body = '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2024-11-05","capabilities":{},"clientInfo":{"name":"powershell-example","version":"1.0.0"}}}'
Invoke-RestMethod -Uri "https://mcp.bugagent.com/mcp" \`
  -Method Post -Headers $headers -Body $body

# 2. List tools visible to this key
$body = '{"jsonrpc":"2.0","id":2,"method":"tools/list"}'
Invoke-RestMethod -Uri "https://mcp.bugagent.com/mcp" \`
  -Method Post -Headers $headers -Body $body

# 3. Call list_bug_reports for a specific project
$body = @{
  jsonrpc = "2.0"
  id = 3
  method = "tools/call"
  params = @{
    name = "list_bug_reports"
    arguments = @{ project = "bugagent"; limit = 5 }
  }
} | ConvertTo-Json -Depth 5

Invoke-RestMethod -Uri "https://mcp.bugagent.com/mcp" \`
  -Method Post -Headers $headers -Body $body

As respostas podem ser JSON ou Server-Sent Events. Cada chunk SSE é uma linha prefixada com data: seguida por um objeto JSON. Clientes compatíveis com os padrões devem enviar Accept: application/json, text/event-stream; o bug Agent atualmente normaliza valores Accept ausentes ou incompletos para compatibilidade.

ℹ️

Solução de problemas de 401 Não Autorizado: Verifique se sua chave de API não foi revogada em Configurações → Desenvolvedores. As chaves começam com ba_live_. Se você ainda estiver com problemas, gere uma nova chave e tente novamente.

Modelo de acesso e escopos de privilégio mínimo

O catálogo OAuth completo contém 141 ferramentas. Uma chave de API de workspace vê apenas as ferramentas mapeadas para um de seus escopos selecionados. A descoberta não autenticada pode mostrar metadados de ferramentas, mas tools/call sempre exige uma chave de API ou token OAuth.

Ler relatórios de bugs e resolver projetos reports:read

Criar e atualizar relatórios de bugs reports:read, reports:write

Monitor de uso usage:read

Verificar estado de sincronização do Jira jira:read

Sincronizar ou mesclar relatórios do Jira jira:write

Autorizar automações web automations:write

Executar automações web e ler execuções automations:run

Observar ativos e execuções móveis mobile:read

Gerenciar ativos móveis mobile:read, mobile:write

Executar automação móvel mobile:read, mobile:run

Gerenciar o catálogo de testes reports:read, test_cases:read, test_cases:write

Worker externo de execução de testes test_runs:read, test_runs:write

As chaves de API estão vinculadas ao workspace onde foram criadas. As entradas das ferramentas podem restringir uma chamada a um projeto autorizado, mas não podem mudar a chave para outro workspace. Resolva UUIDs de projeto com list_projects e rejeite nomes ambíguos.

Títulos e anotações de ferramentas

Cada ferramenta retornada por tools/list inclui um título legível por humanos e dicas de leitura/escrita. Dicas de leitura ausentes vêm de uma lista revisada explicitamente, não de prefixos de nomes de ferramentas ou escopos de chave de API. Anotações explícitas, incluindo false, são preservadas.

readOnlyHint: true descreve uma ferramenta que não modifica seu ambiente.
readOnlyHint: false com destructiveHint: false descreve escritas aditivas, não uma operação somente leitura.
readOnlyHint: false com destructiveHint: true descreve escritas potencialmente destrutivas. Ferramentas não classificadas usam esses padrões conservadores. A dica destrutiva é significativa apenas para escritas.

login não é somente leitura: no modo stdio, ela salva credenciais. analyze_fix_area e check_config_drift são escritas potencialmente destrutivas porque substituem resultados de análise persistidos ou linhas de base de configuração.

As anotações não concedem acesso nem substituem autenticação, autorização de workspace/projeto, escopos de chave de API ou verificações de direito. Os prompts de confirmação dependem da política de permissão do cliente e das configurações do usuário; as dicas não garantem se uma chamada exibirá um prompt.

Para descoberta programática e auditoria, baixe o mcp-tool-index.json gerado. Ele registra todas as 141 ferramentas em tempo de execução, acesso por escopo de chave de API ou somente OAuth, família de direito, nomes de entrada, modo de esquema de saída e anotações MCP declaradas explicitamente. Uma anotação null significa que ela não é declarada no local da chamada; use a resposta tools/list do servidor conectado para anotações efetivas após os padrões serem aplicados.

Ferramentas somente OAuth: administração de conta, chave de API e equipe, gerenciamento de conexão Jira, outras integrações, controles premium de testes, notas, controle de tempo e outras operações interativas não são desbloqueadas pela adição de escopos de chave de API. As ferramentas de verificação, sincronização e mesclagem de relatórios Jira são a exceção restrita por meio de jira:read e jira:write.

Experimente — Prompts em Linguagem Natural

Uma vez conectado, você não precisa saber nomes de ferramentas ou parâmetros. Descreva o que você quer em linguagem natural e seu assistente de IA chama a ferramenta certa do bug Agent automaticamente.

Prompts de relatórios de bugs, gerenciamento de testes com escopo, automação Playwright, automação móvel e uso estão disponíveis para chaves de API com os escopos correspondentes. Segurança, desempenho, exploração, conta, equipe, notas, controle de tempo e outras entradas sem um escopo de chave de API nomeado exigem OAuth delegado e qualquer direito de plano aplicável.

Relatórios de Bugs

List my 5 most recent bug reports
Show all open critical bugs in the Auth project
Create a bug titled "Login broken on Safari" with severity s2
Update TEST-451 status to in-progress and assign it to me
Add a comment to TEST-451: "root cause confirmed — null check missing in auth middleware"
Show me everything filed this week, grouped by severity

Gerenciamento de Testes

Create a test suite called "Smoke Tests" with cases for login, checkout, and account settings
Run the Regression suite and list all failures
Use Hermes to execute the curated "Checkout smoke" suite and report every result to bugAgent
Show failing test cases from the last 7 days
Which test cases have never been run in the past 90 days?
Get a pass-rate trend for this month vs last month

Segurança e Desempenho

Run a security scan on https://app.example.com
Get this month's security scan results — show only high and critical findings
Create a performance test for the landing page and check Lighthouse scores
What are the Core Web Vitals for our checkout flow?

Automação Playwright

Create a Playwright script that logs in and verifies the dashboard loads
Run the checkout automation on iPhone 15 Pro on a real device
Optimize the login automation script
Show runs for the checkout automation — any failures?
Schedule the smoke test suite to run every weekday at 6 AM UTC

IA Exploratória

Run an exploratory AI session on https://app.example.com with 5 parallel agents
Get the latest exploration run results — list any bugs that were filed
What testing strategies did the agents use and which found the most issues?

Uso e Estatísticas

Check my plan usage for this month
Show team bug stats for this week broken down by severity and type
List all team members and their roles
How many security scans do I have left this month?

Referência Rápida

Referências de configuração para todas as oito opções de conexão. Clientes com chave de API conectam-se a https://mcp.bugagent.com/mcp com o cabeçalho Authorization: Bearer ba_live_YOUR_KEY_HERE sobre Streamable HTTP; hosts compatíveis com OAuth usam credenciais de conector geradas no painel.

Claude Desktop — macOS ~/Library/Application Support/Claude/claude_desktop_config.json

Claude Desktop — Windows %APPDATA%\Claude\claude_desktop_config.json

Claude Code (CLI) claude mcp add --transport http bugagent https://mcp.bugagent.com/mcp --header "Authorization: Bearer ba_live_..."

Codex CLI ~/.codex/config.toml

Cursor — macOS Configurações → UI MCP, ou ~/.cursor/mcp.json

Cursor — Windows %USERPROFILE%\.cursor\mcp.json

VS Code + Continue ~/.continue/config.json (macOS) / %USERPROFILE%\.continue\config.json (Windows)

Host compatível com OAuth Configurações → Desenvolvedores → Conectores MCP — gere o client_id e client_secret do host

HTTP direto (curl) curl / Invoke-RestMethod — inclua Accept: application/json, text/event-stream

Solução de Problemas

401 Unauthorized Chave errada, expirada ou revogada. Verifique Configurações → Desenvolvedores — as chaves começam com ba_live_. Regere se necessário.

Ferramentas não aparecem no cliente Clientes com chave de API listam apenas ferramentas permitidas pelos escopos selecionados da chave. Verifique a chave em Configurações → Desenvolvedores e, em seguida, saia completamente e reinicie o cliente após alterar sua configuração. No Claude Desktop, Cmd+Q (não apenas feche a janela). No Cursor, verifique Configurações → MCP para um ponto verde.

Campo ausente no cliente Compare o esquema do cliente com o tools/list bruto do mesmo endpoint. Se forem diferentes, atualize ou reconecte o catálogo de ferramentas e inicie um novo chat. Se persistir, colete o endpoint, a versão do cliente e a resposta tools/list bruta; um cache desatualizado é apenas uma causa possível.

Accept header required Envie Accept: application/json, text/event-stream para Streamable HTTP compatível com padrões. O bug Agent atualmente normaliza valores ausentes ou incompletos, mas as integrações não devem depender desse comportamento de compatibilidade.

Dados do workspace errado Cada chave de API é limitada a um workspace. Gere uma nova chave a partir do workspace que você deseja consultar em Configurações → Desenvolvedores.

Ferramentas aparecem, mas chamadas falham silenciosamente Inspecione a resposta para isError: true e o conteúdo retornado. Uma ferramenta visível ainda pode ser negada por plano, função, direito de recurso, associação a projeto, propriedade ou entrada inválida. Verifique a saúde do servidor somente após ler o erro da ferramenta.

Erro de CORS no MCP Inspector Selecione Proxy (não Direto) para o Tipo de Conexão na interface do Inspector. O Inspector faz proxy por meio de um processo Node local para contornar as restrições de CORS do navegador.

MCP Inspector v2 sai com código 5 O Inspector v2 retorna um código de saída diferente de zero quando uma resposta de ferramenta tem isError: true. Leia a mensagem de resposta para um erro de plano, permissão, entrada ou tempo de execução; o Inspector v1 podia retornar código de saída 0 para a mesma resposta de ferramenta com falha.

Codex CLI — ferramentas não reconhecidas Verifique se ~/.codex/config.toml usa [mcp_servers.bugagent], defina bearer_token_env_var = "BUGAGENT_API_KEY" e exporte essa variável antes de iniciar o Codex. Verifique codex --version se as ferramentas ainda não aparecerem.

Recursos MCP

Sessões Conversacionais permanecem um piloto restrito ao workspace. Salvar um script gerado em sessão exige a aprovação explícita do Workbench do proprietário por meio do endpoint de salvamento de script somente sessão. Não há ferramenta de aprovação MCP: pedir a um agente para rascunhar um script não cria nem agenda uma automação.

O catálogo interativo/OAuth completo contém 141 ferramentas. Chaves de API de workspace descobrem apenas o subconjunto de privilégio mínimo permitido por seus escopos selecionados; ferramentas de conta, administração de chave de API, administração de equipe, testes premium, notas e controle de tempo são somente sessão interativa, a menos que uma entrada nomeie explicitamente um escopo de chave de API.

🐛

Gerenciamento de Relatórios de Bugs

Importações retomáveis de capturas de tela do Google Sheets usam o endpoint REST separado POST /api/reports/import-attachment com reports:write, e o status GET com reports:read. Nenhuma ferramenta MCP de importação de captura de tela é adicionada. Esta API somente JPEG/PNG verifica armazenamento privado e o problema Jira mapeado exato antes de relatar a conclusão; o upload legado de relatórios permanece somente sessão.

create_bug_report — Registre um novo relatório com classificação automática em 19 tipos — bugs, solicitações de recursos, melhorias, dívida técnica e mais (título: 3-500 caracteres). O array opcional attachments aceita arquivos codificados em base64 de até 400 MB cada: qualquer imagem, vídeo, áudio, PDF ou texto/JSON. Defina format_description: true para reformatar automaticamente a descrição em um modelo estruturado usando IA. Passe time_spent_seconds para rastrear o esforço de QA. Passe priority (urgent / high / normal / low) para definir a urgência da correção independentemente da severidade. Passe is_epic: true para criar um Epic, ou parent_epic_id (UUID/ID curto) para criar um filho no mesmo projeto autorizado. A resposta inclui campos de hierarquia além de project_id, project, short_id, legacy_short_id e project_short_id.
list_bug_reports — Liste e filtre relatórios (máx. 100 por página). Os filtros de projeto são aplicados no servidor antes da paginação. Filtre por project (UUID, slug, nome exato ou prefixo de ticket), project_id, project_slug, project_prefix, workspace (UUID, nome exato ou prefixo de ticket do workspace), workspace_id / team_id, is_epic, type, severity, status, resolution, root_cause ou reporter_user_id. O filtro search pesquisa o texto do relatório; entrada apenas com dígitos, como 366, é uma busca exata contra números de ticket legados e do projeto, portanto texto não relacionado contendo esses dígitos é excluído. Cada resultado inclui identificadores de pessoas/projetos com escopo do tenant, além de is_epic, parent_epic_id, parent_epic e epic_progress limitado. As ferramentas de leitura de relatórios não expõem endereços de e-mail de membros.
pick_next_bug — Retorna o(s) próximo(s) bug(s) em que o loop do agente deve trabalhar, em ordem de prioridade (S1 → S2 → S3, mais antigos primeiro dentro de cada grupo). Escopo automático para seu workspace — retorna tickets em todos os projetos da sua equipe com status new, awaiting-triage ou confirmed e severidade S1-S3. Somente leitura — não reivindica tickets atomicamente. severity opcional (nível único), limit (1-50, padrão 1). Retorna um objeto com count e bugs; cada bug é uma linha de fila reduzida, não a forma completa de list_bug_reports. Combine com claim_bug para o padrão ler-depois-reivindicar.
claim_bug — Transiciona atomicamente um bug de status new, awaiting-triage ou confirmed para status='in-progress', define assigned_to como o usuário chamador e carimba claimed_at=NOW(). Sem corrida entre chamadores concorrentes via padrão UPDATE-WHERE-RETURNING do Postgres — se dois agentes chamarem claim_bug no mesmo id em rápida sucessão, exatamente um recebe claimed:true com o corpo do bug e o outro recebe claimed:false com uma string de motivo. Respostas bem-sucedidas incluem reporter_user_id, reporter_name, assigned_to e assignee_name. Um coletor pg_cron libera reivindicações obsoletas (status= in-progress + claimed_at > 30 minutos) de volta para new automaticamente, então os tickets de um agente que travou reentram na fila sem intervenção manual. Entradas: id (UUID ou ID curto).
get_bug_report — Obtém detalhes completos de um relatório por UUID ou ID curto do workspace/projeto. Retorna os campos padrão de pessoas/projeto/qualidade, além de is_epic, identidade do pai, progresso agregado e uma primeira página limitada de filhos para Epics.
Tags nativas de relatório: create_bug_report e update_bug_report aceitam tags como um array de strings, por exemplo {"tags":["login","regression"]}. No máximo 20 elementos brutos são aceitos antes da deduplicação. Strings são aparadas, devem ser não vazias e ter no máximo 50 pontos de código Unicode, e não podem conter controles ASCII (U+0000 a U+001F ou U+007F). Duplicatas exatas são removidas após o aparamento; maiúsculas/minúsculas são preservadas e Login difere de login. Na atualização, o array substitui todas as tags, [] as limpa, e a omissão as preserva. Na criação, omissão significa sem tags. null e elementos inválidos são rejeitados. Resultados de criar, obter, listar e atualizar expõem tags nativo.
Filtragem de tags: chame list_bug_reports com {"project":"bugagent","tags":["login","regression"]} para corresponder a TODAS as tags solicitadas, com distinção de maiúsculas/minúsculas, antes da paginação. Os mesmos limites de tags se aplicam; omissão ou [] não aplica filtro de tags. Os escopos existentes reports:read / reports:write e a autorização de workspace/projeto permanecem inalterados. Isso não adiciona UI visual de tags ou importação, sincronização ou backfill automático de rótulos do Jira.
get_epic — Lê um Epic diretamente com id obrigatório (UUID ou ID curto do workspace/projeto). Retorna apenas o registro do Epic, sem carregar implicitamente relatórios filhos. Requer acesso ao workspace e projeto; chamadores com chave de API exigem reports:read. Use list_epic_children separadamente para ler filhos.
list_epic_children — Pagina os relatórios filhos de um Epic com id, limit (1–100) e offset. Retorna children, total, has_more e epic_progress agregado por SQL sem carregar cada relatório filho.
update_bug_report — Atualiza campos padrão do relatório, além de is_epic e parent_epic_id. Passe parent_epic_id: null para desanexar; reparentalização/desanexação é atômica e requer autorização de mesmo workspace e mesmo projeto. Promover para Epic desanexa um pai existente, enquanto um Epic com filhos não pode ser rebaixado. Regras existentes de status/resolução/causa raiz e notificação de atribuição ainda se aplicam. Uma alteração de status em um relatório vinculado ao Jira é espelhada no issue do Jira via suas transições de fluxo de trabalho quando exatamente uma transição legal corresponde ao status mapeado; caso contrário, o issue é deixado intacto.
add_comment — Adiciona um comentário a um relatório de bug (UUID ou ID curto, corpo de 1-10000 caracteres). Se o relatório estiver sincronizado com o Jira, o comentário é enviado automaticamente para o issue vinculado no Jira. Markdown de anexo privado, como ![proof](/api/attachments/ATTACHMENT_UUID), torna-se um link inteligente absoluto autenticado do bugAgent no Jira. Os visualizadores devem entrar no bugAgent com acesso ao workspace e projeto do relatório; pré-visualizações inline nativas do Jira não são garantidas.
list_comments — Lista o thread de comentários armazenado de um relatório, do mais antigo ao mais novo — cada comentário com nome do autor, parentId (respostas em thread), createdAt e updatedAt. Comentários não fazem parte de get_bug_report, então é assim que você lê a discussão de um ticket. Aceita UUID ou ID curto. Esta leitura não atualiza o Jira. Integrações agendadas que precisam de comentários frescos do Jira podem primeiro chamar POST /api/jira/comments-refresh com uma chave de API autorizada de propriedade do gerente. Use IDs de comentário e revisões de conteúdo para distinguir novos comentários de edições, e não afirme um relatório de atividade completo se a atualização falhar.
link_bug_reports — Cria um link semântico direcional entre dois relatórios no mesmo projeto autorizado. Para parent-of, o relatório de origem deve ser um Epic e o relatório de destino um filho padrão. Prefira parent_epic_id na criação/atualização para atribuição de Epic.
unlink_bug_reports — Remove um link de relatório de bug criado anteriormente pelo seu UUID (link_id, retornado por link_bug_reports ou list_bug_report_links).
list_bug_report_links — Lista todos os links curados pelo usuário que tocam um relatório de bug. Retorna cada link conforme lido da perspectiva do relatório fornecido — por exemplo, uma linha armazenada duplicate-of onde este relatório é o destino renderiza como duplicated-by; parent-of onde este relatório é o destino renderiza como subtask-of; depends-on onde este relatório é o destino renderiza como blocks; testing-blocked-by onde este relatório é o destino renderiza como blocks-testing. related-to é simétrico. Complementa o campo similar_reports auto-detectado retornado por get_bug_report.
classify_bug — Classifica uma descrição em um dos 19 tipos de relatório (bugs, recursos, melhorias, etc.) com pontuação de confiança
flush_reports — Exclusão em massa de relatórios antigos (somente admin)

📊

Uso e Análises

get_usage — Verifica o uso em relação aos limites do plano. Chamadores com chave de API exigem usage:read.
get_stats — Contagens diárias, detalhamentos por tipo/severidade/status

📁

Gerenciamento de Projetos

list_projects — Lista projetos acessíveis com id, name, slug, ticket_prefix, descrição e status padrão. Use esses valores com ferramentas de relatório de bug e catálogo de testes para direcionar o projeto correto.
create_project — Cria um novo projeto (torna-se automaticamente o padrão se for o primeiro)
delete_project — Exclui permanentemente um projeto e todos os dados associados (relatórios de bug, automações, casos de teste, aplicativos móveis, agendamentos, snaps geográficos, notas, entradas de tempo). Somente proprietário/gerente. Não é possível excluir o último projeto. O armazenamento é liberado automaticamente
export_okf_bundle — Exporta o conhecimento de QA de um projeto — relatórios de bug, casos de teste, automações e testes de desempenho, segurança e exploratórios — como um pacote markdown OKF/OQA (o formato Open Query Agent usado por oqa.ai). Padrão para o projeto ativo; passe o project opcional (slug ou nome) para exportar um diferente. Retorna a lista de arquivos no pacote além do próprio pacote como um zip codificado em base64

🔐

Autenticação e Conta

register_account — Cria uma nova conta (senha: 8-128 caracteres, limitada a 5/15min)
login — Entra e recebe tokens de acesso (limitado a 5/15min)
update_profile — Atualiza o nome de exibição
change_password — Altera a senha da conta
get_settings — Lê perfil e preferências de notificação.
update_settings — Atualiza perfil e preferências de notificação suportados. Mutação somente via OAuth.

🔑

Gerenciamento de Chaves de API

generate_api_key — Cria uma chave de API nomeada
list_api_keys — Lista chaves ativas (somente prefixo)
regenerate_api_key — Revoga e substitui uma chave
delete_api_key — Revoga permanentemente uma chave

👥

Gerenciamento de Equipe

list_workspaces — Lista os workspaces aos quais você pertence, seu papel em cada um e qual a sessão usa por padrão. Hosts multi-workspace podem fixar uma solicitação com o cabeçalho X-BugAgent-Workspace (somente membros ativos)
list_team_members — Lista todos os membros do seu workspace com papéis, status e flags de booster
invite_team_member — Convida um usuário por e-mail (gerentes podem convidar contribuidores e gerentes; somente proprietários podem convidar admins). Link de expiração em 5 dias

🎯

Integrações

A sincronização de relatórios do Jira Cloud está incluída nos planos Free e Enterprise. Um gerente do workspace deve primeiro conectar o Jira no painel. Chaves de API do workspace podem então usar jira:read para comparação e jira:write para sincronização/merge; limites do plano Atlassian e da API ainda se aplicam.

sync_to_jira — Envia um relatório para o Jira usando a conexão compartilhada da equipe. Roteia para o projeto Jira mapeado ao projeto bugAgent do relatório (padrão do workspace como fallback), usando seu mapa de campos: v2 separa prioridade e severidade personalizada, enquanto mapeamentos sem versão mantêm a tradução legada de severidade para prioridade. O opcional projectKey pode selecionar apenas esse mapeamento configurado ou o padrão do workspace; projetos Jira arbitrários são rejeitados. Normalmente você não precisa disso: quando o modo de sincronização do projeto é auto_new ou auto_all, os relatórios que você cria são enviados automaticamente — chame isso para um envio manual no modo manual.
check_jira_sync — Comparação somente leitura de título e status, prioridade e severidade mapeados para um relatório vinculado autorizado. Usa o projeto salvo do relatório e a conexão Jira. A versão 2 mapeia a Prioridade do Jira separadamente de um campo de Severidade personalizado suportado; mapeamentos sem versão mantêm o comportamento legado de prioridade para severidade. Esta ferramenta não compara comentários, anexos, tipo ou todos os campos do Jira.
merge_jira_sync — Mescla esses campos mapeados usando prefer: jira para puxar valores do Jira ou prefer: bugagent para enviar valores locais. Envios de status usam transições de fluxo de trabalho legais do Jira. Conflitos de saída não mapeados, gravações remotas com falha e alterações locais concorrentes retornam erros em vez de afirmar que tudo está sincronizado. Comentários e anexos permanecem fluxos de sincronização separados no dashboard. Gravações entre sistemas não são atômicas.
push_to_claude — Gera (ou regenera) as Notas do Desenvolvedor para um relatório de bug — causa raiz, correção sugerida, etapas de verificação e avaliação de risco. Aceita UUID ou ID curto (WRKID-545). Usa chaves da plataforma — nenhuma conexão Claude por equipe necessária. Executa uma cadeia adaptativa: três etapas em bugs s3 / medium ou s4 / low (rascunho Sonnet → crítica OpenAI gpt-5 → síntese Sonnet), cinco etapas nos dois buckets de severidade mais altos — s1 / critical ou s2 / high — (rascunho → crítica → réplica Sonnet → árbitro Claude Opus que lê a transcrição completa e escreve as notas finais com julgamento independente). A resposta expõe cada rodada: analysis, draft, critique, rebuttal, challenger_model, adjudicator_model e um sinalizador debated. Qualquer etapa com falha recai para a próxima melhor resposta. Dispara automaticamente na criação do bug; geralmente chamado apenas para regeneração manual.
analyze_fix_area — Gera (ou regenera) o sub-bloco "Área Provável da Correção" das Notas do Desenvolvedor — uma saída estreita do Sonnet que nomeia onde no código a correção provavelmente pertence. Aceita UUID ou ID curto. Usa a chave Anthropic da plataforma. Quando a equipe tem uma linha github_connections e o projeto tem um github_repo mapeado, a saída é fundamentada em trechos reais de arquivos do repositório conectado; caso contrário, recai para orientação geral com um incentivo para conectar um repositório. Retorna texto likely_fix_area, generated_at, repo_used e um sinalizador grounded. Dispara automaticamente na criação do bug — agentes normalmente só precisam chamar isso para regeneração manual.
upgrade_plan — Obtenha o link de inscrição Enterprise assistida por vendas

⚡

Testes de Performance

create_performance_test — Crie uma configuração de teste de performance com URL, dispositivo, usuários virtuais, duração, limite de pontuação e alternância de criação automática de bug. Somente Enterprise
run_performance_test — Dispare uma auditoria de página e teste de carga para um teste de performance web. Retorna um ID de execução para consultar os resultados. Execuções de perfil de aplicativo móvel são disparadas pelo dashboard
get_performance_results — Obtenha resultados completos incluindo pontuações Lighthouse (Performance, Acessibilidade, Boas Práticas, SEO), Core Web Vitals (LCP, FID, CLS, FCP, TTFB, INP, TBT, SI) e métricas de teste de carga (VUs, requisições, RPS, latências p50/p90/p95/p99)
list_performance_tests — Liste todas as configurações de teste de performance para a equipe atual
get_performance_usage — Verifique o uso mensal de teste de performance. Teste de performance é somente Enterprise. Gratuito=0, Enterprise=ilimitado

Fluxo de Trabalho de Exemplo

get_performance_usage → verifique a cota restante
create_performance_test → configure um teste para sua URL
run_performance_test → dispare a auditoria + teste de carga
get_performance_results → revise pontuações e métricas vitais

🛡

Varredura de Segurança

create_security_scan — Crie uma configuração de varredura de segurança. Varreduras web usam Quick Scanner + Nuclei (mais de 4.000 modelos) com três níveis de profundidade e varredura autenticada opcional. Varreduras móveis usam MobSF para análise binária APK/IPA. Criação automática de bug configurável com limites de severidade. Somente Enterprise
run_security_scan — Dispare uma varredura de vulnerabilidade. Varreduras web exigem verificação de domínio DNS. Varreduras móveis exigem um aplicativo enviado. Retorna um ID de execução para consultar os resultados
get_security_results — Obtenha resultados completos incluindo pontuação de segurança (0-100), descobertas categorizadas por severidade (Crítica, Alta, Média, Baixa, Info) com referências CWE, mapeamentos OWASP, evidências e orientação de remediação
list_security_scans — Liste todas as configurações de varredura de segurança para a equipe atual com última pontuação e selos de autenticação/profundidade
get_security_usage — Verifique o uso mensal de varredura de segurança. Varredura de segurança é somente Enterprise. Enterprise=ilimitado
list_security_schedules — Liste todas as varreduras de segurança agendadas para a equipe com cron, fuso horário, estado habilitado, próxima execução e configurações de notificação. Junta com a configuração de varredura pai (nome, scan_type, target_url)
create_security_schedule — Crie um agendamento recorrente para uma varredura de segurança. Requer scan_id e cron_expression. Um agendamento por configuração de varredura. Opcionais timezone, notify_on_fail (nenhum/email/slack/ambos), notify_email, slack_channel_id. Cada execução conta contra seu limite mensal; usuários administradores ignoram o limite. A profundidade da varredura é sempre lida da configuração de varredura no momento da execução
delete_security_schedule — Exclua uma varredura de segurança agendada. Não afeta a configuração de varredura pai ou execuções concluídas

Fluxo de Trabalho de Exemplo

get_security_usage → verifique a cota restante
create_security_scan → configure uma varredura para sua URL ou repositório
run_security_scan → dispare uma varredura de vulnerabilidade única
create_security_schedule → automatize execuções recorrentes (ex.: SAST semanal no branch principal)
get_security_results → revise descobertas e remediação

📖

Revisão de Código

list_code_reviews — Liste revisões de código de IA recentes para a equipe. Retorna pontuações de qualidade, contagens de severidade, informações de PR e carimbos de data/hora. Somente Enterprise
get_code_review — Obtenha uma revisão de código com todas as descobertas. Cada descoberta inclui severidade, categoria (bug/segurança/performance/estilo/lógica/manutenibilidade), título, descrição, sugestão de código, caminho do arquivo e números de linha
get_code_review_usage — Verifique o uso de revisão de código. Revisão de código de IA é somente Enterprise; ilimitado no Enterprise
get_code_review_analytics — Obtenha análises de revisão: tendências, categorias/origens de descobertas, detalhamento de severidade, métricas de velocidade, principais repositórios/autores. Suporta retrospectiva de 7/30/90 dias

Fluxo de Trabalho de Exemplo

get_code_review_usage → verifique revisões restantes
Revise um PR no dashboard em /dashboard/code-review
list_code_reviews → veja revisões recentes
get_code_review → obtenha descobertas e sugestões

🔍

IA Exploratória

Localizador de bugs de site autônomo multiagente com até 10 agentes paralelos, cada um usando uma estratégia de teste diferente.

list_explorations — Liste configurações de IA Exploratória para a equipe
create_exploration — Crie uma nova exploração. Aceita agent_count (1–10, máx. 10) para executar vários agentes paralelos com estratégias únicas: happy_path, edge_case, security, accessibility, error_path, performance, mobile, data_integrity, navigation, custom. Esta ferramenta não pode configurar credenciais ou modo de autenticação. Configure e lance Somente fluxo de login de teste explicitamente pelo dashboard ou REST, depois use get_exploration e get_exploration_run para inspecionar configuração e resultados. Nunca infira o modo a partir de instruções ou coloque credenciais em argumentos MCP. Exploração baseada em credenciais padrão ainda requer uma sessão reutilizável.
get_exploration — Obtenha configuração de exploração com configurações de agente, metadados de autenticação segura e execuções recentes. Senhas e texto cifrado nunca são retornados.
get_exploration_run — Obtenha resultados de execução com progresso por agente, dados de fase, descobertas com atribuição de agente (agent_index, agent_strategy) e bugs vinculados
get_exploration_usage — Verifique o uso mensal. IA Exploratória é somente Enterprise; Enterprise: ilimitado (10 agentes)

Fluxo de Trabalho de Exemplo

create_exploration com agent_count: 5 → configure 5 agentes paralelos
Dispare uma execução pelo dashboard ou via POST /api/explorations/run
get_exploration_run → consulte o progresso por agente e descobertas
Veja descobertas deduplicadas com atribuição de agente no dashboard

📝

Notas

list_notes — Liste notas com filtros opcionais de palavra-chave, projeto, visibilidade, pasta, tag, arquivo, wiki, intervalo de datas e classificação. Retorna notas que o usuário possui ou notas compartilhadas com ele.
create_note — Crie uma nota em um dos 5 formatos: markdown, plain, bugtemplate, checklist, outline. Defina visibility para private ou shared. Título automático dos primeiros 30 caracteres se nenhum título for fornecido. Matriz opcional attachments aceita arquivos codificados em base64 de até 400 MB cada: qualquer imagem, vídeo, áudio, PDF ou texto/JSON. Passe time_spent_seconds para rastrear esforço de QA.
get_note — Obtenha detalhes completos da nota incluindo conteúdo e anexos. Requer id.
update_note — Atualize título, conteúdo, formato, visibilidade, projeto ou time_spent_seconds. Passe uma matriz attachments para anexar novos arquivos (máx. 400 MB cada) aos anexos existentes da nota sem substituí-los. Somente o autor pode atualizar. Requer id.
delete_note — Exclua permanentemente uma nota e seus anexos. Somente o autor pode excluir. Requer id.
list_note_folders — Liste pastas de notas/wiki, opcionalmente com escopo para um projeto.
create_note_folder — Crie uma pasta de notas/wiki com escopo de projeto com configurações opcionais de pai, visibilidade, favorito e acesso de colegas de equipe.

Fluxo de Trabalho de Exemplo

create_note → inicie uma nota de sessão de teste
update_note → anexe observações enquanto testa
list_notes → pesquise notas passadas por palavra-chave ou projeto
get_note → recupere nota completa com anexos

🤖

Automação

create_automation — Crie uma nova automação com um script Playwright personalizado (nenhuma gravação FAB necessária). Requer name. Opcional: target_url (derivado automaticamente da primeira URL page.goto(...) no script se omitido), script (Node.js/JavaScript/TypeScript ou Python — a linguagem é detectada automaticamente; o padrão é um placeholder), status (draft ou active, padrão: draft), project_id. Retorna o id da automação. Dica — Duplicar uma automação: use get_automation para buscar o script original e, em seguida, chame create_automation com name definido como "[Copy] Original Name" e passe o script, target_url e project_id originais. A duplicata começa com status draft e sem histórico de versões.
list_automations — Liste scripts de automação Playwright. Filtre por project_id ou status (draft, active, paused). Retorna uma matriz de automações com nome, target_url, last_run_status e run_count.
get_automation — Obtenha detalhes completos da automação, incluindo o script Playwright e execuções recentes. Requer id. Retorna a automação com o script ativo, uma pilha script_versions (do mais antigo para o mais recente, até 100 entradas anteriores, cada uma com { script, source, timestamp }) e uma matriz recent_runs em que cada execução carrega o script_version_label / script_version_source que foi executado. Chame isso antes de run_automation se precisar escolher uma versão histórica específica.
run_automation — Acione uma execução imediata de um teste Playwright. Requer automation_id. Localizadores de autocorreção (automáticos): quando uma ação de localizador expira, o executor pergunta ao Claude por um seletor funcional e tenta a etapa novamente uma vez — as asserções nunca são corrigidas, portanto, regressões reais ainda falham — e cada correção é registrada na saída padrão da execução. Modo de emulação (padrão): device opcional para um perfil de dispositivo emulado (por exemplo, desktop, iphone-15). Modo real: defina browserstack: true com bs_browser (chrome, firefox, safari, edge), bs_os (Windows, OS X) e bs_os_version para executar em um navegador de desktop real. Celular real: defina bs_os: "android" (dispositivos: "Samsung Galaxy S25 Ultra", "Google Pixel 10", "OnePlus 13R") ou bs_os: "ios" (dispositivos: "iPhone 17 Pro Max", "iPhone 16 Pro Max", "iPhone 15 Pro Max") e passe o nome do dispositivo em bs_os_version. Ambos os modos são executados em segundo plano; Real descreve o ambiente de execução, não uma sessão interativa visível. Scripts Node.js passam por browserstack-node-sdk (cobre desktop + Android + iPhone). Scripts Python passam por browserstack-sdk (pytest-playwright) e cobrem apenas desktop — celular real via Python não é suportado porque o browser_type.connect() do pytest-playwright não pode acionar os endpoints de celular real do BrowserStack. Vídeo e logs de rede são capturados automaticamente; logs de console apenas para desktop. Repetição de versão: inspecione script_versions com get_automation e, em seguida, passe o version_label durável preferido (por exemplo, "v103"). O version_index legado permanece suportado, mas não deve ser combinado com version_label. Padrão: quando ambos os seletores são omitidos, o script salvo atual é executado. Rótulos podados e índices inválidos são rejeitados em vez de executar silenciosamente o atual. O registro da execução armazena o snapshot exato que foi executado, e qualquer relatório de bug criado automaticamente a partir de uma execução com falha vincula-se diretamente a essa versão no editor.
list_automation_runs — Liste execuções recentes de uma automação. Requer automation_id. Retorna execuções com status, duration_ms e error_message.
list_schedules — Liste todas as execuções de automação web agendadas com cron_expression anulável, run_at anulável, once_status, fuso horário, dispositivo e configurações de notificação. Linhas recorrentes mantêm run_at e once_status nulos; linhas únicas têm cron nulo. Estados únicos: pending, claimed, missed, dispatched, failed, uncertain. Esses são estados de despacho, não resultados de teste; inspecione list_automation_runs para obter resultados.
Agendamentos web recorrentes: create_schedule valida cinco campos numéricos de cron e o fuso horário, e retorna um next_run_at UTC futuro. Recorrências mensais e anuais são suportadas. Por exemplo, 30 12 23 9 * em America/Toronto significa 23 de setembro às 12:30 todos os anos, não uma execução única. Tempo inválido ou impossível é rejeitado antes da criação. Quando tanto o dia do mês quanto o dia da semana são restritos, ambos devem corresponder. Horários de horário de verão inexistentes são ignorados; horários repetidos na parede podem ocorrer duas vezes. O despacho ocorre na próxima sondagem do agendador, não necessariamente no minuto exato. O comportamento recorrente existente permanece inalterado.
Agendamentos web únicos: chame create_schedule com { "automation_id": "AUTOMATION_UUID", "run_at": "2030-12-15T09:30:00-05:00", "timezone": "America/Toronto" }, escolhendo uma data futura e omitindo cron_expression. Forneça exatamente um campo de tempo. run_at requer um timestamp ISO 8601 futuro com deslocamento qualificado (deslocamento explícito ou Z); o fuso horário IANA é apenas para exibição. Um agendamento pendente habilitado é executado na primeira sondagem de cron após o vencimento; mais de uma hora de atraso é marcado como missed. Ele é reivindicado atomicamente e desabilitado antes do despacho, e não pode ser reabilitado após o consumo. Falhas de despacho definitivas são failed; despacho ambíguo é uncertain e nunca é repetido automaticamente. Verifique as execuções antes de agendar outra tentativa. dispatched não significa concluído ou aprovado. A criação é apenas via API/MCP, não um novo modo de criação no painel.
Os fusos horários de agendamento web são identificadores IANA, como America/Argentina/Buenos_Aires. O seletor do painel inclui todas as regiões e cidades suportadas pelo servidor e usa como padrão o fuso horário do seu perfil; o padrão de fuso horário do MCP permanece UTC.
create_schedule — Crie uma execução de automação web agendada. Requer automation_id e exatamente um de cron_expression ou run_at. Suporta configurações opcionais de dispositivo, fuso horário, notificação de falha, e-mail e canal do Slack. Conecte o Slack pelo painel primeiro e escolha um canal do qual o bot participe; apenas a instalação do webhook é insuficiente. Veja Configuração do Slack e descoberta de canais.
Implantação e recuperação únicas: aplique a migração de banco de dados 374_one_time_web_schedules.sql antes de implantar o código correspondente de API/MCP e agendador. claimed pode persistir após uma falha do worker: inspecione o histórico de execuções antes de criar uma substituição para despacho reivindicado ou incerto. Um timestamp com mais de uma hora de atraso nunca é executado automaticamente.
Automações web em rascunho: ative a automação antes de criar um agendamento, reativar um agendamento ou alterar sua expressão cron ou fuso horário. create_schedule verifica o acesso ao workspace e ao projeto antes de rejeitar o status de Rascunho. Agendamentos existentes pulam ciclos enquanto a automação está em Rascunho; pausar, excluir, fixar e alterações apenas de notificação permanecem disponíveis. Não há ferramenta MCP web update_schedule; use o painel para essas atualizações.
delete_schedule — Exclua uma execução de automação web agendada
list_mobile_schedules — Liste todas as execuções de automação móvel agendadas com dispositivos, cron, fuso horário e notificações
create_mobile_schedule — Crie uma execução de automação móvel agendada em dispositivos reais. Requer automation_id e cron_expression; devices é opcional.
delete_mobile_schedule — Exclua uma execução de automação móvel agendada
optimize_automation_script — Envie um script Playwright para o Sonnet 4 para otimização com IA. Aplica uma lista de verificação de 12 pontos que corrige seletores, estratégias de espera, asserções, tratamento de erros, padrões de autenticação, compatibilidade móvel e modo estrito. Requer automation_id. A versão atual do script é salva antes da otimização. Retorna o script otimizado e um resumo das alterações.
undo_automation_script — Reverta um script de automação para a versão anterior. Até 100 versões anteriores são retidas. Requer automation_id. Retorna o script restaurado e o número de versões restantes.

Exemplo de Fluxo de Trabalho

create_automation → crie um teste com um script personalizado
list_automations → navegue pelos testes disponíveis
get_automation → inspecione o script Playwright
run_automation → acione o teste
list_automation_runs → verifique os resultados e a duração

⏱️

Controle de Tempo

list_time_entries — Liste as entradas de tempo da equipe. Filtre por period (today, week, month, all), project_id, category e sort (newest, oldest, most_time, least_time). Apenas plano Enterprise.
create_time_entry — Registre o tempo gasto em tarefas de QA. Requer description, category e duration_minutes. Opcionalmente, defina project_id e entry_date (o padrão é hoje). Apenas plano Enterprise.
update_time_entry — Atualize uma entrada de tempo existente. Requer id. Pode atualizar description, category, duration_minutes, project_id ou entry_date. Apenas plano Enterprise.
delete_time_entry — Exclua permanentemente uma entrada de tempo. Requer id. Apenas plano Enterprise.

Exemplo de Fluxo de Trabalho

create_time_entry → registre 45 minutos de teste de regressão
list_time_entries → veja as entradas de tempo desta semana
update_time_entry → ajuste a duração ou a categoria
delete_time_entry → remova uma entrada incorreta

☑️

Casos de Teste

Gerenciamento de testes com pastas hierárquicas, suítes aninhadas (até 3 níveis de profundidade com expansão automática de sub-suítes nas execuções), reordenação por arrastar e soltar e uma aba de Relatórios de análise com tendências de KPI, análise de falhas, saúde da suíte, cobertura e produtividade do testador. Todas as ferramentas chamam o Supabase diretamente — sem ida e volta HTTP, mesma latência do painel.

Limites gratuitos: 10 casos de teste armazenados, 1 suíte, 3 pastas, 128 KB de conteúdo estruturado por caso, 2 chaves de API de workspace ativas e 10 execuções de teste totais por mês civil UTC. Até 3 dessas execuções podem usar o Hermes ou outro agente externo, com 1 execução externa ativa e no máximo 10 casos em cada plano externo. O tráfego MCP gratuito de chave de API é limitado a 30 solicitações por chave e 60 por workspace por minuto. O armazenamento e as execuções de casos de teste Enterprise são ilimitados, sujeitos às proteções gerais da plataforma.

Geração de casos de teste com IA, sugestões de tags com IA, importação do Figma e anexos de arquivos de casos de teste exigem Enterprise. O limite gratuito de 128 KB de conteúdo estruturado é separado dos anexos de arquivos Enterprise. O plano gratuito pode armazenar referências de URL. As ferramentas principais de casos de teste MCP permanecem disponíveis no plano gratuito dentro dos limites acima.

Execução sem usar as mãos: a página de revisão de execução é um carrossel com um caso visível por vez, atalhos de teclado (P Passar · F Falhar · B Bloquear · S Pular) e controle por voz. Clique no microfone e diga "Passar", "Falhar", "Bloquear", "Pular", "Próximo", "Anterior", "Adicionar notas" (transcreve para o campo de notas), "Salvar notas" ou "Voz desligada". Avança automaticamente para o próximo caso não testado em resultados de sucesso; permanece no lugar em Falhar para que os testadores possam ditar detalhes e gerar um bug. Funciona no Chrome, Edge e Safari.

Casos e Pastas

list_test_cases — Lista casos de teste acessíveis com um seletor opcional project além dos filtros search, priority, type, status e sort. Adicione folder_id (null para não arquivado) ou suite_id para associação direta, sem descendentes. Chamadas com chave de API exigem test_cases:read. limit tem como padrão 50 (1-200); offset tem como padrão 0 (0-1000000). O array inalterado cases é acompanhado por total / total_count para todas as correspondências autorizadas, limit, offset, has_more e next_offset anulável. Anteriormente, total significava incorretamente tamanho de página. Siga next_offset até null; não infira conclusão pelo tamanho da página. Uma continuação além do offset 1000000 falha explicitamente; restrinja os filtros em vez de receber um cursor inutilizável ou conclusão falsa. Páginas que excedam 1 MiB de dados de caso falham explicitamente: tente novamente com um limite menor, em vez de aceitar registros omitidos. A desempate por ID estável é usado, mas edições concorrentes podem deslocar páginas de offset.
Exemplo de paginação: chame list_test_cases com {"project":"test-bed","limit":50,"offset":0}. Para 55 correspondências, a resposta tem total:55, has_more:true, next_offset:50. Repita com offset:50 para os cinco restantes e has_more:false, next_offset:null.
create_test_case — Cria um caso de teste no seletor obrigatório project (UUID, slug, nome exato ou prefixo de ticket; chame list_projects primeiro). Duas variantes de modelo: steps (padrão) — grade { action, expected } por etapa via array steps; text — descrição única de formato livre via text_content. Ambos os campos podem ser enviados na mesma chamada. O array opcional urls (máx. 10 URLs http/https) anexa links de referência e está disponível no Free. Anexos de arquivo exigem Enterprise e uma sessão de dashboard. Chamadas com chave de API exigem test_cases:write.
Recuperação de paginação: solicitar um offset de caso além dos resultados disponíveis retorna um erro explícito; reinicie no offset 0. Isso também pode acontecer quando casos são removidos entre solicitações. Siga a continuação retornada em vez de adivinhar o próximo offset.
Identificadores de caso: list_test_cases, get_test_case, create_test_case e update_test_case retornam o UUID id, o short_id imutável (por exemplo, TEST-BA-CASE-123) e o case_number numérico, incluindo respostas compactas de atualização/sem operação. Casos legados sem projeto usam TEST-CASE-123. Identificadores ausentes são retornados como null; use o UUID como fallback. O banco de dados atribui identificadores; chamadores não podem alterá-los ou escolhê-los durante a criação. Uma renomeação de prefixo não reescreve IDs existentes.
Consulta de caso único: get_test_case e update_test_case aceitam um UUID ou ID curto completo em id; link_test_case_to_bug e list_test_case_links aceitam qualquer um em case_id. Espaços em branco ao redor, maiúsculas/minúsculas e preenchimento numérico são normalizados antes da consulta exata no workspace ativo. A autorização usa o workspace e o projeto armazenados, não o prefixo do ID. Números simples, IDs parciais e pesquisas com curinga não são aceitos. Arrays de casos em massa, case_id de resultado de execução, IDs de bug, IDs de pasta e IDs de suíte permanecem somente UUID. Registros de link mantêm o UUID case_id.
Lacunas de numeração: os números de caso não precisam ser contíguos. Editar uma URL ou incrementar um número pode levar a um caso ausente ou inacessível; não é uma ação garantida de próximo caso. Descubra casos com a ferramenta de lista e siga a paginação dela.
Escopo do workspace: o mesmo ID curto pode existir em workspaces diferentes. O MCP o resolve apenas no workspace ativo; alterne o contexto do workspace antes de usar o ID curto de outro workspace. Ao compartilhar uma URL de ID curto do dashboard, preserve ?team=<case.team_id>, por exemplo, /dashboard/test-cases/TEST-BA-CASE-123?team=<team-uuid>. Permalinks UUID mantêm o comportamento autorizado entre workspaces existente. O MCP não constrói um permalink.
get_test_case — Obtém o registro de caso autorizado, incluindo etapas e identificadores. Não carrega histórico de alterações ou histórico de execução. Exemplo: {"id":"TEST-BA-CASE-123"}.
Estimativas de execução: get_test_case retorna estimated_time_seconds e o alias de compatibilidade estimated_time, ambos em segundos. Um 0 armazenado permanece 0; uma estimativa desconhecida ou ausente é null. O campo canônico vence quando ambos os nomes estão presentes, incluindo um null explícito; valores somente legados de estimated_time são tratados como segundos sem conversão. list_test_cases usa estimated_time_seconds. A entrada create_test_case permanece estimated_time, também em segundos; solicitações e respostas REST usam estimated_time_seconds.
list_test_case_folders — Lista pastas acessíveis. Limitado a 500; aceita um seletor flexível project e filtro parent_folder_id (use "root" para somente nível superior). Chamadas com chave de API exigem test_cases:read.
get_test_case_folder — Lê uma pasta de caso de teste diretamente com id obrigatório (UUID). Retorna apenas o registro da pasta, sem carregar implicitamente pastas descendentes ou casos de teste. Exige acesso ao workspace e ao projeto; chamadas com chave de API exigem test_cases:read.
Valores de type de caso de teste para list_test_cases, create_test_case e bulk_update_test_cases: functional (padrão de criação), regression, smoke, integration, performance, security, usability, exploratory. Tipos inválidos são rejeitados antes da gravação. Use integration para fluxos de ponta a ponta; e2e, accessibility e other não são tipos de caso de teste aceitos. Tipos de script de automação são um contrato separado.
create_test_case_folder — Cria uma pasta no project obrigatório retornado por list_projects (aninha até 3 níveis via parent_folder_id). Exige acesso de colaborador ou superior ao workspace e acesso ao projeto. Chamadas com chave de API também exigem test_cases:write.
update_test_case_folder — Atualiza por UUID de pasta: id, name opcional (aparado, 1-120 caracteres), description anulável (máx. 50000 caracteres), parent_folder_id anulável e card_color anulável. Um UUID pai move a pasta e sua subárvore dentro do mesmo workspace e projeto; null move para a raiz. Cor aceita a paleta em minúsculas #1e293b, #7c2d12, #713f12, #14532d, #1e3a5f, #312e81, #581c87, #831843, #4a044e, #fef08a, #fca5a5, #93c5fd; null limpa. Campos omitidos são preservados. Pelo menos um campo de atualização é obrigatório. Campos desconhecidos, com erro de digitação ou inválidos rejeitam a solicitação inteira sem salvar alterações. Ciclos próprios/descendentes, nomes correspondentes a um irmão, pai direto ou filho direto (ignorando maiúsculas/minúsculas e espaços ao redor) e profundidades de subárvore acima de 3 (profundidade raiz 0) são rejeitados. Profundidades descendentes são atualizadas atomicamente; IDs de caso e associações não mudam. Alterações concorrentes conflitantes podem falhar; releia a pasta antes de tentar novamente. Exige acesso ativo de colaborador ou superior ao projeto e test_cases:write para chaves de API. Exemplo: {"id":"folder-uuid","card_color":"#93c5fd"}. Retorna o id atualizado, team_id, project_id, name, description, card_color, parent_folder_id, depth e updated_at. Leituras de obter/listar pastas também incluem card_color.
update_test_case — Aplica patch em um caso existente por UUID ou ID curto completo em id, com pelo menos um campo: name (ou alias title), description, preconditions, steps, template_type, text_content, priority, type, status ou folder_id. Campos omitidos são preservados; steps substitui o array completo ([] limpa). null explícito limpa descrição, pré-condições, text_content ou posicionamento de pasta; text_content vazio também limpa. Se name e title forem enviados, devem corresponder. Prioridade e tipo usam os enums de criação; status é active, draft ou deprecated. Uma alteração de tipo alinha type_tags com o novo tipo, correspondendo à API PATCH. Sem movimentações de workspace/projeto ou gravações de metadados de arquivo. Pastas devem compartilhar exatamente o mesmo workspace e projeto. Exige test_cases:write. Retorna o resumo do caso, id, short_id, case_number e changed; valores inalterados produzem changed: false. Uma atualização confirmada com uma entrada de histórico não confirmada retorna warnings; não repita a atualização para reparar o histórico. Em um erro de alteração concorrente, leia o caso novamente antes de tentar novamente. Associação de suíte é separada: use a ferramenta em massa abaixo, não suite_id nesta ferramenta. Nenhuma ferramenta de exclusão é exposta.
bulk_update_test_cases — Aplica uma ação a 1–500 UUIDs de caso; passe um ID para um único caso. set_folder aceita params.folder_id (UUID para mover, null explícito para desarquivar). add_to_suite e remove_from_suite aceitam params.suite_id; adicionar nunca remove outras associações nem move a pasta. Também suporta set_priority, set_status, set_type, add_tags, remove_tags, pin e unpin. Chaves de API exigem test_cases:write. Retorna applied, skipped e errors; ações de organização contam linhas alteradas confirmadas, deduplicam IDs e pulam associações existentes.
Posicionamento na criação: create_test_case aceita folder_id e suite_id opcionais. Descubra alvos com list_test_case_folders e list_test_suites (descoberta de suíte exige test_runs:read para chaves de API). Pastas são um único local de catálogo; suítes são associações de plano de teste muitos-para-muitos. Os alvos devem pertencer ao mesmo workspace autorizado e projeto exato, incluindo casos legados sem escopo. IDs de caso inacessíveis são pulados sem detalhes; alvos incompatíveis são rejeitados. Alvos de criação inválidos falham antes de criar um caso.
Criação parcial: a criação de caso e a anexação de suíte são gravações separadas. Se a anexação falhar, a resposta retorna o ID do caso criado, suite_id: null e um array warnings. Não repita create_test_case; tente novamente bulk_update_test_cases com add_to_suite para esse ID retornado.
link_test_case_to_bug — Estabelece rastreabilidade entre um caso de teste e um UUID de relatório de bug (verified_by, covers ou relates). Ambos os registros devem pertencer ao workspace ativo e aos projetos acessíveis ao chamador.
list_test_case_links — Lista todos os links de rastreabilidade para um caso de teste.
list_test_case_review_candidates — Sinalizadores de teste morto: never_run (90+ dias desde a criação), always_passes (5+ aprovações consecutivas em 90d), always_skipped (3+ pulos consecutivos).
mark_test_case_review_flags — Persiste os sinalizadores atuais de candidato a arquivamento em test_cases.review_flag. Executa automaticamente toda segunda-feira às 09:00 UTC via pg_cron.

Importações

Importação Figma (Enterprise) (somente sessão de dashboard): envie um export zip de frames do Figma (até 100 MiB), Claude analisa cada tela e cria casos de teste em uma pasta que você escolhe ou cria. Antes da decodificação, o arquivo é limitado a 1.000 entradas, 20 MiB expandidos (decodificados) por entrada e 100 MiB de dados expandidos agregados, incluindo arquivos e diretórios ignorados nos orçamentos. Buffers de frame decodificados devem corresponder aos tamanhos declarados. Arquivos malformados, incompatibilidades de tamanho e limites excedidos falham o trabalho antes da análise de IA; o upload original é retido em caso de falha para nova tentativa, sujeito à política de limpeza de armazenamento. Arquivos válidos entram em um pipeline de múltiplas passagens (classificar → casos por tela → casos de nível de fluxo entre telas de prefixo compartilhado → autocrítica) com cache de prompt, nova tentativa 429 e isolamento de erro de IA por frame. Casos chegam como status=active, marcados ai_generated=true, com source='figma' e source_frame_name preservando um link para o frame original. Usa a chave Anthropic da plataforma — nenhuma conexão Claude por equipe necessária.

Suítes & Execuções

list_test_suites — Lista até 50 suítes de teste acessíveis com um filtro flexível opcional project. Cada suíte inclui um inteiro exato case_count: casos atribuídos diretamente de todos os status, sem descendentes, excluindo casos de outros workspaces ou outros projetos (casos legados sem projeto permanecem incluídos). As contagens não são limitadas pelas linhas de associação buscadas. Chamadas via chave de API exigem test_runs:read para compatibilidade retroativa com workers de execução.
get_test_suite — Lê uma suíte de teste diretamente com o id obrigatório (UUID). Retorna apenas o registro da suíte, sem carregar implicitamente suítes filhas ou casos de teste membros. Exige acesso ao workspace e ao projeto; chamadas via chave de API exigem test_runs:read.
create_test_suite — Cria uma suíte no project obrigatório retornado por list_projects. Aninha até 3 níveis via parent_suite_id. Chamadas via chave de API exigem test_cases:write.
update_test_suite — Atualiza por UUID da suíte: id, name opcional (aparado, 1–120 caracteres), description anulável (máximo 50.000 caracteres) e status (ativo/arquivado). Campos omitidos e associação de casos são preservados. Exige acesso ativo de contribuidor ou superior ao projeto e test_cases:write. Movimentação de pai e fixação não são suportados; movimentação de pai exige manutenção atômica de profundidade dos descendentes. Retorna id, team_id, project_id, name, description, parent_suite_id, depth, status e updated_at. Exemplo: {"id":"suite-uuid","name":"Checkout regression","description":null}.
list_test_runs — Lista execuções de teste com nome da suíte, responsável e resumo de aprovação/reprovação.
create_test_run — Cria uma execução de suíte gerenciada pelo dashboard. Executar uma suíte pai inclui automaticamente todos os casos de todas as sub-suítes descendentes (um caso vinculado a ambas é adicionado exatamente uma vez). Cada linha de test_run_results registra de qual sub-suíte originária o caso veio, para que as páginas de resultados possam agrupar por origem.

Execução por Agente Externo

Estas ferramentas permitem que o Hermes ou outro runtime de agente execute uma suíte aprovada sem se tornar o sistema de registro de QA. Use uma chave com escopo de workspace contendo apenas test_runs:read e test_runs:write. A suíte fornece o limite do projeto; chamadores não podem sobrescrevê-lo.

start_test_plan — Inicia ou retoma um snapshot imutável de suíte com um external_run_id estável. Um ID repetido retorna a execução correspondente existente e a primeira página, em vez de criar uma duplicata.
get_test_run_plan — Lê o estado canônico da execução e uma página de plano estável. Passe o next_cursor anterior; as páginas têm como padrão 100 casos e são limitadas a 200.
report_test_results — Envia de 1 a 200 resultados com status passed, failed, blocked ou skipped. Repetições exatas são seguras; tentar sobrescrever um caso com outro status é rejeitado.
abort_test_run — Interrompe de forma idempotente uma execução interrompida, preservando resultados parciais aceitos e o resumo canônico.

Comportamento de cota: repita start_test_plan com o mesmo external_run_id para retomar a execução correspondente sem consumir outra execução. Excluir dados não redefine o uso mensal de execuções.

Limite de runtime: snapshots de casos excluem credenciais, corpos de arquivos e caminhos privados de anexos. As evidências de resultados são texto no MVP. As credenciais de destino permanecem no runtime de execução. Custos de navegador, modelo e rede permanecem do lado do cliente, e os clientes devem restringir o acesso ao destino e a saída de rede. Um humano permanece responsável pelas decisões de defeito e lançamento.

O guia do agente Hermes empacota este fluxo como uma skill comunitária mantida pelo bugAgent. O kit inicial público contém uma configuração pronta para cópia e uma skill instalável. Não é uma integração oficial da Nous Research.

Relatórios (análises Tier 1 + Tier 4)

get_test_reports_overview — KPIs principais para um período (taxa de aprovação, execuções concluídas, casos executados) com variações em relação ao período equivalente anterior. Os mesmos números exibidos na faixa de KPIs da aba Relatórios. Isso não cria um Relatório de Projeto salvo. Relatórios de Projeto XLSX Enterprise e seus agendamentos são gerenciados no dashboard; nenhuma ferramenta MCP está habilitada para esses artefatos salvos nesta versão.
get_test_reports_failures — Quatro listas de "o que corrigir?": failing_cases (≥50% de falha, mínimo 3 execuções), flaky_cases (mais alternâncias aprovação/reprovação), failing_suites (≥30% de falha, mínimo 5 execuções), regressed_cases (falha mais recente com aprovação anterior no período).

Fluxo de Trabalho de Exemplo

create_test_case_folder → crie uma árvore de pastas (ex.: Smoke → Auth). Use o ID da pasta retornado ao criar um caso de teste no mesmo projeto; o formulário de Novo Caso de Teste do dashboard também oferece criação de pasta inline.
create_test_case → defina casos; edite o conteúdo com update_test_case, organize a associação à suíte com bulk_update_test_cases
Ferramentas/chamada de exemplo: {"name":"update_test_case","arguments":{"id":"00000000-0000-4000-8000-000000000001","title":"Verify login rejection","steps":[{"action":"Submit an incorrect password","expected":"An error is shown; no session is created"}],"status":"active","folder_id":null}}. Prioridade, tipo e descrição omitidos permanecem inalterados.
create_test_suite → monte um plano de teste (sub-suítes opcionais, até 3 níveis de profundidade)
create_test_run → crie uma execução gerenciada por humano/dashboard a partir de uma suíte pai — sub-suítes incluídas automaticamente
start_test_plan → inicie ou retome uma execução de agente externo segura contra repetições
get_test_run_plan → recupere todas as páginas do plano imutável e execute-o no runtime selecionado
report_test_results → retorne lotes de resultados limitados; chame abort_test_run se a execução não puder continuar com segurança
get_test_reports_failures → pergunte "o que corrigir esta semana?" quando a execução for concluída
get_test_reports_overview → acompanhe a tendência da taxa de aprovação semana a semana

⚡

Team Booster

scale_team — Expanda instantaneamente sua equipe de QA com testadores booster. As contas são provisionadas automaticamente com acesso de testador. Especifique team_size (1–10), location, duration, budget e, opcionalmente, product_url, product_types e tech_levels. Disponível no plano Enterprise. Você não será cobrado até que a aprovação seja dada.

Fluxo de Trabalho de Exemplo

scale_team → provisione 5 testadores seniores nos EUA por 1 mês
list_team_members → verifique se novos testadores aparecem na sua equipe
list_bug_reports → revise relatórios registrados por testadores booster

📱

Testes Mobile (Enterprise)

Recursos mobile são limitados ao projeto. Passe project_id ou um seletor flexível project em criações, importações e listas filtradas. Automações herdam o projeto do aplicativo vinculado; caso contrário, o servidor usa o projeto padrão do workspace. Listas não filtradas podem ainda incluir linhas legadas de nível de workspace até que sejam migradas.

list_mobile_apps — Lista aplicativos enviados com filtros opcionais de project_id / project, platform e limit. Retorna o project_id de cada aplicativo para que os agentes possam manter operações subsequentes no mesmo projeto.
upload_mobile_app — Registra um aplicativo APK (Android) ou IPA (iOS) para testes em dispositivos reais. Requer name, platform (android / ios) e file_url; passe project_id para atribuí-lo ao projeto ativo. Para iOS, envie o IPA para execuções em dispositivos reais e use o painel para enviar um build de simulador .app para gravação.
update_mobile_app — Substitui um binário de aplicativo por uma nova versão. Limpa URLs em cache e builds de simulador para que todas as automações usem a nova versão na próxima execução. Requer app_id e file_url. Opcional: version. Perfis de login vinculados privados exigem seu criador ativo; perfis compartilhados exigem acesso ativo ao mesmo projeto. Agendamentos herdam o padrão de automação protegido.
list_mobile_automations — Lista automações mobile com filtros opcionais de project_id / project, app_id, status e limit. Os resultados incluem project_id e o ID do aplicativo vinculado.
create_mobile_automation — Cria um script de teste. Requer name, app_id, script_type (maestro para YAML, appium para Appium Python, appium_js para Appium JavaScript) e script; passe project_id quando o aplicativo ainda não estiver no escopo do projeto. Para um fluxo Maestro YAML autocontido e validado externamente, defina execution_mode como browserstack_maestro; caso contrário, o padrão é appium_actions. O appId do YAML deve corresponder ao pacote ou bundle ID armazenado do aplicativo vinculado; se nenhum estiver armazenado, o primeiro fluxo nativo validado o estabelece. IDs de aplicativo placeholder e IDs de recursos Android ofuscados são rejeitados. runFlow inline é suportado, mas referências externas a arquivos de fluxo/script são rejeitadas na v1. O Maestro nativo preserva comandos como inputRandomText e copyTextFrom, além de expressões em tempo de execução como ${maestro.copiedText} e ${output.value}. Um credential_id do mesmo projeto pode fornecer valores completos de inputText de ${USERNAME} / ${PASSWORD}. Um variable_profile_id do mesmo projeto pode salvar o padrão para valores de ${DATA_*} referenciados; cada chave referenciada deve existir. Perfis de dados são apenas dados sintéticos não secretos.
import_mobile_script — Importa um script de teste mobile existente e o transforma em uma automação executável, preservando os localizadores do desenvolvedor para que as execuções resolvam elementos com precisão. Dialetos suportados: Appium‑Python, WebdriverIO, Maestro (fluxos YAML) e Playwright (mobile‑web). Placeholders de ID de recurso Android ofuscados são ignorados e relatados no mapeamento de seletores warnings. Apenas aplicativos Android. Requer name, app_id e script; opcionais target_devices e project_id. Retorna a automação, além de action_count, dialect detectado e mapeamento de seletores warnings.
run_mobile_automation — Inicia uma automação mobile em um dispositivo real. Requer automation_id; opcionais device, os_version, credential_id e variable_profile_id nativo-Maestro. Para dados, omita variable_profile_id para herdar o padrão da automação, passe null para não usar perfil ou passe um UUID do mesmo projeto para substituir. Cada chave de ${DATA_*} referenciada deve existir. Um perfil de login privado exige seu criador ativo; um perfil de login compartilhado exige acesso ativo ao mesmo projeto. Valores exatos de credenciais conhecidas são filtrados e valores exatos de perfil de dados recebem filtragem de melhor esforço de evidências textuais persistidas; valores transformados, parciais, codificados ou derivados do aplicativo podem permanecer. Vídeos/capturas de tela privados autorizados permanecem disponíveis e podem mostrar valores renderizados pelo aplicativo testado, portanto, os perfis de dados devem conter apenas valores sintéticos não secretos. Se o contexto de redação de credenciais não estiver disponível ou a sanitização não puder ser comprovadamente segura, o texto detalhado com credenciais é omitido, enquanto status e evidências visuais disponíveis permanecem. Diagnósticos exigem autorização de workspace e projeto; links de mídia expiram após cinco minutos.
list_mobile_runs — Obtém resultados de execução mobile autorizados (status, dispositivo, resumo do resultado, links privados de vídeo e captura de tela, sessão BrowserStack, logs nativos Maestro com credenciais filtradas e falhas quando seguramente disponíveis, e qualquer bug criado automaticamente). Associação ao workspace e acesso ao projeto são aplicados para diagnósticos de execução. Filtros opcionais: project_id, automation_id, status (queued, running, passed, failed, error, archived) e limit. Execuções arquivadas são excluídas por padrão.
create_login_profile — Cria um perfil de usuário/senha criptografado somente gravação, reutilizável por Mobile, Web Automation e Exploratory AI. Requer project_id, name, username e password; visibility opcional é private (padrão) ou shared. Perfis privados são somente do criador. Perfis compartilhados são utilizáveis por membros ativos com acesso ao mesmo projeto.
create_mobile_credential — Nome de compatibilidade para create_login_profile; usa as mesmas entradas e limite de segurança.
list_login_profiles — Lista apenas perfis visíveis ao chamador, opcionalmente para um project_id. Retorna metadados não secretos, incluindo visibility; perfis privados de outros usuários e projetos inacessíveis são omitidos.
list_mobile_credentials — Nome de compatibilidade para list_login_profiles; nunca retorna segredos de credenciais.
update_login_profile — Renomeia, rotaciona ou altera visibility. O criador ativo pode atualizar qualquer campo. Um proprietário/admin ativo do workspace pode renomear ou rotacionar um perfil compartilhado, mas não pode alterar a visibilidade; perfis privados permanecem somente do criador.
update_mobile_credential — Nome de compatibilidade para update_login_profile; usa as mesmas verificações de propriedade e projeto.
delete_login_profile — Exclusão suave pelo criador, com recuperação de ciclo de vida por proprietário/admin apenas para perfis compartilhados. Padrões de uso futuro são limpos enquanto o histórico de auditoria permanece.
delete_mobile_credential — Nome de compatibilidade para delete_login_profile; referências históricas permanecem para auditoria.
create_mobile_variable_profile — Cria dados de teste sintéticos reutilizáveis e com escopo de projeto com project_id, name e um objeto variables como {"DATA_EMAIL":"qa@example.test","DATA_REGION":"ca"}. Chaves devem ser identificadores DATA_* em maiúsculas. Perfis permitem 1–100 strings, 4096 bytes UTF-8 por valor e 65536 bytes no total. Nomes reservados de credenciais/tempo de execução são rejeitados. Nunca armazene credenciais, tokens, dados pessoais de produção ou outros segredos.
list_mobile_variable_profiles — Lista perfis Mobile/Ambos e seus valores não secretos legíveis para um project_id autorizado. Regras de atribuição de projeto se aplicam. Perfis existentes e criação mobile usam both por padrão; criação/atualização aceitam platform (mobile ou both). Perfis somente web são excluídos do acesso ao catálogo mobile e do uso em tempo de execução.
update_mobile_variable_profile — Renomeia um perfil ou substitui seu objeto variables completo por id. Apenas o criador ativo ou um proprietário/admin ativo do workspace pode atualizá-lo.
delete_mobile_variable_profile — Exclusão suave de um perfil por id. Apenas o criador ativo ou um proprietário/admin ativo do workspace pode excluí-lo; padrões de automação são limpos enquanto referências históricas de execução permanecem.
list_mobile_schedules, create_mobile_schedule, delete_mobile_schedule — Lista, cria e remove agendamentos de dispositivos reais. Agendamentos herdam contexto do projeto, perfil de login e perfil de variáveis não secretas da automação selecionada. Perfis de login privados exigem seu criador ativo; perfis de login compartilhados exigem acesso ativo ao mesmo projeto. Perfis de variáveis não secretas mantêm sua política de criador-ou-proprietário/admin. Alterações e exclusão de agendamentos são restritas ao criador ativo do agendamento ou a um proprietário/admin ativo do workspace.

Catálogo de Dados de Teste Web

O mesmo catálogo de projeto não secreto está disponível no Automate Web. Essas ferramentas exigem o direito automation do workspace e o escopo de chave de API automations:write, incluindo leituras. Elas não exigem acesso Mobile. Valores nunca compartilham registros com Perfis de Login criptografados. O suporte ao catálogo ainda não vincula ou injeta valores de perfil em execuções web.

create_web_variable_profile: project_id, name, variables obrigatórios; platform opcional (web ou both), padrão web. Usa os mesmos limites DATA_* do mobile. Retorna o perfil, incluindo seu platform.
list_web_variable_profiles: project_id obrigatório; retorna { profiles: [...] } contendo apenas registros Web/Ambos.
get_web_variable_profile: id obrigatório; retorna um perfil Web/Ambos acessível e seus valores sintéticos.
update_web_variable_profile: id obrigatório; name opcional, substituição completa variables ou platform (web ou both). Requer o criador ativo ou proprietário/admin ativo do workspace. Para restringir Ambos para Mobile, use o catálogo Mobile com acesso Mobile.
delete_web_variable_profile: id obrigatório; mesmas permissões de gerenciamento. Exclusão suave e retorna { deleted: true }, mantendo o histórico de auditoria.

Exemplo: resolva um projeto usando list_projects, chame create_web_variable_profile com {"project_id":"PROJECT_UUID","name":"Canadian checkout","platform":"both","variables":{"DATA_REGION":"CA"}} e verifique com list_web_variable_profiles. Projetos/perfis inacessíveis falham sem expor seus valores; dados inválidos ou nomes duplicados em todo o projeto são rejeitados.

Exemplo de Fluxo de Trabalho — Android

list_projects → resolva o project_id de destino
upload_mobile_app → registre o APK nesse projeto
Grave com segurança no painel ou use import_mobile_script / create_mobile_automation
list_mobile_automations → resolva a automação no mesmo projeto
run_mobile_automation → acione-a em um dispositivo real, opcionalmente com um perfil de login
list_mobile_runs → verifique status, resumo do resultado, links visuais privados e metadados da sessão BrowserStack
Falhas criam automaticamente relatórios de bug com snapshot da falha e detalhamento das etapas

Exemplo de Fluxo de Trabalho — iOS

upload_mobile_app → registre seu IPA com project_id para execuções em dispositivos reais
Envie o build de simulador .app na página de detalhes do aplicativo (para gravação)
Grave o teste no navegador → ações capturadas do simulador
run_mobile_automation → acione a automação salva em um iPhone (usa o IPA)
update_mobile_app → substitua o IPA por uma nova versão quando estiver pronto

Exemplo de Fluxo de Trabalho — Maestro Nativo

upload_mobile_app → registre o APK ou IPA no projeto de destino
create_mobile_credential → opcionalmente, crie um perfil do mesmo projeto para um fluxo autenticado
create_mobile_variable_profile → opcionalmente, crie valores sintéticos DATA_* do mesmo projeto usados pelo fluxo
create_mobile_automation → passe um fluxo YAML conhecido e funcional com o pacote/bundle appId exato do aplicativo vinculado, script_type: maestro e execution_mode: browserstack_maestro. Use ${USERNAME} / ${PASSWORD} para login e placeholders estilo ${DATA_EMAIL} para entrada sintética; passe IDs de perfil para salvar padrões.
run_mobile_automation → selecione um dispositivo compatível e opcionalmente substitua o perfil de login ou variável. Omita o perfil de variável para herdar ou passe null para desativá-lo em uma execução.
list_mobile_runs → inspecione resumos autorizados de aprovação/reprovação, vídeo/capturas de tela privados, logs filtrados, nomes reais de etapas, falhas detalhadas e metadados de sessão. Se a sanitização segura não puder ser estabelecida para uma execução com credenciais, o texto detalhado é omitido enquanto status e evidências visuais disponíveis permanecem.

Refinar com IA: o beta na allowlist está disponível pelo painel e endpoints REST de refinamento. Nenhuma ferramenta MCP Refine faz parte do catálogo público ainda.

✅

Conformidade e Evidências (Enterprise)

collect_compliance_evidence — Acione a coleta automatizada de evidências dos serviços conectados (Cloudflare, GitHub, Sentry, Supabase, Railway). Retorna o ID da execução. Coleta configurações de SSL/TLS, status do WAF, alertas do Dependabot, tendências de erros, histórico de deploys e muito mais.
check_config_drift — Verifique todos os serviços conectados quanto a desvios de configuração de segurança em relação às linhas de base (modo SSL, versão do TLS, HSTS, regras do WAF, cabeçalhos de segurança).
generate_access_review — Crie um relatório trimestral de revisão de acessos. Audita membros da equipe, papéis, status de MFA, uso de chaves de API e gera recomendações (ex.: revogar chaves inativas).
get_security_events — Consulte a linha do tempo de eventos de segurança entre serviços. Filtre por fonte (cloudflare, sentry, github) e gravidade (critical, high, medium, low, info). Os eventos são correlacionados automaticamente entre os serviços.

Cobertura de Conformidade

Estas ferramentas ajudam com os requisitos de conformidade SOC2 (CC4.1, CC6.1, CC7.2, CC8.1), ISO 27001 (A.5.18, A.8.8, A.8.9, A.8.15-16, A.8.29) e GDPR (Art. 5, 25, 32, 33).

Clientes Compatíveis

O bug Agent funciona com qualquer cliente que suporte o Model Context Protocol. Aqui estão guias de configuração para clientes populares:

Abra Configurações → Desenvolvedor → Editar Config e adicione:

{
  "mcpServers": {
    "bugagent": {
      "type": "http",
      "url": "https://mcp.bugagent.com/mcp",
      "headers": {
        "Authorization": "Bearer ba_live_YOUR_KEY_HERE"
      }
    }
  }
}

Reinicie o Claude Desktop após salvar.

✳️

Cursor

Abra Configurações → MCP Servers → Adicionar Servidor, ou edite o .cursor/mcp.json na raiz do seu projeto:

{
  "mcpServers": {
    "bugagent": {
      "type": "http",
      "url": "https://mcp.bugagent.com/mcp",
      "headers": {
        "Authorization": "Bearer ba_live_YOUR_KEY_HERE"
      }
    }
  }
}

🌊

Windsurf

Abra Configurações → MCP → Adicionar Servidor, ou edite seu arquivo de configuração MCP:

{
  "mcpServers": {
    "bugagent": {
      "type": "http",
      "url": "https://mcp.bugagent.com/mcp",
      "headers": {
        "Authorization": "Bearer ba_live_YOUR_KEY_HERE"
      }
    }
  }
}

Adicione o bug Agent diretamente do terminal:

claude mcp add --transport http bugagent https://mcp.bugagent.com/mcp --header "Authorization: Bearer ba_live_YOUR_KEY_HERE"

Isso conecta diretamente ao servidor Streamable HTTP hospedado.

Para clientes que exigem stdio, use a ponte publicada bugagent-mcp:

Comando: npx
Linha de comando: npx -y bugagent-mcp
Argumentos: ["-y", "bugagent-mcp"]
Ambiente: BUGAGENT_API_KEY

Obter Ajuda

Precisa de assistência? Estamos aqui para ajudar.

Comunidade Discord

Junte-se ao nosso Discord para suporte em tempo real e discussões com a comunidade.

Suporte por E-mail

support@bugagent.com — Normalmente respondemos em até 24 horas.