qarunbook

npx add-mcp 'https://qarunbook.com/api/mcp'

A maior parte da ajuda de codificação com IA para no diff. A parte que decide se um release é seguro — o que os testadores realmente encontraram, em qual plataforma, e se a correção se manteve — vive em algum lugar que seu assistente não consegue ver. Um servidor MCP fecha essa lacuna.

Model Context Protocol é o padrão para entregar a um assistente um conjunto de ferramentas que ele pode chamar. Um servidor MCP de QA expõe o próprio runbook: os checks, os resultados por plataforma e os problemas levantados pelos testadores. Seu assistente lê tudo isso da mesma forma que uma pessoa lê o quadro, e escreve de volta no mesmo lugar.

qarunbook entrega um em https://qarunbook.com/api/mcp. Ele fala HTTP streamable, é gratuito, e o handshake e a lista de ferramentas respondem sem token, para que diretórios e clientes possam ver o que ele oferece antes de qualquer login.

O ciclo que ele fecha

Testes geralmente quebram na entrega. Um testador escreve “página de pagamento retorna 404 após abandonar o checkout” em uma planilha, alguém corrige, e ninguém sabe se a correção foi verificada na plataforma em que o bug ocorreu. O runbook torna isso mecânico:

1. Um testador registra uma falha em um check, em uma plataforma, com um screenshot.
2. Seu assistente chama list_issues, lê o que foi escrito e corrige o código.
3. Ele chama resolve_issue.
4. O check subjacente volta para needs retest — não para passing. O status é derivado, não armazenado, então nada pode marcar o próprio dever de casa.

Esse último passo é todo o design. Uma correção é uma afirmação até que um humano a confirme na plataforma em que o bug foi reportado.

As ferramentas

Quatorze, divididas pelo que elas tocam. Cada uma carrega um título e uma dica honesta sobre se altera dados.

Leitura

• list_apps — os apps no runbook e seus códigos de plataforma
• progress — contagens de passing, failing, untested e not-applicable
• list_issues — o que os testadores levantaram, do mais recente para o mais antigo
• list_checks — filtrar por failing, untested ou awaiting retest
• get_check — um check completo, com seus problemas

Adição

• create_app, import_plan — iniciar um app, ou colar um plano de teste markdown inteiro
• add_section, add_check — estender o plano
• add_issue — registrar o que você encontrou

Alteração

• set_result — registrar um pass ou fail em uma plataforma
• resolve_issue — marcar um problema como corrigido
• edit_issue, update_check — corrigir redação, ou marcar um check como not applicable em uma plataforma para que ele pare de contar contra a cobertura

Conectando

Faça login, abra Connect your AI e copie seu token. Depois, uma destas opções. O token é por pessoa, então cada resultado carrega um nome.

claude mcp add qa-runbook --transport http https://qarunbook.com/api/mcp \
  --header "Authorization: Bearer qarb_your_token_here"

No Claude Desktop: Settings → Connectors → Add custom connector, com a URL acima e um cabeçalho Authorization: Bearer.

// ~/.cursor/mcp.json
{
  "mcpServers": {
    "qa-runbook": {
      "url": "https://qarunbook.com/api/mcp",
      "headers": { "Authorization": "Bearer qarb_your_token_here" }
    }
  }
}

# ~/.codex/config.toml
[mcp_servers.qa-runbook]
url = "https://qarunbook.com/api/mcp"
http_headers = { Authorization = "Bearer qarb_your_token_here" }

O que perguntar a ele

Uma vez conectado, os prompts úteis são entediantes, e é exatamente esse o ponto:

• “O que está falhando no iOS para Smart Invites?”
• “Leia os problemas abertos, corrija os dois que estão neste repositório e marque-os como corrigidos.”
• “Onde está o teste antes de lançarmos?”
• “Importe este plano de teste e me diga o que ele não cobre.”

Quando você não precisa disso

Se uma pessoa escreve o código e faz o teste, um checklist em um arquivo é suficiente. Isso ganha seu lugar quando os resultados vêm de mais de uma pessoa, em mais de uma plataforma, e alguém precisa decidir se um release é seguro. Também não substitui testes automatizados — ele cobre a passagem manual que roda ao lado deles, que é onde as decisões de release realmente são tomadas.