qarunbook

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

La mayoría de la ayuda de codificación con IA se detiene en el diff. La parte que decide si un lanzamiento es seguro — lo que los testers realmente encontraron, en qué plataforma, y si la corrección se mantuvo — vive en algún lugar que tu asistente no puede ver. Un servidor MCP cierra esa brecha.

Model Context Protocol es la forma estándar de entregar a un asistente un conjunto de herramientas que puede invocar. Un servidor MCP de QA expone el runbook en sí: los checks, los resultados por plataforma, y los problemas que los testers plantearon. Tu asistente los lee de la misma manera que una persona lee el tablero, y escribe de vuelta en el mismo lugar.

qarunbook incluye uno en https://qarunbook.com/api/mcp. Habla HTTP transmisible, es gratuito, y el handshake y la lista de herramientas responden sin token, para que directorios y clientes puedan ver lo que ofrece antes de que alguien inicie sesión.

El ciclo que cierra

Las pruebas suelen fallar en la entrega. Un tester escribe "la página de pago da 404 después de abandonar el checkout" en una hoja de cálculo, alguien lo corrige, y nadie sabe si la corrección se verificó en la plataforma donde falló. El runbook hace que eso sea mecánico:

1. Un tester registra un fallo en un check, en una plataforma, con una captura de pantalla.
2. Tu asistente llama a list_issues, lee lo que escribieron, y corrige el código.
3. Llama a resolve_issue.
4. El check subyacente vuelve a necesita retest — no a aprobado. El estado se deriva, no se almacena, así que nada puede marcar su propia tarea.

Ese último paso es todo el diseño. Una corrección es una afirmación hasta que un humano la confirma en la plataforma donde se reportó el error.

Las herramientas

Catorce, divididas por lo que tocan. Cada una lleva un título y una pista honesta sobre si cambia datos.

Leer

• list_apps — las apps en el runbook y sus códigos de plataforma
• progress — conteos de aprobados, fallidos, sin probar y no aplicables
• list_issues — lo que los testers plantearon, más reciente primero
• list_checks — filtrar a fallidos, sin probar, o en espera de retest
• get_check — un check completo, con sus problemas

Añadir

• create_app, import_plan — iniciar una app, o pegar un plan de pruebas markdown completo
• add_section, add_check — extender el plan
• add_issue — plantear lo que encontraste

Cambiar

• set_result — registrar un aprobado o fallido en una plataforma
• resolve_issue — marcar un problema como corregido
• edit_issue, update_check — corregir redacción, o marcar un check como no aplicable en una plataforma para que deje de contar contra la cobertura

Conectarlo

Inicia sesión, abre Conecta tu IA, y copia tu token. Luego uno de estos. El token es por persona, así que cada resultado lleva un nombre.

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

En Claude Desktop: Configuración → Conectores → Añadir conector personalizado, con la URL anterior y un encabezado 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" }

Qué preguntarle

Una vez conectado, los prompts útiles son aburridos, que es el punto:

• "¿Qué está fallando en iOS para Smart Invites?"
• "Lee los problemas abiertos, corrige los dos que están en este repositorio, y márcalos como corregidos."
• "¿Hasta dónde está el testing antes de que lancemos?"
• "Importa este plan de pruebas y dime qué no cubre."

Cuando no necesitas esto

Si una persona escribe el código y hace las pruebas, una lista de verificación en un archivo es suficiente. Esto gana su lugar cuando los resultados vienen de más de una persona, en más de una plataforma, y alguien tiene que decidir si un lanzamiento es seguro. Tampoco reemplaza las pruebas automatizadas — cubre la pasada manual que corre junto a ellas, que es donde realmente se toman las decisiones de lanzamiento.