bugAgent

Conecta bug Agent con cualquier cliente de IA compatible con MCP.

Registra, clasifica y gestiona errores, solicitudes de funciones y mucho más directamente desde tu asistente de programación con IA. Sin cambiar de contexto ni copiar y pegar: solo describe el problema y bug Agent se encarga del resto.

Los clientes MCP externos son independientes del Asistente de IA del panel de bug Agent. El asistente del panel está desactivado de forma predeterminada en todos los planes y requiere habilitación explícita en el espacio de trabajo; su ai_assistant no desactiva MCP ni las integraciones. Siguen aplicándose la autenticación MCP, los ámbitos, los permisos del espacio de trabajo y del proyecto, y las autorizaciones específicas de cada herramienta.

Primeros pasos

bug Agent ejecuta el servidor MCP alojado para que los clientes de IA puedan crear, consultar y gestionar informes de errores, solicitudes de funciones, mejoras y mucho más mediante Model Context Protocol. Los clientes se conectan directamente al endpoint alojado de Streamable HTTP.

Obtén tu clave de API

Create a Free account; a los nuevos propietarios de espacios de trabajo se les lleva directamente a la configuración de la clave de API. Los usuarios que regresan pueden generar una clave desde Settings → Developers → API Keys.

Configura tu cliente de IA

Añade bug Agent como servidor MCP en la configuración de tu cliente (consulta las instrucciones de configuración más abajo).

Empieza a registrar errores

Describe un error en lenguaje natural y bug Agent lo clasifica, enriquece y almacena automáticamente.

# 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

Configuración

Plugin especializado para capturar errores

Consulta el código fuente público del plugin y la lista de verificación de configuración. Esta es una vista previa del código fuente; la verificación de OAuth alojado y la publicación en el directorio de OpenAI están pendientes.

El endpoint especializado https://mcp.bugagent.com/mcp/capture solo ofrece capture_get_profile, capture_list_projects, capture_search_reports, capture_get_report y capture_create_report. No expone funciones de administración, eliminación, comentarios ni ejecución de pruebas. La disponibilidad en el directorio de OpenAI está sujeta a una revisión y publicación independientes.

Conéctate mediante OAuth. Los permisos de captura están vinculados a este endpoint y no se pueden usar en el endpoint completo /mcp. Las lecturas requieren bugs:read; la creación requiere bugs:write. Las claves de API del espacio de trabajo siguen siendo compatibles con reports:read y reports:write, y están restringidas a su espacio de trabajo.

Selecciona primero un espacio de trabajo y un proyecto autorizados. Las búsquedas y lecturas de informes requieren workspace_id y project_id explícitos; los resultados están limitados y paginados. Los resultados de búsqueda son posibles coincidencias, no una garantía de que no existan duplicados.

Antes de crear un informe, revisa el destino, el título, la descripción, el tipo y la gravedad. Envía approved: true y un UUID estable request_id junto con esa carga útil aprobada. Reutiliza el mismo ID de solicitud solo para reintentar una solicitud idéntica; se rechazará una carga útil modificada. Siguen aplicándose los límites del plan vigente y el reenvío a Jira configurado.

La interpretación de imágenes puede ayudar a redactar un borrador, pero este endpoint no carga archivos adjuntos. Abre el ticket creado para adjuntar pruebas privadas. Nunca pegues contraseñas, tokens ni otros secretos en la conversación.

Recomendado: Streamable HTTP alojado

Conéctate directamente a https://mcp.bugagent.com/mcp. No hay nada que instalar ni que mantener en ejecución localmente. Añade la clave de API de tu espacio de trabajo como token bearer:

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

💡

Sustituye ba_live_YOUR_KEY_HERE por tu clave de API real de Settings → Developers.

Puente stdio opcional

Usa el puente publicado solo cuando un cliente requiera stdio y no pueda conectarse a un servidor HTTP remoto. Ejecútalo cuando lo necesites con npx -y bugagent-mcp:

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

Conectarse al servidor

En el panel, en dispositivos táctiles, toca una vez la etiqueta de la barra lateral para navegar. Las opciones y Restaurar son controles independientes, a los que también se puede acceder con el teclado. La visibilidad de la barra lateral no concede ni revoca permisos de MCP.

El servidor MCP de bug Agent está disponible en https://mcp.bugagent.com/mcp mediante el transporte Streamable HTTP. Conéctate desde cualquiera de los ocho clientes siguientes: elige el que mejor se adapte a tu flujo de trabajo.

Para obtener una configuración breve lista para copiar, recomendaciones sobre claves con ámbitos y sugerencias iniciales seguras, consulta la guía rápida pública de MCP.

🔑

Obtén primero tu clave de API. Inicia sesión en Settings → Developers, haz clic en Create API Key, selecciona los ámbitos que necesita tu cliente y copia el valor (empieza por ba_live_). Solo podrás verlo una vez, así que guárdalo en un lugar seguro. Los clientes MCP solo muestran las herramientas permitidas por esos ámbitos. Los ejemplos de conexión siguientes usan esta clave; las sugerencias que requieren una sesión u OAuth interactivos, o una autorización de plan de pago, se indican por separado.

Opción 1 — MCP Inspector (interfaz web, recomendado para las primeras pruebas)

La herramienta oficial de Anthropic. Inicia una interfaz web local donde puedes probar cada herramienta, rellenar parámetros y ver las respuestas. Sin configuración y sin necesidad de un IDE.

macOS (Terminal)

npx @modelcontextprotocol/inspector

Windows (PowerShell o CMD)

npx @modelcontextprotocol/inspector

En la interfaz del navegador que se abre:

1. Transport Type: selecciona Streamable HTTP
2. URL: https://mcp.bugagent.com/mcp
3. Connection Type: selecciona Proxy (la opción predeterminada; Inspector usa un proceso local de Node como proxy para evitar CORS del navegador)
4. Abre Server Settings → Custom Headers y añade:
   • Header Name: X-Api-Key
     • Value: ba_live_YOUR_KEY_HERE (sin el prefijo Bearer)
5. Haz clic en Connect. El panel izquierdo muestra las herramientas de bug Agent permitidas por los ámbitos de la clave de API que seleccionaste.
6. Haz clic en cualquier herramienta (por ejemplo, list_bug_reports), rellena los parámetros y haz clic en Run Tool. La respuesta aparece a la derecha.

Requisitos previos: MCP Inspector v2 requiere Node.js 22.19 o posterior. Instala una versión actual de Node.js desde nodejs.org si aún no lo tienes.

Si Inspector devuelve invalid_client, está intentando usar una conexión OAuth guardada en lugar de la autenticación con clave de API. Elimina el servidor guardado (o borra su estado OAuth almacenado), vuelve a añadirlo y usa el encabezado personalizado X-Api-Key indicado arriba. No introduzcas una clave ba_live_ en un campo OAuth client_id.

Opción 2 — Claude Desktop (Mac + Windows)

Si usas la aplicación Claude Desktop, puedes añadir bug Agent como servidor MCP permanente. Con una clave de API del espacio de trabajo, Claude recibe solo las herramientas permitidas por los ámbitos de esa clave. OAuth delegado expone el catálogo interactivo completo.

macOS

1. Abre Claude Desktop → barra de menús Claude → Settings → Developer → Edit Config. Se abrirá ~/Library/Application Support/Claude/claude_desktop_config.json.
2. Añade la entrada de bug Agent en mcpServers:

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

3. Guarda el archivo y cierra por completo Claude Desktop (Cmd+Q, no basta con cerrar la ventana).
4. Vuelve a abrir Claude Desktop. El icono de martillo de herramientas, en la parte inferior del campo de chat, debería mostrar ahora las herramientas de bug Agent.
5. Pruébalo: escribe “Lista mis 5 informes de errores más recientes”; Claude llamará automáticamente a list_bug_reports.

Windows

1. Abre Claude Desktop → File → Settings → Developer → Edit Config. Se abrirá %APPDATA%\Claude\claude_desktop_config.json (normalmente C:\Users\YourName\AppData\Roaming\Claude\claude_desktop_config.json).
2. Añade el mismo bloque JSON que se muestra en la sección de macOS.
3. Guarda el archivo y cierra por completo Claude Desktop desde la bandeja del sistema (haz clic con el botón derecho en el icono de Claude → Quit); luego vuelve a abrirlo.
4. El icono de martillo de herramientas mostrará las herramientas de bug Agent.

Opción 3 — Claude Code (CLI)

Si usas Claude Code desde la terminal (la versión CLI de Claude), registra el servidor de bug Agent con un solo comando. Funciona igual en macOS, Linux y Windows.

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

Luego reinicia tu sesión de Claude Code. Comprueba que esté conectado:

claude mcp list

Deberías ver bugagent en la lista con un punto verde. Empieza con una sugerencia compatible con claves de API: “Lista mis 5 informes de errores abiertos más recientes”.

¿Está conectado, pero faltan algunas herramientas?

Comprueba el recuento de herramientas del servidor en /mcp, no solo las herramientas que ya se han cargado en la conversación. Claude Code puede descubrir herramientas bajo demanda mediante la búsqueda de herramientas. Pídele que busque en bugAgent list_test_cases, list_test_suites o get_test_run_plan. Consulta la documentación de búsqueda de herramientas de Claude Code.

El catálogo se filtra según los ámbitos de la clave de API. Para leer casos de prueba se necesita test_cases:read; para leer suites y ejecuciones se necesita test_runs:read. Solicita solo los ámbitos de escritura que realmente necesites. Compara el tools/list autenticado con el mismo endpoint y la misma clave que usa tu cliente; la detección anónima o el uso de otra clave no son comparaciones válidas. Comprueba si una configuración a nivel de proyecto está anulando la conexión a nivel de usuario y, después de cambiar las credenciales, vuelve a conectarte o reinicia.

Si el catálogo del servidor autenticado incluye una herramienta, pero el cliente sigue sin poder descubrirla, registra la versión del cliente, la versión del servidor, los nombres y recuentos de las herramientas y cualquier error de esquema, eliminando las credenciales y los datos de clientes. Una sesión iniciada con ENABLE_TOOL_SEARCH=false claude puede ayudar a distinguir entre la detección diferida y los problemas de carga, pero carga todas las definiciones de herramientas y consume más contexto; úsala solo como diagnóstico temporal. No amplíes los permisos ni dividas los endpoints solo para aumentar el recuento de herramientas.

Para eliminarlo más adelante:

claude mcp remove bugagent

Opción 4 — OpenAI Codex CLI

Si usas OpenAI Codex CLI, exporta tu clave de API y añade bug Agent a ~/.codex/config.toml.

Registro permanente (añadir a la configuración)

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

Configurar la clave de API

export BUGAGENT_API_KEY="ba_live_YOUR_KEY_HERE"

Inicia o reinicia Codex desde ese entorno. Codex resuelve automáticamente las llamadas a herramientas a partir de tus instrucciones en lenguaje natural. Prueba: “Lista mis errores abiertos ordenados por gravedad”.

Opción 5 — Cursor (Mac + Windows)

Cursor incluye compatibilidad integrada con MCP. Con una clave de API del espacio de trabajo con los ámbitos adecuados, el asistente de IA de Cursor puede registrar errores, enumerar informes y ejecutar flujos de trabajo de automatización compatibles sin salir del editor. Los análisis de seguridad, rendimiento y exploración requieren OAuth delegado y el acceso al plan correspondiente.

1. Abre Cursor → Settings (Cmd+, en Mac / Ctrl+, en Windows) → MCP en la barra lateral izquierda.
2. Haz clic en + Add new MCP server.
3. Selecciona el tipo de transporte HTTP.
4. Rellena:
   • Name: bugagent
     • URL: https://mcp.bugagent.com/mcp
     • Header name: Authorization
     • Header value: Bearer ba_live_YOUR_KEY_HERE
5. Haz clic en Save. Cursor mostrará un indicador verde cuando se conecte.
6. Abre el chat de Cursor (Cmd+L / Ctrl+L) y escribe “Crea un informe de error titulado ‘Inicio de sesión no funciona’ con gravedad alta”. Cursor invocará create_bug_report.

Alternativa: Cursor también lee ~/.cursor/mcp.json (Mac) o %USERPROFILE%\.cursor\mcp.json (Windows). Añade el mismo formato JSON que se muestra en la sección de Claude Desktop.

Opción 6 — VS Code con la extensión Continue (Mac + Windows)

Si prefieres VS Code, la extensión Continue admite servidores MCP de forma nativa.

1. Instala la extensión Continue desde el marketplace de VS Code.
2. Abre la configuración de Continue: Command Palette (Cmd+Shift+P / Ctrl+Shift+P) → Continue: Open config.json. El archivo está en:
   • macOS: ~/.continue/config.json
     • Windows: %USERPROFILE%\.continue\config.json
3. Añade una entrada mcpServers:

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

4. Guarda. Continue se recargará automáticamente y mostrará las herramientas de bug Agent en la barra lateral.
5. Abre el panel de chat de Continue y prueba: “Lista mis 5 informes de errores abiertos más recientes”.

Otras extensiones de VS Code compatibles con MCP: Cline, Roo Code y Windsurf (fork) siguen patrones de configuración JSON similares, con una clave mcpServers y transporte HTTP.

Opción 7 — Hosts compatibles con OAuth (Claude.ai web como ejemplo)

Algunos hosts MCP se autentican mediante OAuth 2.0 y solicitan por adelantado un client_id y un client_secret estáticos, en lugar de aceptar una clave de API bearer. Genera un par de credenciales de conector desde el panel de bug Agent y pégalo en el formulario de conexión del host. El par identifica al cliente MCP; tras dar el consentimiento, la ejecución de herramientas usa el usuario que inició sesión y su espacio de trabajo activo de bug Agent. El recorrido siguiente usa la aplicación web Claude.ai como ejemplo más habitual.

i

OAuth vinculado a un recurso. El identificador del recurso protegido es https://mcp.bugagent.com/mcp. Los hosts compatibles con los estándares lo descubren mediante /.well-known/oauth-protected-resource/mcp y lo envían como parámetro resource de RFC 8707. bug Agent emite tokens opacos vinculados a ese recurso, al cliente OAuth, al usuario que inició sesión y a los ámbitos concedidos; un token no se puede reutilizar en otro servicio ni canjear desde otro cliente.

1. En bug Agent: abre Settings → Developers → MCP Connectors. Haz clic en Generate connector, asígnale un nombre que describa el host (p. ej., “Claude.ai (work)”), pega el URI de redirección que requiera tu host MCP (para la aplicación web de Claude.ai es https://claude.ai/api/mcp/auth_callback — consulta la documentación de conectores de tu host para ver otros), y elige Confidential como método de autenticación. Copia client_id y client_secret, que se muestran una sola vez en la pantalla de confirmación.
2. En la configuración de conectores / OAuth de tu host MCP, pega:
   • URL del servidor: https://mcp.bugagent.com/mcp
     • Client ID + Client Secret: del paso 1
     • URL de autorización: https://mcp.bugagent.com/authorize
     • URL del token: https://mcp.bugagent.com/token
     • Recurso protegido / audiencia, cuando se solicite: https://mcp.bugagent.com/mcp En concreto, para Claude.ai: ve a claude.ai/customize/connectors y haz clic en Add MCP connector.
3. Guarda. El host te redirigirá a bug Agent para iniciar sesión (con Google o correo electrónico/contraseña, según el método que uses para el panel) y aprobar el consentimiento; después completará el intercambio OAuth.
4. Administra los conectores generados desde la misma página de Settings. Solo quien creó un conector de tenant puede revocarlo; los administradores del espacio de trabajo no obtienen acceso para revocar el registro de otro miembro. Una revocación confirmada elimina ese registro de la lista activa. Los registros independientes con el mismo nombre siguen siendo distintos: compara sus Client IDs. Si no se puede confirmar la revocación, la página muestra un error en lugar de un mensaje de éxito. La revocación bloquea la autenticación de nuevos conectores. Los tokens de acceso emitidos anteriormente pueden seguir siendo válidos hasta que caduquen.

Nota: Claude Code, Cursor, VS Code y MCP Inspector no necesitan este flujo: gestionan automáticamente el registro dinámico de clientes (RFC 7591) y se autentican mediante una clave de API, como se muestra arriba. El formulario MCP Connectors es solo para hosts que requieren credenciales OAuth estáticas.

Los valores de acceso y actualización de OAuth solo se muestran al host. Son opacos, se rotan al actualizarse y bug Agent los almacena únicamente como hashes unidireccionales; la credencial de actualización de identidad del proveedor se cifra en reposo. Nunca copies un token OAuth en una solicitud a la API REST ni en otro servidor MCP.

Opción 8 — HTTP directo con curl (Terminal)

Si quieres probar el servidor directamente sin ningún cliente o integrarlo en un script, puedes acceder al endpoint HTTP con curl. El protocolo MCP es 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

Las respuestas pueden ser JSON o Server-Sent Events. Cada fragmento SSE es una línea precedida por data: y seguida de un objeto JSON. Los clientes que cumplen con los estándares deben enviar Accept: application/json, text/event-stream; actualmente, bug Agent normaliza los valores Accept ausentes o incompletos por compatibilidad.

ℹ️

Solución de problemas: 401 Unauthorized: Comprueba que no se haya revocado tu clave de API en Settings → Developers. Las claves empiezan por ba_live_. Si el problema persiste, vuelve a generar la clave e inténtalo de nuevo.

Modelo de acceso y ámbitos de mínimo privilegio

El catálogo OAuth completo contiene 141 herramientas. Una clave de API del espacio de trabajo solo ve las herramientas asignadas a uno de sus ámbitos seleccionados. La detección sin autenticación puede mostrar metadatos de herramientas, pero tools/call siempre requiere una clave de API o un token OAuth.

Leer informes de errores y resolver proyectos reports:read

Crear y actualizar informes de errores reports:read, reports:write

Monitor de uso usage:read

Comprobar el estado de sincronización con Jira jira:read

Sincronizar o combinar informes de Jira jira:write

Crear automatizaciones web automations:write

Ejecutar automatizaciones web y leer ejecuciones automations:run

Observar recursos y ejecuciones móviles mobile:read

Administrar recursos móviles mobile:read, mobile:write

Ejecutar automatización móvil mobile:read, mobile:run

Administrar el catálogo de pruebas reports:read, test_cases:read, test_cases:write

Trabajador externo de ejecución de pruebas test_runs:read, test_runs:write

Las claves de API están vinculadas al espacio de trabajo en el que se crean. Las entradas de las herramientas pueden limitar una llamada a un proyecto autorizado, pero no pueden cambiar la clave a otro espacio de trabajo. Resuelve los UUID de proyecto con list_projects y rechaza los nombres ambiguos.

Títulos y anotaciones de herramientas

Todas las herramientas devueltas por tools/list incluyen un título legible y sugerencias de lectura/escritura. Las sugerencias de lectura que faltan proceden de una lista revisada explícitamente, no de prefijos de nombres de herramientas ni de ámbitos de claves de API. Se conservan las anotaciones explícitas, incluida false.

• readOnlyHint: true describe una herramienta que no modifica su entorno.
• readOnlyHint: false con destructiveHint: false describe escrituras aditivas, no una operación de solo lectura.
• readOnlyHint: false con destructiveHint: true describe escrituras potencialmente destructivas. Las herramientas sin clasificar usan estos valores predeterminados conservadores. La sugerencia de acción destructiva solo tiene sentido para las escrituras.

login no es de solo lectura: en modo stdio guarda credenciales. analyze_fix_area y check_config_drift son escrituras potencialmente destructivas porque reemplazan resultados de análisis persistidos o líneas base de configuración.

Las anotaciones no conceden acceso ni sustituyen la autenticación, la autorización de espacio de trabajo/proyecto, los ámbitos de claves de API ni las comprobaciones de derechos. Las solicitudes de confirmación dependen de la política de permisos del cliente y de la configuración del usuario; las sugerencias no garantizan que una llamada solicite confirmación.

Para la detección y auditoría programáticas, descarga el mcp-tool-index.json generado. Registra las 141 herramientas en tiempo de ejecución, el acceso mediante ámbito de clave de API o solo OAuth, la familia de derechos, los nombres de entrada, el modo del esquema de salida y las anotaciones MCP declaradas explícitamente. Una anotación null significa que no está declarada en el punto de llamada; usa la respuesta tools/list del servidor conectado para obtener las anotaciones efectivas una vez aplicados los valores predeterminados.

!

Herramientas solo OAuth: la administración de cuentas, claves de API y equipos, la gestión de conexiones con Jira, otras integraciones, los controles de pruebas premium, las notas, el seguimiento del tiempo y otras operaciones interactivas no se habilitan al añadir ámbitos de claves de API. Las herramientas para comprobar, sincronizar y combinar informes de Jira son la excepción limitada mediante jira:read y jira:write.

Pruébalo — Indicaciones en lenguaje sencillo

Una vez conectado, no necesitas conocer los nombres de las herramientas ni sus parámetros. Describe lo que quieres en lenguaje sencillo y tu asistente de IA llamará automáticamente a la herramienta adecuada de bug Agent.

Las indicaciones sobre informes de errores, gestión de pruebas con ámbito, automatización de Playwright, automatización móvil y uso están disponibles para las claves de API con los ámbitos correspondientes. Las entradas de seguridad, rendimiento, exploración, cuentas, equipos, notas, seguimiento del tiempo y otras que no tienen un ámbito de clave de API con nombre requieren OAuth delegado y cualquier derecho de plan aplicable.

Informes de errores

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

Gestión de pruebas

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

Seguridad y rendimiento

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?

Automatización de 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 exploratoria

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 y estadí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?

Referencia rápida

Referencias de configuración para las ocho opciones de conexión. Los clientes con clave de API se conectan a https://mcp.bugagent.com/mcp con el encabezado Authorization: Bearer ba_live_YOUR_KEY_HERE mediante Streamable HTTP; los hosts compatibles con OAuth usan las credenciales de conector generadas en el panel.

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 Settings → MCP UI, o ~/.cursor/mcp.json

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

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

Host compatible con OAuth Settings → Developers → MCP Connectors — genera el client_id y el client_secret del host

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

Solución de problemas

401 Unauthorized La clave es incorrecta, ha caducado o se ha revocado. Comprueba Settings → Developers: las claves empiezan por ba_live_. Vuelve a generarla si es necesario.

Las herramientas no aparecen en el cliente. Los clientes con clave de API solo muestran las herramientas permitidas por los ámbitos seleccionados para la clave. Comprueba la clave en Settings → Developers y, después de cambiar su configuración, cierra por completo y vuelve a iniciar el cliente. En Claude Desktop, usa Cmd+Q (no basta con cerrar la ventana). En Cursor, comprueba que aparezca un punto verde en Settings → MCP.

Falta un campo en el cliente. Compara el esquema del cliente con el tools/list sin procesar del mismo endpoint. Si difieren, actualiza o vuelve a conectar el catálogo de herramientas e inicia un chat nuevo. Si el problema persiste, recopila el endpoint, la versión del cliente y la respuesta tools/list sin procesar; una caché obsoleta es solo una de las posibles causas.

Accept header required Envía Accept: application/json, text/event-stream para usar Streamable HTTP conforme a los estándares. Actualmente, bug Agent normaliza los valores ausentes o incompletos, pero las integraciones no deben depender de ese comportamiento de compatibilidad.

Datos del espacio de trabajo equivocado. Cada clave de API está limitada a un espacio de trabajo. Genera una clave nueva desde el espacio de trabajo que quieras consultar en Settings → Developers.

Las herramientas aparecen, pero las llamadas fallan sin aviso. Inspecciona la respuesta para encontrar isError: true y el contenido devuelto. Una herramienta visible puede seguir denegada por el plan, el rol, los derechos de funciones, la pertenencia al proyecto, la propiedad o una entrada no válida. Comprueba el estado del servidor solo después de leer el error de la herramienta.

Error de CORS en MCP Inspector. Selecciona Proxy (no Direct) como tipo de conexión en la interfaz de Inspector. Inspector usa un proceso local de Node como proxy para eludir las restricciones CORS del navegador.

MCP Inspector v2 sale con el código 5. Inspector v2 devuelve un código de salida distinto de cero cuando una respuesta de herramienta contiene isError: true. Lee el mensaje de respuesta para identificar un error de plan, permisos, entrada o ejecución; Inspector v1 podía devolver el código de salida 0 para la misma respuesta fallida de herramienta.

Codex CLI — no se reconocen las herramientas. Comprueba que ~/.codex/config.toml use [mcp_servers.bugagent], configura bearer_token_env_var = "BUGAGENT_API_KEY" y exporta esa variable antes de iniciar Codex. Comprueba codex --version si las herramientas siguen sin aparecer.

Funciones de MCP

Las sesiones conversacionales siguen siendo un programa piloto sujeto a las restricciones del espacio de trabajo. Para guardar un script generado en una sesión, se requiere la aprobación explícita de su propietario en Workbench mediante el endpoint para guardar scripts solo de sesión. No hay ninguna herramienta de aprobación MCP: pedirle a un agente que redacte un script no crea ni programa una automatización.

Guardar una captura de pantalla del navegador en la nube solo crea un borrador de hallazgo mediante el endpoint de retención de sesión del propietario. La actualización en vivo no sustituye la captura seleccionada; para guardarla se requiere que el propietario tenga acceso vigente, que se use la generación de navegador autorizada original y que haya una fuente disponible. El propietario debe revisarla y aprobarla en Workbench antes de que se registre un error con sus pruebas privadas. No hay ninguna herramienta MCP para conservar fotogramas ni eludir esa aprobación.

El consentimiento para iniciar el navegador también está reservado al propietario del panel. Las claves de API, las herramientas MCP y las respuestas genéricas del chat no pueden concederlo. La aprobación cubre un navegador de solo lectura y la captura privada de pantallas, no el inicio de sesión, las acciones en formularios ni la grabación de reuniones. El host de navegador en la nube de producción no se activa mediante estos controles de consentimiento.

El catálogo interactivo/OAuth completo contiene 141 herramientas. Las claves de API del espacio de trabajo solo detectan el subconjunto de mínimo privilegio permitido por los ámbitos seleccionados; las herramientas de cuentas, administración de claves de API, administración de equipos, pruebas premium, notas y seguimiento del tiempo son solo para sesiones interactivas, salvo que una entrada indique explícitamente un ámbito de clave de API.

🐛

Gestión de informes de errores

Las actualizaciones de informes registran atómicamente los valores reales anteriores y posteriores, incluidos los campos de reproducción, las notas internas y las etiquetas. Los valores sin cambios y las escrituras fallidas no crean entradas en el historial de campos. El registro de cambios del panel expande las diferencias de solo texto y permite recorrer las entradas anteriores. El historial de archivos adjuntos conserva metadatos descriptivos, no URL firmadas ni archivos eliminados. Los valores históricos que faltan no se completan retroactivamente. No se añade ninguna herramienta MCP de historial ni ningún protocolo de conflictos de edición en vivo; los clientes autorizados pueden usar el endpoint REST del historial de informes. update_bug_report también acepta los campos de cadena steps_to_reproduce, expected_result y actual_result. Los campos omitidos se conservan; una cadena vacía borra el texto. Las actualizaciones mantienen los requisitos de autorización existentes del espacio de trabajo/proyecto y del ámbito reports:write.

Las importaciones reanudables de capturas de pantalla de Google Sheets usan el endpoint REST independiente POST /api/reports/import-attachment con reports:write, y GET para consultar el estado con reports:read. No se añade ninguna herramienta MCP para importar capturas de pantalla. Esta API, que solo admite JPEG/PNG, verifica el almacenamiento privado y la incidencia de Jira asignada exacta antes de informar que se completó; la carga de informes heredada sigue siendo solo para sesiones.

Los enlaces privados a informes y archivos adjuntos de ejecuciones de pruebas vuelven a comprobar la pertenencia activa al espacio de trabajo y los permisos actuales del proyecto al abrirse. Las descargas de ejecuciones de pruebas requieren una sesión del panel, no una clave de API MCP. Los enlaces de almacenamiento emitidos anteriormente pueden seguir siendo válidos hasta 60 segundos y no deben compartirse.

• create_bug_report — Presentar un informe nuevo con clasificación automática entre 19 tipos — errores, solicitudes de funciones, mejoras, deuda técnica y más (título: 3-500 caracteres). La matriz opcional attachments acepta archivos codificados en base64 de hasta 400 MB cada uno: cualquier imagen, vídeo, audio, PDF o texto/JSON. Establece format_description: true para reformatear automáticamente la descripción con IA en una plantilla estructurada. Pasa time_spent_seconds para registrar el esfuerzo de QA. Pasa priority (urgent / high / normal / low) para establecer la urgencia de la corrección independientemente de la gravedad. Pasa is_epic: true para crear una épica, o parent_epic_id (UUID/ID corto) para crear un elemento secundario en el mismo proyecto autorizado. La respuesta incluye campos de jerarquía, además de project_id, project, short_id, legacy_short_id y project_short_id.
• list_bug_reports — Enumerar y filtrar informes (máximo 100 por página). Los filtros de proyecto se aplican en el servidor antes de la paginación. Filtra por project (UUID, slug, nombre exacto o prefijo de ticket), project_id, project_slug, project_prefix, workspace (UUID, nombre exacto o prefijo de ticket del espacio de trabajo), workspace_id / team_id, is_epic, type, severity, status, resolution, root_cause o reporter_user_id. El filtro search busca en el texto de los informes; una entrada compuesta solo por dígitos, como 366, realiza una búsqueda exacta tanto en los números de ticket heredados como en los del proyecto, por lo que se excluye el texto no relacionado que contenga esos dígitos. Cada resultado incluye identificadores de personas/proyectos con ámbito de tenant, además de is_epic, parent_epic_id, parent_epic y epic_progress con límites. Las herramientas de lectura de informes no exponen las direcciones de correo electrónico de los miembros.
• pick_next_bug — Devuelve los siguientes errores en los que debe trabajar el bucle del agente, en orden de prioridad (S1 → S2 → S3, primero los más antiguos dentro de cada grupo). Se limita automáticamente a tu espacio de trabajo: devuelve tickets de todos los proyectos de tu equipo con status new, awaiting-triage o confirmed y gravedad S1-S3. Solo lectura — no reclama tickets de forma atómica. Opcional: severity (un solo nivel), limit (1-50, valor predeterminado 1). Devuelve un objeto con count y bugs; cada error es una fila reducida de la cola, no la estructura completa de list_bug_reports. Combínalo con claim_bug para el patrón de lectura y posterior reclamación.
• claim_bug — Cambia atómicamente un error de status new, awaiting-triage o confirmed a status='in-progress', establece assigned_to como el usuario que realiza la llamada y registra claimed_at=NOW(). Evita condiciones de carrera entre llamadas simultáneas mediante el patrón UPDATE-WHERE-RETURNING de Postgres: si dos agentes llaman a claim_bug para el mismo ID con poca diferencia de tiempo, exactamente uno recibe claimed:true con el cuerpo del error y el otro recibe claimed:false con una cadena que explica el motivo. Las respuestas satisfactorias incluyen reporter_user_id, reporter_name, assigned_to y assignee_name. Un proceso de limpieza pg_cron libera automáticamente las reclamaciones obsoletas (status= in-progress + claimed_at con más de 30 minutos) y las devuelve a new, de modo que los tickets de un agente que se haya bloqueado vuelven a la cola sin intervención manual. Entradas: id (UUID o ID corto).
• get_bug_report — Obtener todos los detalles de un informe por UUID o ID corto del espacio de trabajo/proyecto. Devuelve los campos estándar de personas/proyecto/calidad, además de is_epic, la identidad del elemento principal, el progreso agregado y una primera página limitada de elementos secundarios para las épicas.
• Etiquetas nativas de informes: create_bug_report y update_bug_report aceptan tags como matriz de cadenas, por ejemplo {"tags":["login","regression"]}. Se aceptan como máximo 20 elementos sin procesar antes de eliminar duplicados. Las cadenas se recortan, deben tener contenido y no superar los 50 puntos de código Unicode; tampoco pueden contener controles ASCII (U+0000 a U+001F o U+007F). Los duplicados exactos se eliminan después de recortar; se conserva el uso de mayúsculas y Login es distinto de login. Al actualizar, la matriz reemplaza todas las etiquetas, [] las borra y omitirla las conserva. Al crear, omitirla significa que no hay etiquetas. Se rechazan null y los elementos no válidos. Los resultados de crear, obtener, enumerar y actualizar exponen tags nativas.
• Filtrado por etiquetas: llama a list_bug_reports con {"project":"bugagent","tags":["login","regression"]} para buscar TODAS las etiquetas solicitadas, distinguiendo mayúsculas y minúsculas, antes de la paginación. Se aplican los mismos límites de etiquetas; si se omite o se proporciona [], no se aplica ningún filtro de etiquetas. Los ámbitos existentes reports:read / reports:write y la autorización del espacio de trabajo/proyecto no cambian. Esto no añade una interfaz visual para etiquetas ni la importación, sincronización o carga retroactiva automática de etiquetas de Jira.
• get_epic — Leer directamente una épica con el campo obligatorio id (UUID o ID corto del espacio de trabajo/proyecto). Devuelve solo el registro de la épica, sin cargar implícitamente los informes secundarios. Requiere acceso a su espacio de trabajo y proyecto; quienes llaman con una clave de API necesitan reports:read. Usa list_epic_children por separado para leer los elementos secundarios.
• list_epic_children — Paginar los informes secundarios de una épica con id, limit (1–100) y offset. Devuelve children, total, has_more y epic_progress agregados mediante SQL, sin cargar todos los informes secundarios.
• update_bug_report — Actualizar los campos estándar del informe, además de is_epic y parent_epic_id. Pasa parent_epic_id: null para desvincular; cambiar el elemento principal o desvincular es una operación atómica y requiere autorización para el mismo espacio de trabajo y proyecto. Al convertir un informe en épica, se desvincula el elemento principal existente; una épica con elementos secundarios no se puede convertir en otro tipo. Se siguen aplicando las reglas existentes de estado/resolución/causa raíz y notificación de asignación. Un cambio de status en un informe vinculado a Jira se refleja en la incidencia de Jira mediante sus transiciones de flujo de trabajo cuando coincide exactamente una transición legal con el estado asignado; de lo contrario, la incidencia no se modifica.
• add_comment — Añadir un comentario a un informe de error (UUID o ID corto, cuerpo de 1-10000 caracteres). Si el informe está sincronizado con Jira, el comentario se envía automáticamente a la incidencia de Jira vinculada. El Markdown de archivos adjuntos privados, como ![proof](/api/attachments/ATTACHMENT_UUID), se convierte en un enlace inteligente absoluto y autenticado de bugAgent en Jira. Quienes lo vean deben iniciar sesión en bugAgent y tener acceso al espacio de trabajo y al proyecto del informe; no se garantizan las vistas previas integradas de Jira.
• list_comments — Enumerar el hilo de comentarios almacenado de un informe, del más antiguo al más reciente: cada comentario incluye el nombre del autor, parentId (respuestas en hilo), createdAt y updatedAt. Los comentarios no forman parte de get_bug_report, así que esta es la forma de leer el debate de un ticket. Acepta un UUID o ID corto. Esta lectura no actualiza Jira. Las integraciones programadas que necesiten comentarios recientes de Jira pueden llamar primero a POST /api/jira/comments-refresh con una clave de API autorizada y propiedad de un administrador. Usa los ID de comentarios y las revisiones de contenido para distinguir los comentarios nuevos de las ediciones, y no afirmes que el informe de actividad está completo si falla la actualización.
• link_bug_reports — Crear un enlace semántico direccional entre dos informes del mismo proyecto autorizado. Para parent-of, el informe de origen debe ser una épica y el de destino, un elemento secundario estándar. Al crear o actualizar, prefiere parent_epic_id para asignar una épica.
• unlink_bug_reports — Eliminar un enlace de informe de error creado anteriormente mediante su UUID (link_id, devuelto por link_bug_reports o list_bug_report_links).
• list_bug_report_links — Enumerar todos los enlaces seleccionados por usuarios que afectan a un informe de error. Devuelve cada enlace desde la perspectiva del informe proporcionado; por ejemplo, una fila almacenada duplicate-of en la que este informe es el destino se muestra como duplicated-by; parent-of en la que este informe es el destino se muestra como subtask-of; depends-on en la que este informe es el destino se muestra como blocks; testing-blocked-by en la que este informe es el destino se muestra como blocks-testing. related-to es simétrico. Complementa el campo similar_reports detectado automáticamente que devuelve get_bug_report.
• classify_bug — Clasificar una descripción en uno de 19 tipos de informe (errores, funciones, mejoras, etc.) con una puntuación de confianza
• flush_reports — Eliminar en bloque informes antiguos (solo administradores)

📊

Uso y análisis

• get_usage — Consultar el uso en relación con los límites del plan. Quienes llaman con una clave de API necesitan usage:read.
• get_stats — Recuentos diarios y desgloses por tipo/gravedad/estado

📁

Gestión de proyectos

• list_projects — Enumerar los proyectos accesibles con id, name, slug, ticket_prefix, la descripción y el estado predeterminado. Usa esos valores con las herramientas de informes de errores y del catálogo de pruebas para seleccionar el proyecto correcto.
• create_project — Crear un proyecto nuevo (se convierte automáticamente en el predeterminado si es el primero)
• delete_project — Eliminar permanentemente un proyecto y todos sus datos asociados (informes de errores, automatizaciones, casos de prueba, aplicaciones móviles, programaciones, capturas geográficas, notas y registros de tiempo). Solo el propietario o un administrador. No se puede eliminar el último proyecto. El almacenamiento se libera automáticamente.
• export_okf_bundle — Exportar los conocimientos de QA de un proyecto — informes de errores, casos de prueba, automatizaciones y pruebas de rendimiento, seguridad y exploratorias — como un paquete Markdown OKF/OQA (el formato Open Query Agent utilizado por oqa.ai). De forma predeterminada, se usa el proyecto activo; pasa el campo opcional project (slug o nombre) para exportar otro. Devuelve la lista de archivos del paquete y el paquete en sí como un archivo zip codificado en base64.

🔐

Autenticación y cuenta

• register_account — Crear una cuenta nueva (contraseña: 8-128 caracteres; límite de frecuencia: 5/15 min)
• login — Iniciar sesión y recibir tokens de acceso (límite de frecuencia: 5/15 min)
• update_profile — Actualizar el nombre para mostrar
• change_password — Cambiar la contraseña de la cuenta
• get_settings — Leer el perfil y las preferencias de notificación.
• update_settings — Actualizar las preferencias de perfil y notificación admitidas. Solo se puede modificar mediante OAuth.

🔑

Gestión de claves de API

• generate_api_key — Crear una clave de API con nombre
• list_api_keys — Enumerar las claves activas (solo el prefijo)
• regenerate_api_key — Revocar y reemplazar una clave
• delete_api_key — Revocar una clave permanentemente

👥

Gestión del equipo

• list_workspaces — Enumerar los espacios de trabajo a los que perteneces, tu rol en cada uno y cuál usa la sesión de forma predeterminada. Los hosts con varios espacios de trabajo pueden fijar una solicitud mediante el encabezado X-BugAgent-Workspace (solo para miembros activos).
• list_team_members — Enumerar todos los miembros de tu espacio de trabajo con sus roles, estados e indicadores de booster
• invite_team_member — Invitar a un usuario por correo electrónico (los administradores pueden invitar a colaboradores y administradores; solo los propietarios pueden invitar a administradores del sistema). Enlace válido durante 5 días

🎯

Integraciones

La sincronización de informes con Jira Cloud está incluida en los planes Free y Enterprise. Un administrador del espacio de trabajo debe conectar primero Jira desde el panel. Después, las claves de API del espacio de trabajo pueden usar jira:read para comparar y jira:write para sincronizar/combinar; siguen aplicándose los límites del plan y de la API de Atlassian.

• sync_to_jira — Envía un informe a Jira usando la conexión compartida del equipo. Lo dirige al proyecto de Jira asignado al proyecto bugAgent del informe (con el proyecto predeterminado del espacio de trabajo como alternativa), usando su mapa de campos: la versión 2 separa la prioridad y la gravedad personalizada, mientras que los mapas sin versión conservan la traducción heredada de gravedad a prioridad. El parámetro opcional projectKey solo puede seleccionar ese mapa configurado o el proyecto predeterminado del espacio de trabajo; se rechazan los proyectos de Jira arbitrarios. Normalmente no necesitas esto: cuando el modo de sincronización del proyecto es auto_new o auto_all, los informes que creas se envían automáticamente; úsalo para un envío manual en el modo manual.
• check_jira_sync — Comparación de solo lectura del título y del estado, la prioridad y la gravedad asignados de un informe vinculado autorizado. Usa el proyecto guardado del informe y la conexión de Jira. La versión 2 asigna Jira Priority por separado de un campo Severity personalizado compatible; los mapas sin versión conservan el comportamiento heredado de prioridad a gravedad. Esta herramienta no compara comentarios, archivos adjuntos, tipo ni todos los campos de Jira.
• merge_jira_sync — Combina esos campos asignados usando prefer: jira para obtener los valores de Jira o prefer: bugagent para enviar los valores locales. Los envíos de estado usan transiciones válidas del flujo de trabajo de Jira. Los conflictos salientes sin asignación, los errores de escritura remota y los cambios locales simultáneos devuelven errores en lugar de afirmar que todo está sincronizado. Los comentarios y los archivos adjuntos siguen siendo flujos de trabajo de sincronización independientes del panel. Las escrituras entre sistemas no son atómicas.
• push_to_claude — Genera (o vuelve a generar) las Notas para desarrolladores de un informe de error: causa raíz, solución sugerida, pasos de verificación y evaluación de riesgos. Acepta un UUID o un ID corto (WRKID-545). Usa claves de plataforma; no requiere una conexión Claude por equipo. Ejecuta una cadena adaptativa: tres pasos para errores s3 / medium o s4 / low (borrador de Sonnet → crítica de OpenAI gpt-5 → síntesis de Sonnet), cinco pasos para los dos niveles de gravedad más altos — s1 / critical o s2 / high — (borrador → crítica → réplica de Sonnet → árbitro Claude Opus que lee la transcripción completa y redacta las notas finales con criterio independiente). La respuesta expone cada ronda: analysis, draft, critique, rebuttal, challenger_model, adjudicator_model y un indicador debated. Si falla algún paso, se recurre a la siguiente mejor respuesta. Se ejecuta automáticamente al crear un error; normalmente solo se llama para regenerar manualmente.
• analyze_fix_area — Genera (o vuelve a generar) el subbloque «Área probable de la solución» de las Notas para desarrolladores: una respuesta concisa de Sonnet que indica en qué parte del código probablemente corresponda implementar la solución. Acepta un UUID o un ID corto. Usa la clave de Anthropic de la plataforma. Si el equipo tiene una fila github_connections y el proyecto tiene un github_repo asignado, la respuesta se basa en fragmentos reales de archivos del repositorio conectado; de lo contrario, ofrece orientación general e invita a conectar un repositorio. Devuelve texto likely_fix_area, generated_at, repo_used y un indicador grounded. Se ejecuta automáticamente al crear un error; normalmente los agentes solo necesitan llamarla para regenerar manualmente.
• upgrade_plan — Obtén el enlace de inscripción a Enterprise con asistencia de ventas

⚡

Pruebas de rendimiento

• create_performance_test — Crea una configuración de prueba de rendimiento con URL, dispositivo, usuarios virtuales, duración, umbral de puntuación y opción para crear errores automáticamente. El parámetro opcional project acepta un UUID de proyecto, slug, nombre exacto o prefijo de ticket del espacio de trabajo actual. Si se omite, usa el proyecto predeterminado del espacio de trabajo y, después, el proyecto más antiguo; quien realiza la llamada debe tener acceso. Usa list_projects para elegir un proyecto. Se rechaza un proyecto vacío, desconocido o inaccesible. name no puede estar vacío y se eliminan los espacios sobrantes. Los nombres de las pruebas de rendimiento deben ser únicos dentro del espacio de trabajo y del proyecto, sin distinguir mayúsculas de minúsculas ni espacios al principio o al final; si hay un conflicto, se te pedirá que elijas otro nombre. Solo Enterprise
• run_performance_test — Inicia una auditoría de página y una prueba de carga para una prueba de rendimiento web. Devuelve un ID de ejecución para consultar los resultados. Las ejecuciones de perfilado de aplicaciones móviles se inician desde el panel
• get_performance_results — Obtén los resultados completos, incluidas las puntuaciones de Lighthouse (rendimiento, accesibilidad, prácticas recomendadas, SEO), las métricas web esenciales (LCP, FID, CLS, FCP, TTFB, INP, TBT, SI) y las métricas de la prueba de carga (usuarios virtuales, solicitudes, RPS, latencias p50/p90/p95/p99)
• list_performance_tests — Muestra todas las configuraciones de pruebas de rendimiento del equipo actual
• get_performance_usage — Consulta el uso mensual de pruebas de rendimiento. Las pruebas de rendimiento solo están disponibles en Enterprise. Free=0, Enterprise=ilimitado

Flujo de trabajo de ejemplo

1. get_performance_usage → consulta la cuota restante
2. create_performance_test → configura una prueba para tu URL
3. run_performance_test → inicia la auditoría y la prueba de carga
4. get_performance_results → revisa las puntuaciones y las métricas esenciales

🛡

Análisis de seguridad

• create_security_scan — Crea una configuración de análisis de seguridad. Los análisis web usan Quick Scanner + Nuclei (más de 4.000 plantillas) con tres niveles de profundidad y análisis autenticado opcional. Los análisis móviles usan MobSF para analizar archivos binarios APK/IPA. Permite configurar la creación automática de errores con umbrales de gravedad. El parámetro opcional project acepta un UUID de proyecto, slug, nombre exacto o prefijo de ticket del espacio de trabajo actual. Si se omite, usa el proyecto predeterminado del espacio de trabajo y, después, el proyecto más antiguo; quien realiza la llamada debe tener acceso. Usa list_projects para elegir un proyecto. Se rechaza un proyecto vacío, desconocido o inaccesible. name no puede estar vacío y se eliminan los espacios sobrantes. Los nombres de los análisis de seguridad deben ser únicos dentro del espacio de trabajo y del proyecto, sin distinguir mayúsculas de minúsculas ni espacios al principio o al final, independientemente de los nombres de las pruebas de rendimiento; si hay un conflicto, se te pedirá que elijas otro nombre. Solo Enterprise
• run_security_scan — Inicia un análisis de vulnerabilidades. Los análisis web requieren verificar el dominio DNS. Los análisis móviles requieren una aplicación cargada. Devuelve un ID de ejecución para consultar los resultados
• get_security_results — Obtén los resultados completos, incluida la puntuación de seguridad (0-100), los hallazgos clasificados por gravedad (crítica, alta, media, baja, informativa) con referencias CWE, asignaciones OWASP, evidencias y recomendaciones de corrección
• list_security_scans — Muestra todas las configuraciones de análisis de seguridad del equipo actual, con la última puntuación e indicadores de autenticación/profundidad
• get_security_usage — Consulta el uso mensual de análisis de seguridad. El análisis de seguridad solo está disponible en Enterprise. Enterprise=ilimitado
• list_security_schedules — Muestra todos los análisis de seguridad programados del equipo, con cron, zona horaria, estado de activación, próxima ejecución y configuración de notificaciones. Se combina con la configuración de análisis principal (name, scan_type, target_url)
• create_security_schedule — Crea una programación recurrente para un análisis de seguridad. Requiere scan_id y cron_expression. Una programación por configuración de análisis. Opcionales: timezone, notify_on_fail (none/email/slack/both), notify_email, slack_channel_id. Cada ejecución cuenta para el límite mensual; los usuarios administradores no están sujetos al límite. La profundidad del análisis siempre se lee de la configuración de análisis al ejecutarlo
• delete_security_schedule — Elimina un análisis de seguridad programado. No afecta a la configuración de análisis principal ni a las ejecuciones completadas

Flujo de trabajo de ejemplo

1. get_security_usage → consulta la cuota restante
2. create_security_scan → configura un análisis para tu URL o repositorio
3. run_security_scan → inicia un análisis de vulnerabilidades puntual
4. create_security_schedule → automatiza las ejecuciones recurrentes (p. ej., SAST semanal en la rama principal)
5. get_security_results → revisa los hallazgos y las recomendaciones de corrección

📖

Revisión de código

• list_code_reviews — Muestra las revisiones de código recientes de IA del equipo. Devuelve puntuaciones de calidad, recuentos por gravedad, información de las solicitudes de incorporación de cambios y marcas de tiempo. Solo Enterprise
• get_code_review — Obtén una revisión de código con todos los hallazgos. Cada hallazgo incluye gravedad, categoría (error/seguridad/rendimiento/estilo/lógica/mantenibilidad), título, descripción, sugerencia de código, ruta del archivo y números de línea
• get_code_review_usage — Consulta el uso de revisiones de código. La revisión de código con IA solo está disponible en Enterprise; es ilimitada en Enterprise
• get_code_review_analytics — Obtén análisis de revisiones: tendencias, categorías/orígenes de hallazgos, desglose por gravedad, métricas de velocidad, repositorios/autores principales. Admite periodos retrospectivos de 7/30/90 días

Flujo de trabajo de ejemplo

1. get_code_review_usage → consulta las revisiones restantes
2. Revisa una solicitud de incorporación de cambios en el panel, en /dashboard/code-review
3. list_code_reviews → consulta las revisiones recientes
4. get_code_review → obtén los hallazgos y las sugerencias

🔍

IA exploratoria

Buscador autónomo de errores en sitios web con varios agentes, con hasta 10 agentes en paralelo, cada uno con una estrategia de prueba distinta.

• list_explorations — Muestra las configuraciones de IA exploratoria del equipo
• create_exploration — Crea una exploración nueva. Acepta agent_count (1–10, máximo 10) para ejecutar varios agentes en paralelo con estrategias únicas: happy_path, edge_case, security, accessibility, error_path, performance, mobile, data_integrity, navigation, custom. Esta herramienta no puede configurar credenciales ni el modo de autenticación. Configura e inicia explícitamente Probar solo el flujo de inicio de sesión desde el panel o REST; después, usa get_exploration y get_exploration_run para inspeccionar la configuración y los resultados. Nunca deduzcas el modo a partir de las instrucciones ni incluyas credenciales en los argumentos de MCP. La exploración predeterminada basada en credenciales sigue requiriendo una sesión reutilizable.
• get_exploration — Obtén la configuración de exploración con los ajustes de los agentes, metadatos de autenticación seguros y ejecuciones recientes. Nunca se devuelven contraseñas ni texto cifrado.
• get_exploration_run — Obtén los resultados de la ejecución con el progreso de cada agente, datos de las fases, hallazgos con atribución al agente (agent_index, agent_strategy) y errores vinculados
• get_exploration_usage — Consulta el uso mensual. La IA exploratoria solo está disponible en Enterprise; Enterprise: ilimitado (10 agentes)

Flujo de trabajo de ejemplo

1. create_exploration con agent_count: 5 → configura 5 agentes en paralelo
2. Inicia una ejecución desde el panel o mediante POST /api/explorations/run
3. get_exploration_run → consulta el progreso y los hallazgos de cada agente
4. Consulta en el panel los hallazgos deduplicados con atribución al agente

📝

Notas

• list_notes — Muestra notas con filtros opcionales de palabra clave, proyecto, visibilidad, carpeta, etiqueta, archivo, wiki, intervalo de fechas y orden. Devuelve las notas que pertenecen al usuario o que se han compartido con él.
• create_note — Crea una nota en uno de 5 formatos: markdown, plain, bugtemplate, checklist, outline. Establece visibility en private o shared. Si no se proporciona un título, se genera automáticamente a partir de los primeros 30 caracteres. El parámetro opcional attachments acepta una matriz de archivos codificados en base64 de hasta 400 MB cada uno: cualquier imagen, vídeo, audio, PDF o archivo de texto/JSON. Pasa time_spent_seconds para registrar el esfuerzo de QA.
• get_note — Obtén todos los detalles de una nota, incluido el contenido y los archivos adjuntos. Requiere id.
• update_note — Actualiza el título, el contenido, el formato, la visibilidad, el proyecto o time_spent_seconds. Pasa una matriz attachments para añadir archivos nuevos (máximo 400 MB cada uno) a los archivos adjuntos existentes de la nota, sin reemplazarlos. Solo el autor puede actualizarla. Requiere id.
• delete_note — Elimina permanentemente una nota y sus archivos adjuntos. Solo el autor puede eliminarla. Requiere id.
• list_note_folders — Muestra las carpetas de notas/wiki, con la opción de limitar los resultados a un proyecto.
• create_note_folder — Crea una carpeta de notas/wiki asociada a un proyecto, con opciones para configurar la carpeta principal, la visibilidad, los favoritos y el acceso de compañeros de equipo.

Flujo de trabajo de ejemplo

1. create_note → inicia una nota de sesión de pruebas
2. update_note → añade observaciones mientras haces las pruebas
3. list_notes → busca notas anteriores por palabra clave o proyecto
4. get_note → recupera la nota completa con los archivos adjuntos

🤖

Automatización

• create_automation — Crea una nueva automatización con un script personalizado de Playwright (no se requiere grabación con FAB). Requiere name. Opcional: target_url (se deriva automáticamente de la primera URL page.goto(...) del script si se omite), script (Node.js/JavaScript/TypeScript o Python; el lenguaje se detecta automáticamente y, de forma predeterminada, se usa un marcador de posición), status (draft o active; valor predeterminado: draft), project_id. Devuelve la automatización id. Consejo — Duplicar una automatización: usa get_automation para obtener el script original y luego llama a create_automation con name establecido en "[Copy] Original Name" y pasa el script, target_url y project_id originales. La copia comienza con el estado draft y sin historial de versiones.
• list_automations — Enumera los scripts de automatización de Playwright. Filtra por project_id o status (draft, active, paused). Devuelve una matriz de automatizaciones con name, target_url, last_run_status y run_count.
• get_automation — Obtiene todos los detalles de la automatización, incluidos el script de Playwright y las ejecuciones recientes. Requiere id. Devuelve la automatización con el script vigente, una pila de script_versions (de la más antigua a la más reciente, hasta 100 entradas anteriores, cada una { script, source, timestamp }) y una matriz recent_runs en la que cada ejecución incluye el script_version_label / script_version_source que se ejecutó. Llama a esta herramienta antes de run_automation si necesitas elegir una versión histórica específica.
• run_automation — Inicia una ejecución inmediata de una prueba de Playwright. Requiere automation_id. Selectores con autocorrección (automática): cuando se agota el tiempo de espera de una acción de localizador, el ejecutor pide a Claude un selector funcional y vuelve a intentar el paso una vez; las aserciones nunca se corrigen automáticamente, por lo que las regresiones reales siguen fallando; cada corrección se registra en la salida estándar de la ejecución. Modo de emulación (predeterminado): device opcional para un perfil de dispositivo emulado (p. ej., desktop, iphone-15). Modo real: establece browserstack: true con bs_browser (chrome, firefox, safari, edge), bs_os (Windows, OS X) y bs_os_version para ejecutar en un navegador de escritorio real. Móvil real: establece bs_os: "android" (dispositivos: "Samsung Galaxy S25 Ultra", "Google Pixel 10", "OnePlus 13R") o bs_os: "ios" (dispositivos: "iPhone 17 Pro Max", "iPhone 16 Pro Max", "iPhone 15 Pro Max") y pasa el nombre del dispositivo en bs_os_version. Ambos modos se ejecutan en segundo plano; «Real» describe el entorno de ejecución, no una sesión interactiva visible. Los scripts de Node.js se ejecutan mediante browserstack-node-sdk (compatible con escritorio, Android y iPhone). Los scripts de Python se ejecutan mediante browserstack-sdk (pytest-playwright) y solo son compatibles con escritorio; Python no admite dispositivos móviles reales porque browser_type.connect() de pytest-playwright no puede controlar los endpoints móviles reales de BrowserStack. El video y los registros de red se capturan automáticamente; los registros de consola, solo en escritorio. Reproducción de versiones: inspecciona script_versions con get_automation y luego pasa el version_label persistente que prefieras (por ejemplo, "v103"). Se sigue admitiendo el version_index heredado, pero no debe combinarse con version_label. Valor predeterminado: si se omiten ambos selectores, se ejecuta el script guardado actual. Las etiquetas eliminadas y los índices no válidos se rechazan en lugar de ejecutar silenciosamente la versión actual. El registro de ejecución almacena la instantánea exacta que se ejecutó, y cualquier informe de errores creado automáticamente a partir de una ejecución fallida incluye un enlace directo a esa versión en el editor.
• list_automation_runs — Enumera las ejecuciones recientes de una automatización. Requiere automation_id. Devuelve las ejecuciones con status, duration_ms y error_message.
• list_schedules — Enumera todas las ejecuciones programadas de automatización web con cron_expression anulable, run_at anulable, once_status, zona horaria, dispositivo y configuración de notificaciones. Las filas recurrentes conservan run_at y once_status como null; las filas de una sola ejecución tienen cron en null. Estados de una sola ejecución: pending, claimed, missed, dispatched, failed, uncertain. Estos son estados de despacho, no resultados de pruebas; consulta list_automation_runs para ver los resultados.
• Programaciones web recurrentes: create_schedule valida cinco campos cron numéricos y la zona horaria, y devuelve un next_run_at UTC futuro. Se admiten recurrencias mensuales y anuales. Por ejemplo, 30 12 23 9 * en America/Toronto significa el 23 de septiembre a las 12:30 todos los años, no una ejecución única. Los horarios no válidos o imposibles se rechazan antes de la creación. Si se restringen tanto el día del mes como el día de la semana, ambos deben coincidir. Se omiten las horas inexistentes por el horario de verano; las horas repetidas pueden ocurrir dos veces. El despacho se realiza en la siguiente consulta del programador, no necesariamente en el minuto exacto. El comportamiento recurrente existente no cambia.
• Programaciones web de una sola ejecución: llama a create_schedule con { "automation_id": "AUTOMATION_UUID", "run_at": "2030-12-15T09:30:00-05:00", "timezone": "America/Toronto" }, elige una fecha futura y omite cron_expression. Proporciona exactamente un campo de horario. run_at requiere una marca de tiempo ISO 8601 futura con desplazamiento horario (desplazamiento explícito o Z); la zona horaria IANA se usa para mostrarla. Una programación pendiente habilitada se ejecuta en la primera consulta cron posterior a la hora prevista; si lleva más de una hora de retraso, se marca como missed. Se reclama y deshabilita de forma atómica antes del despacho, y no se puede volver a habilitar una vez consumida. Los fallos definitivos de despacho son failed; los despachos ambiguos son uncertain y nunca se reintentan automáticamente. Comprueba las ejecuciones antes de programar otro intento. dispatched no significa que se haya completado ni aprobado. La creación solo está disponible mediante API/MCP; no es un nuevo modo de creación en el panel.
• Las zonas horarias de las programaciones web son identificadores IANA, como America/Argentina/Buenos_Aires. El selector del panel incluye todas las regiones y ciudades compatibles con el servidor y usa de forma predeterminada la zona horaria de tu perfil; la zona horaria predeterminada de MCP sigue siendo UTC.
• create_schedule — Crea una ejecución programada de automatización web. Requiere automation_id y exactamente uno de cron_expression o run_at. Admite configuración opcional de dispositivo, zona horaria, notificaciones de fallos, correo electrónico y canal de Slack. Conecta Slack primero desde el panel y elige un canal al que pertenezca el bot; instalar solo el webhook no es suficiente. Consulta Configuración de Slack y búsqueda de canales.
• Despliegue y recuperación de ejecuciones únicas: aplica la migración de base de datos 374_one_time_web_schedules.sql antes de desplegar el código correspondiente de API/MCP y del programador. claimed puede persistir tras un fallo del trabajador: consulta el historial de ejecuciones antes de crear un reemplazo para cualquier despacho reclamado o incierto. Nunca se ejecuta automáticamente una marca de tiempo que lleve más de una hora de retraso.
• Automatizaciones web en borrador: activa la automatización antes de crear una programación, volver a habilitarla o cambiar su expresión cron o zona horaria. create_schedule verifica el acceso al espacio de trabajo y al proyecto antes de rechazar el estado Draft. Las programaciones existentes omiten ciclos mientras la automatización está en estado Draft; siguen estando disponibles las acciones de pausar, eliminar, fijar y cambiar solo las notificaciones. No hay una herramienta MCP web update_schedule; usa el panel para esas actualizaciones.
• delete_schedule — Elimina una ejecución programada de automatización web
• list_mobile_schedules — Enumera todas las ejecuciones programadas de automatización móvil con dispositivos, cron, zona horaria y notificaciones
• create_mobile_schedule — Crea una ejecución programada de automatización móvil en dispositivos reales. Requiere automation_id y cron_expression; devices es opcional.
• delete_mobile_schedule — Elimina una ejecución programada de automatización móvil
• optimize_automation_script — Envía un script de Playwright a Sonnet 4 para optimizarlo con IA. Aplica una lista de verificación de 12 puntos que corrige selectores, estrategias de espera, aserciones, manejo de errores, patrones de autenticación, compatibilidad móvil y modo estricto. Requiere automation_id. La versión actual del script se guarda antes de la optimización. Devuelve el script optimizado y un resumen de los cambios.
• undo_automation_script — Revierte un script de automatización a su versión anterior. Se conservan hasta 100 versiones anteriores. Requiere automation_id. Devuelve el script restaurado y el número de versiones restantes.

Flujo de trabajo de ejemplo

1. create_automation → crea una prueba con un script personalizado
2. list_automations → explora las pruebas disponibles
3. get_automation → inspecciona el script de Playwright
4. run_automation → inicia la prueba
5. list_automation_runs → consulta los resultados y la duración

⏱️

Seguimiento del tiempo

• list_time_entries — Enumera las entradas de tiempo del equipo. Filtra por period (today, week, month, all), project_id, category y sort (newest, oldest, most_time, least_time). Solo para el plan Enterprise.
• create_time_entry — Registra el tiempo dedicado a tareas de QA. Requiere description, category y duration_minutes. Opcionalmente, establece project_id y entry_date (el valor predeterminado es hoy). Solo para el plan Enterprise.
• update_time_entry — Actualiza una entrada de tiempo existente. Requiere id. Puede actualizar description, category, duration_minutes, project_id o entry_date. Solo para el plan Enterprise.
• delete_time_entry — Elimina permanentemente una entrada de tiempo. Requiere id. Solo para el plan Enterprise.

Flujo de trabajo de ejemplo

1. create_time_entry → registra 45 minutos de pruebas de regresión
2. list_time_entries → consulta las entradas de tiempo de esta semana
3. update_time_entry → ajusta la duración o la categoría
4. delete_time_entry → elimina una entrada incorrecta

☑️

Casos de prueba

Gestión de pruebas con carpetas jerárquicas, suites anidadas (hasta 3 niveles de profundidad, con expansión automática de las subsuites al ejecutar), reordenamiento mediante arrastrar y soltar, y una pestaña Reports de análisis con tendencias de KPI, análisis de fallos, estado de las suites, cobertura y productividad de los evaluadores. Todas las herramientas llaman directamente a Supabase, sin viajes de ida y vuelta HTTP y con la misma latencia que el panel.

Límites del plan Free: 10 casos de prueba almacenados, 1 suite, 3 carpetas, 128 KB de contenido estructurado por caso, 2 claves de API activas por espacio de trabajo y 10 ejecuciones de prueba en total por mes calendario UTC. Hasta 3 de esas ejecuciones pueden usar Hermes u otro agente externo, con 1 ejecución externa activa y un máximo de 10 casos en cada plan externo. El tráfico MCP de claves de API del plan Free está limitado a 30 solicitudes por clave y 60 por espacio de trabajo por minuto. El almacenamiento de casos de prueba y las ejecuciones del plan Enterprise son ilimitados, sujetos a las protecciones generales de la plataforma.

La generación de casos de prueba con IA, las sugerencias de etiquetas con IA, la importación de Figma y los archivos adjuntos a casos de prueba requieren Enterprise. El límite de 128 KB de contenido estructurado del plan Free es independiente de los archivos adjuntos de Enterprise. El plan Free permite almacenar referencias URL. Las herramientas MCP principales para casos de prueba siguen disponibles en el plan Free, dentro de los límites indicados.

Ejecución manos libres: la página de revisión de ejecuciones es un carrusel que muestra un caso a la vez, con atajos de teclado (P Aprobar · F Fallar · B Bloquear · S Omitir) y control por voz. Haz clic en el micrófono y di «Aprobar», «Fallar», «Bloquear», «Omitir», «Siguiente», «Anterior», «Añadir notas» (transcribe el dictado en el campo de notas), «Guardar notas» o «Desactivar voz». Avanza automáticamente al siguiente caso sin probar cuando el resultado es satisfactorio; permanece en el caso actual si falla, para que los evaluadores puedan dictar detalles y crear un error. Funciona en Chrome, Edge y Safari.

Casos y carpetas

• list_test_cases — Enumera los casos de prueba accesibles con un selector opcional project y los filtros search, priority, type, status y sort. Añade folder_id (null para los que no están archivados) o suite_id para la pertenencia directa, sin descendientes. Los usuarios de claves de API necesitan test_cases:read. limit tiene un valor predeterminado de 50 (1-200); offset, de 0 (0-1000000). La matriz cases se devuelve sin cambios, acompañada de total / total_count para todas las coincidencias autorizadas, limit, offset, has_more y next_offset, que admite null. Antes, total indicaba incorrectamente la longitud de la página. Sigue next_offset hasta que sea null; no deduzcas que has terminado por la longitud de la página. Si la continuación supera el desplazamiento 1000000, se produce un error explícito; acota los filtros en lugar de recibir un cursor inutilizable o una falsa indicación de que has terminado. Las páginas que superen 1 MiB de datos de casos producen un error explícito: vuelve a intentarlo con un límite menor, en lugar de aceptar registros omitidos. Se usa un desempate estable por ID, pero las ediciones simultáneas pueden desplazar las páginas por desplazamiento.
• Ejemplo de paginación: llama a list_test_cases con {"project":"test-bed","limit":50,"offset":0}. Para 55 coincidencias, la respuesta contiene total:55, has_more:true, next_offset:50. Repite la llamada con offset:50 para obtener las cinco restantes y has_more:false, next_offset:null.
• create_test_case — Crea un caso de prueba en el selector obligatorio project (UUID, slug, nombre exacto o prefijo de ticket; llama primero a list_projects). Hay dos variantes de plantilla: steps (predeterminada): cuadrícula { action, expected } por paso mediante la matriz steps; text: descripción libre única mediante text_content. Ambos campos pueden enviarse en la misma llamada. La matriz opcional urls (máximo 10 URL http/https) adjunta enlaces de referencia y está disponible en Free. Los archivos adjuntos requieren Enterprise y una sesión del panel. Los usuarios de claves de API necesitan test_cases:write.
• Recuperación de la paginación: solicitar un desplazamiento de caso posterior a los resultados disponibles devuelve un error explícito; reinicia en el desplazamiento 0. Esto también puede ocurrir si se eliminan casos entre solicitudes. Sigue la continuación devuelta en lugar de adivinar el siguiente desplazamiento.
• Identificadores de casos: list_test_cases, get_test_case, create_test_case y update_test_case devuelven el UUID id, el short_id inmutable (por ejemplo, TEST-BA-CASE-123) y el case_number numérico, incluso en respuestas compactas de actualización o sin cambios. Los casos heredados sin proyecto usan TEST-CASE-123. Los identificadores que faltan se devuelven como null; usa el UUID como alternativa. La base de datos asigna los identificadores; los usuarios no pueden cambiarlos ni elegirlos durante la creación. Cambiar el prefijo no modifica los ID existentes.
• Búsqueda de un solo caso: get_test_case y update_test_case aceptan un UUID o un ID corto completo en id; link_test_case_to_bug y list_test_case_links aceptan cualquiera de los dos en case_id. Los espacios en blanco circundantes, las mayúsculas y minúsculas y los ceros de relleno numérico se normalizan antes de la búsqueda exacta en el espacio de trabajo activo. La autorización usa el espacio de trabajo y el proyecto almacenados, no el prefijo del ID. No se aceptan números sin prefijo, ID parciales ni búsquedas con comodines. Las matrices de casos en bloque, case_id de resultados de ejecución, los ID de errores, los ID de carpetas y los ID de suites siguen aceptando únicamente UUID. Los registros de enlaces conservan el UUID case_id.
• Saltos en la numeración: los números de caso no tienen por qué ser consecutivos. Editar una URL o incrementar un número puede llevar a un caso inexistente o inaccesible; no garantiza que se acceda al siguiente caso. Descubre los casos con la herramienta de listado y sigue su paginación.
• Ámbito del espacio de trabajo: el mismo ID corto puede existir en distintos espacios de trabajo. MCP lo resuelve únicamente en el espacio de trabajo activo; cambia el contexto del espacio de trabajo antes de usar el ID corto de otro espacio. Al compartir una URL de ID corto del panel, conserva ?team=<case.team_id>, por ejemplo, /dashboard/test-cases/TEST-BA-CASE-123?team=<team-uuid>. Los enlaces permanentes con UUID mantienen el comportamiento existente de acceso autorizado entre espacios de trabajo. MCP no construye enlaces permanentes.
• get_test_case — Obtiene el registro autorizado del caso, incluidos los pasos y los identificadores. No carga el historial de cambios ni el historial de ejecuciones. Ejemplo: {"id":"TEST-BA-CASE-123"}.
• Estimaciones de ejecución: get_test_case devuelve estimated_time_seconds y el alias de compatibilidad estimated_time, ambos en segundos. Un valor almacenado de 0 se mantiene como 0; una estimación desconocida o ausente es null. El campo canónico prevalece cuando están presentes ambos nombres, incluso si contiene un valor null explícito; los valores de estimated_time que solo usan el formato heredado se interpretan como segundos, sin conversión. list_test_cases usa estimated_time_seconds. La entrada create_test_case sigue siendo estimated_time, también en segundos; las solicitudes y respuestas REST usan estimated_time_seconds.
• list_test_case_folders — Enumera las carpetas accesibles. El límite es de 500; acepta un selector flexible project y el filtro parent_folder_id (usa "root" para obtener solo las de nivel superior). Los usuarios de claves de API necesitan test_cases:read.
• get_test_case_folder — Lee directamente una carpeta de casos de prueba con el id obligatorio (UUID). Devuelve únicamente el registro de la carpeta, sin cargar implícitamente las carpetas descendientes ni los casos de prueba. Requiere acceso a su espacio de trabajo y proyecto; los usuarios de claves de API necesitan test_cases:read.
• Valores de type de los casos de prueba para list_test_cases, create_test_case y bulk_update_test_cases: functional (valor predeterminado al crear), regression, smoke, integration, performance, security, usability, exploratory. Los tipos no válidos se rechazan antes de escribir. Usa integration para flujos de extremo a extremo; e2e, accessibility y other no se aceptan como tipos de casos de prueba. Los tipos de scripts de automatización tienen un contrato independiente.
• create_test_case_folder — Crea una carpeta en el project obligatorio devuelto por list_projects (permite anidar hasta 3 niveles mediante parent_folder_id). Requiere acceso al espacio de trabajo de nivel colaborador o superior y acceso al proyecto. Los usuarios de claves de API también necesitan test_cases:write.
• update_test_case_folder — Actualiza por UUID de carpeta: id, name opcional (se eliminan los espacios en blanco al principio y al final; de 1 a 120 caracteres), description nullable (máximo 50000 caracteres), parent_folder_id nullable y card_color nullable. Un UUID de carpeta principal mueve la carpeta y su subárbol dentro del mismo espacio de trabajo y proyecto; null la mueve a la raíz. El color acepta la paleta en minúsculas #1e293b, #7c2d12, #713f12, #14532d, #1e3a5f, #312e81, #581c87, #831843, #4a044e, #fef08a, #fca5a5, #93c5fd; null lo borra. Los campos omitidos se conservan. Se requiere al menos un campo de actualización. Los campos desconocidos, mal escritos o no válidos rechazan la solicitud completa sin guardar ningún cambio. Se rechazan los ciclos propios o de descendientes, los nombres que coincidan con los de un elemento hermano, padre directo o hijo directo (ignorando mayúsculas y minúsculas y los espacios circundantes), y las profundidades del subárbol superiores a 3 (la profundidad de la raíz es 0). Las profundidades de los descendientes se actualizan de forma atómica; los ID y la pertenencia de los casos no cambian. Los cambios simultáneos en conflicto pueden fallar; vuelve a leer la carpeta antes de reintentarlo. Requiere acceso activo al proyecto de nivel colaborador o superior y test_cases:write para las claves de API. Ejemplo: {"id":"folder-uuid","card_color":"#93c5fd"}. Devuelve id, team_id, project_id, name, description, card_color, parent_folder_id, depth y updated_at actualizados. Las lecturas de carpetas mediante get/list también incluyen card_color.
• update_test_case — Aplica un parche a un caso existente por UUID o ID corto completo en id, con al menos un campo: name (o el alias title), description, preconditions, steps, template_type, text_content, priority, type, status o folder_id. Los campos omitidos se conservan; steps reemplaza la matriz completa ([] la borra). Un valor null explícito borra la descripción, las precondiciones, text_content o la ubicación de la carpeta; un text_content vacío también se borra. Si se envían name y title, deben coincidir. La prioridad y el tipo usan las enumeraciones de creación; el estado es active, draft o deprecated. Un cambio de tipo ajusta type_tags al nuevo tipo, igual que la API PATCH. No permite mover entre espacios de trabajo o proyectos ni escribir metadatos de archivos. Las carpetas deben pertenecer exactamente al mismo espacio de trabajo y proyecto. Requiere test_cases:write. Devuelve el resumen del caso, id, short_id, case_number y changed; los valores sin cambios producen changed: false. Una actualización confirmada con una entrada de historial no confirmada devuelve warnings; no repitas la actualización para corregir el historial. Si se produce un error por cambios simultáneos, vuelve a leer el caso antes de reintentarlo. La pertenencia a suites es independiente: usa la herramienta de operaciones en bloque que aparece a continuación, no suite_id en esta herramienta. No se ofrece ninguna herramienta para eliminar.
• bulk_update_test_cases — Aplica una acción a entre 1 y 500 UUID de casos; pasa un ID para un solo caso. set_folder acepta params.folder_id (UUID para mover, null explícito para quitar de la carpeta). add_to_suite y remove_from_suite aceptan params.suite_id; añadir nunca elimina otras pertenencias ni mueve la carpeta. También admite set_priority, set_status, set_type, add_tags, remove_tags, pin y unpin. Las claves de API requieren test_cases:write. Devuelve applied, skipped y errors; las acciones de organización cuentan las filas modificadas confirmadas, deduplican los ID y omiten las pertenencias existentes.
• Ubicación al crear: create_test_case acepta folder_id y suite_id opcionales. Descubre los destinos con list_test_case_folders y list_test_suites (para descubrir suites, las claves de API necesitan test_runs:read). Las carpetas son una única ubicación del catálogo; las suites son pertenencias de muchos a muchos a planes de prueba. Los destinos deben pertenecer al mismo espacio de trabajo autorizado y al proyecto exacto, incluidos los casos heredados sin ámbito. Los ID de casos inaccesibles se omiten sin detalles; los destinos que no coinciden se rechazan. Los destinos de creación no válidos fallan antes de crear un caso.
• Creación parcial: la creación del caso y la asociación a la suite son escrituras independientes. Si falla la asociación, la respuesta devuelve el ID del caso creado, suite_id: null y una matriz warnings. No repitas create_test_case; vuelve a intentar bulk_update_test_cases con add_to_suite para ese ID devuelto.
• link_test_case_to_bug — Establece la trazabilidad entre un caso de prueba y el UUID de un informe de error (verified_by, covers o relates). Ambos registros deben pertenecer al espacio de trabajo activo y a proyectos accesibles para quien realiza la solicitud.
• list_test_case_links — Enumera todos los enlaces de trazabilidad de un caso de prueba.
• list_test_case_review_candidates — Indicadores de pruebas obsoletas: never_run (90 días o más desde su creación), always_passes (5 o más aprobaciones consecutivas en 90 días), always_skipped (3 o más omisiones consecutivas).
• mark_test_case_review_flags — Guarda los indicadores actuales de candidatos al archivado en test_cases.review_flag. Se ejecuta automáticamente todos los lunes a las 09:00 UTC mediante pg_cron.

Importaciones

• Importación de Figma (Enterprise) (solo sesión del panel): sube un archivo zip de exportación de marcos de Figma (hasta 100 MiB); Claude analiza cada pantalla y redacta casos de prueba en una carpeta que elijas o crees. Antes de decodificarlo, el archivo está limitado a 1,000 entradas, 20 MiB expandidos (decodificados) por entrada y 100 MiB de datos expandidos en total; los presupuestos incluyen los archivos y directorios ignorados. Los búferes de marcos decodificados deben coincidir con los tamaños declarados. Los archivos malformados, las discrepancias de tamaño y los límites excedidos hacen que el trabajo falle antes del análisis de IA; la carga original se conserva en caso de fallo para reintentar, sujeta a la política de limpieza del almacenamiento. Los archivos válidos pasan por un proceso de varias etapas (clasificación → casos por pantalla → casos de flujo entre pantallas con prefijos compartidos → autocrítica), con almacenamiento en caché de indicaciones, reintentos ante errores 429 y aislamiento de errores de IA por marco. Los casos se crean como status=active, con la etiqueta ai_generated=true; source='figma' y source_frame_name conservan un enlace al marco original. Usa la clave de Anthropic de la plataforma; no se requiere una conexión de Claude por equipo.

Suites y ejecuciones

• list_test_suites — Enumera hasta 50 suites de pruebas accesibles con un filtro flexible opcional project. Cada suite incluye un case_count entero exacto: casos asignados directamente de todos los estados, sin descendientes y excluyendo los casos de otros espacios de trabajo o proyectos (se siguen incluyendo los casos heredados sin proyecto). Los recuentos no están limitados por las filas de pertenencia obtenidas. Para mantener la compatibilidad con los trabajadores de ejecución, quienes llamen con una clave de API necesitan test_runs:read.
• get_test_suite — Lee directamente una suite de pruebas con el id obligatorio (UUID). Devuelve solo el registro de la suite, sin cargar implícitamente suites secundarias ni casos de prueba miembros. Requiere acceso a su espacio de trabajo y proyecto; quienes llamen con una clave de API necesitan test_runs:read.
• create_test_suite — Crea una suite en el project obligatorio devuelto por list_projects. Permite anidar hasta 3 niveles mediante parent_suite_id. Quienes llamen con una clave de API necesitan test_cases:write.
• update_test_suite — Actualiza por UUID de suite: id, name opcional (recortado, de 1 a 120 caracteres), description anulable (máximo 50000 caracteres) y status (activa/archivada). Los campos omitidos y la pertenencia de casos se conservan. Requiere acceso activo al proyecto como colaborador o superior y test_cases:write. No se admiten cambios de suite principal ni fijación; los cambios de suite principal requieren el mantenimiento atómico de la profundidad de los descendientes. Devuelve id, team_id, project_id, name, description, parent_suite_id, depth, status y updated_at. Ejemplo: {"id":"suite-uuid","name":"Checkout regression","description":null}.
• list_test_runs — Enumera ejecuciones de pruebas con el nombre de la suite, la persona asignada y un resumen de aprobaciones y fallos. Las evidencias de ejecución cargadas desde el panel usan enlaces privados que requieren una sesión del panel y acceso al espacio de trabajo y proyecto de la ejecución; una clave de API de MCP no concede acceso a los archivos.
• create_test_run — Crea una ejecución de suite administrada desde el panel. Al ejecutar una suite principal, se incluyen automáticamente todos los casos de todas las subsuites descendientes (si un caso está vinculado a ambas, se añade exactamente una vez). Cada fila test_run_results registra de qué subsuite de origen procede el caso, para que las páginas de resultados puedan agruparlos por origen.

Ejecución por agentes externos

Estas herramientas permiten que Hermes u otro entorno de ejecución de agentes ejecute una suite aprobada sin convertirse en el sistema de registro de QA. Usa una clave con alcance limitado al espacio de trabajo y solo test_runs:read y test_runs:write. La suite determina los límites del proyecto; quienes llaman no pueden modificarlos.

• start_test_plan — Inicia o reanuda una instantánea inmutable de la suite con un external_run_id estable. Si se repite el ID, se devuelve la ejecución coincidente existente y su primera página, en lugar de crear un duplicado.
• get_test_run_plan — Lee el estado canónico de la ejecución y una página estable del plan. Pasa el next_cursor anterior; las páginas contienen 100 casos de forma predeterminada y tienen un máximo de 200.
• report_test_results — Envía de 1 a 200 resultados con estado passed, failed, blocked o skipped. Los reintentos exactos son seguros; se rechaza intentar sobrescribir un caso con otro estado.
• abort_test_run — Detiene de forma idempotente una ejecución interrumpida, conservando los resultados parciales aceptados y el resumen canónico.

Comportamiento de la cuota: reintenta start_test_plan con el mismo external_run_id para reanudar la ejecución coincidente sin consumir otra ejecución. Eliminar datos no restablece el uso mensual de ejecuciones.

Límites del entorno de ejecución: las instantáneas de casos excluyen credenciales, contenido de archivos y rutas de adjuntos privados. En la versión MVP, las evidencias de resultados son texto. Las credenciales de destino permanecen en el entorno de ejecución. Los costes de navegador, modelo y red corren por cuenta del cliente, que debe restringir el acceso al destino y el tráfico de salida de la red. Una persona sigue siendo responsable de las decisiones sobre defectos y versiones.

La guía de Hermes Agent ofrece este flujo como una skill comunitaria mantenida por bugAgent. El kit de inicio público incluye una configuración lista para copiar y una skill instalable. No es una integración oficial de Nous Research.

Informes (analítica de nivel 1 y nivel 4)

• get_test_reports_overview — Indicadores clave para un período (tasa de aprobación, ejecuciones completadas, casos ejecutados) con variaciones respecto al período equivalente anterior. Son los mismos valores que muestra la franja de indicadores clave de la pestaña Reports. Esto no crea un informe de proyecto guardado. Los informes de proyecto XLSX de Enterprise y sus programaciones se administran en el panel; en esta versión no hay ninguna herramienta MCP habilitada para esos artefactos guardados.
• Controles de informes del panel: la pestaña Reports puede combinar varias suites (incluidas las descendientes) en un único informe filtrado. Una ejecución completada también tiene una acción Export PDF cuyo denominador de cobertura son los casos incluidos en esa ejecución. Estos controles del panel no añaden parámetros a las herramientas MCP; las descargas de PDF de una sola ejecución requieren una sesión del panel.
• Filtros de casos del panel: la exportación CSV respeta los filtros actuales de Cases en todas las páginas coincidentes. Suite Health y Coverage by suite agrupan las suites secundarias bajo sus suites principales reales dentro del alcance de la suite seleccionada. Las suites principales que solo contienen jerarquía muestran guiones, no métricas agregadas de las suites secundarias. Se excluyen otras suites no relacionadas que compartan los mismos casos. Estas correcciones no cambian los parámetros de las herramientas MCP.
• get_test_reports_failures — Cuatro listas de «¿qué hay que corregir?»: failing_cases (≥50 % de fallos, mínimo 3 ejecuciones), flaky_cases (más cambios entre aprobado y fallido), failing_suites (≥30 % de fallos, mínimo 5 ejecuciones), regressed_cases (fallo más reciente con una aprobación anterior dentro del período).

Flujo de trabajo de ejemplo

1. create_test_case_folder → crea un árbol de carpetas (p. ej., Smoke → Auth). Usa el ID de carpeta devuelto al crear un caso de prueba en el mismo proyecto; el formulario New Test Case del panel también permite crear carpetas en línea.
2. create_test_case → define casos; edita el contenido con update_test_case y organiza la pertenencia a suites con bulk_update_test_cases
3. Ejemplo de tools/call: {"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}}. La prioridad, el tipo y la descripción omitidos no cambian.
4. create_test_suite → crea un plan de pruebas (las subsuites son opcionales; se permiten hasta 3 niveles de profundidad)
5. create_test_run → crea una ejecución administrada por una persona o desde el panel a partir de una suite principal; las subsuites se incluyen automáticamente
6. start_test_plan → inicia o reanuda una ejecución de agente externo con reintentos seguros
7. get_test_run_plan → recupera todas las páginas inmutables del plan y luego ejecútalo en el entorno seleccionado
8. report_test_results → devuelve lotes de resultados acotados; llama a abort_test_run si no es posible continuar la ejecución de forma segura
9. get_test_reports_failures → pregunta «¿qué hay que corregir esta semana?» cuando termine la ejecución
10. get_test_reports_overview → sigue la tendencia de la tasa de aprobación semana a semana

⚡

Refuerzo del equipo

• scale_team — Amplía al instante tu equipo de QA con testers de refuerzo. Las cuentas se aprovisionan automáticamente con acceso de tester. Especifica team_size (1–10), location, duration, budget y, opcionalmente, product_url, product_types y tech_levels. Disponible en el plan Enterprise. No se te cobrará hasta que se haya dado la aprobación.

Flujo de trabajo de ejemplo

1. scale_team → aprovisiona 5 testers sénior en EE. UU. durante 1 mes
2. list_team_members → verifica que los nuevos testers aparezcan en tu equipo
3. list_bug_reports → revisa los informes presentados por los testers de refuerzo

📱

Pruebas móviles (Enterprise)

Los recursos móviles tienen alcance de proyecto. Pasa project_id o un selector flexible project al crear, importar y filtrar listas. Las automatizaciones heredan el proyecto de la aplicación vinculada; de lo contrario, el servidor usa el proyecto predeterminado del espacio de trabajo. Las listas sin filtrar pueden seguir incluyendo filas heredadas del nivel del espacio de trabajo hasta que se migren.

• list_mobile_apps — Enumera las aplicaciones cargadas, con filtros opcionales project_id / project, platform y limit. Devuelve el project_id de cada aplicación para que los agentes puedan mantener las operaciones posteriores en el mismo proyecto.
• upload_mobile_app — Registra una aplicación APK (Android) o IPA (iOS) para probarla en dispositivos reales. Requiere name, platform (android / ios) y file_url; pasa project_id para asignarla al proyecto activo. En iOS, carga el IPA para las ejecuciones en dispositivos reales y, después, usa el panel para cargar una compilación de simulador .app para grabar.
• update_mobile_app — Sustituye el binario de una aplicación por una versión nueva. Borra las URL almacenadas en caché y las compilaciones de simulador para que todas las automatizaciones usen la nueva versión en la siguiente ejecución. Requiere app_id y file_url. Opcional: version. Los perfiles de inicio de sesión privados vinculados requieren que su creador esté activo; los perfiles compartidos requieren acceso activo al mismo proyecto. Las programaciones heredan la configuración predeterminada de automatización protegida.
• list_mobile_automations — Enumera las automatizaciones móviles, con filtros opcionales project_id / project, app_id, status y limit. Los resultados incluyen project_id y el ID de la aplicación vinculada.
• create_mobile_automation — Crea un script de prueba. Requiere name, app_id, script_type (maestro para YAML, appium para Appium Python, appium_js para Appium JavaScript) y script; pasa project_id si la aplicación aún no está asociada a un proyecto. Para un único flujo YAML de Maestro autocontenido y validado externamente, establece execution_mode en browserstack_maestro; de lo contrario, el valor predeterminado es appium_actions. El appId de YAML debe coincidir con el ID de paquete o bundle almacenado de la aplicación vinculada; si no hay ninguno almacenado, el primer flujo nativo validado lo establece. Se rechazan los ID de aplicación de marcador de posición y los ID de recursos de Android ofuscados. Se admite runFlow en línea, pero en la versión 1 se rechazan las referencias a archivos de flujo/script externos. Maestro nativo conserva comandos como inputRandomText y copyTextFrom, además de expresiones de tiempo de ejecución como ${maestro.copiedText} y ${output.value}. Un credential_id del mismo proyecto puede proporcionar valores completos de inputText de tipo ${USERNAME} / ${PASSWORD}. Un variable_profile_id del mismo proyecto puede guardar los valores predeterminados para los valores ${DATA_*} referenciados; todas las claves referenciadas deben existir. Los perfiles de datos solo pueden contener datos sintéticos no secretos.
• import_mobile_script — Importa un script de prueba móvil existente y lo convierte en una automatización ejecutable, conservando los localizadores propios del desarrollador para que las ejecuciones resuelvan los elementos con precisión. Dialectos compatibles: Appium‑Python, WebdriverIO, Maestro (flujos YAML) y Playwright (web móvil). Se omiten los marcadores de posición de ID de recurso de Android ofuscados y se notifican en warnings de asignación de selectores. Solo aplicaciones Android. Requiere name, app_id y script; target_devices y project_id son opcionales. Devuelve la automatización, además de action_count, los dialect detectados y warnings de asignación de selectores.
• run_mobile_automation — Inicia una automatización móvil en un dispositivo real. Requiere automation_id; device, os_version, credential_id y el variable_profile_id de Maestro nativo son opcionales. Para los datos, omite variable_profile_id para heredar el valor predeterminado de la automatización, pasa null para no usar ningún perfil o pasa un UUID del mismo proyecto para anularlo. Deben existir todas las claves ${DATA_*} referenciadas. Un perfil de inicio de sesión privado requiere que su creador esté activo; un perfil de inicio de sesión compartido requiere acceso activo al mismo proyecto. Se filtran los valores de credenciales conocidos exactos y se aplica un filtrado de mejor esfuerzo a los valores exactos de perfiles de datos a partir de evidencia textual persistida; los valores transformados, parciales, codificados o derivados de la aplicación pueden permanecer. Los videos y capturas de pantalla privados autorizados siguen disponibles y pueden mostrar valores representados por la aplicación probada, por lo que los perfiles de datos solo deben contener valores sintéticos no secretos. Si el contexto de redacción de credenciales no está disponible o no se puede demostrar que la sanitización sea segura, se omite el texto detallado que contiene credenciales, pero se mantienen el estado y la evidencia visual disponible. Los diagnósticos requieren autorización para el espacio de trabajo y el proyecto; los enlaces a archivos multimedia caducan a los cinco minutos.
• list_mobile_runs — Obtiene resultados autorizados de ejecuciones móviles (estado, dispositivo, resumen de resultados, enlaces privados a videos y capturas de pantalla, sesión de BrowserStack, registros y errores filtrados de Maestro nativo con credenciales cuando estén disponibles de forma segura, y cualquier error creado automáticamente). Para los diagnósticos de ejecución se exige pertenencia al espacio de trabajo y acceso al proyecto. Filtros opcionales: project_id, automation_id, status (queued, running, passed, failed, error, archived) y limit. De forma predeterminada, se excluyen las ejecuciones archivadas.
• create_login_profile — Crea un perfil cifrado de solo escritura con nombre de usuario y contraseña, reutilizable en Mobile, Web Automation y Exploratory AI. Requiere project_id, name, username y password; visibility es opcional y puede ser private (predeterminado) o shared. Los perfiles privados solo están disponibles para su creador. Los perfiles compartidos pueden usarlos los miembros activos con acceso al mismo proyecto.
• create_mobile_credential — Nombre de compatibilidad para create_login_profile; usa las mismas entradas y el mismo límite de seguridad.
• list_login_profiles — Enumera solo los perfiles visibles para quien realiza la llamada, opcionalmente para un único project_id. Devuelve metadatos no secretos, incluido visibility; se omiten los perfiles privados de otros usuarios y los proyectos inaccesibles.
• list_mobile_credentials — Nombre de compatibilidad para list_login_profiles; nunca devuelve secretos de credenciales.
• update_login_profile — Cambia el nombre, rota o modifica visibility. El creador activo puede actualizar cualquier campo. Un propietario/administrador activo del espacio de trabajo puede cambiar el nombre o rotar un perfil compartido, pero no puede cambiar su visibilidad; los perfiles privados siguen siendo exclusivos de su creador.
• update_mobile_credential — Nombre de compatibilidad para update_login_profile; aplica las mismas comprobaciones de propiedad y proyecto.
• delete_login_profile — Eliminación lógica por parte del creador, con recuperación del ciclo de vida por parte del propietario/administrador solo para perfiles compartidos. Se borran los valores predeterminados para usos futuros, pero se conserva el historial de auditoría.
• delete_mobile_credential — Nombre de compatibilidad para delete_login_profile; se conservan las referencias históricas para auditoría.
• create_mobile_variable_profile — Crea datos de prueba sintéticos reutilizables y asociados a un proyecto con project_id, name y un objeto variables, como {"DATA_EMAIL":"qa@example.test","DATA_REGION":"ca"}. Las claves deben ser identificadores DATA_* en mayúsculas. Los perfiles admiten entre 1 y 100 cadenas, 4096 bytes UTF-8 por valor y 65536 bytes en total. Se rechazan los nombres reservados para credenciales/tiempo de ejecución. Nunca almacenes credenciales, tokens, datos personales de producción ni otros secretos.
• list_mobile_variable_profiles — Enumera los perfiles Mobile/Both y sus valores legibles no secretos para un único project_id autorizado. Se aplican las reglas de asignación de proyectos. Los perfiles existentes y la creación móvil usan both de forma predeterminada; la creación/actualización acepta platform (mobile o both). Los perfiles solo web se excluyen del acceso al catálogo móvil y del uso en tiempo de ejecución.
• update_mobile_variable_profile — Cambia el nombre de un perfil o sustituye el objeto completo variables mediante id. Solo el creador activo o un propietario/administrador activo del espacio de trabajo puede actualizarlo.
• delete_mobile_variable_profile — Elimina lógicamente un perfil mediante id. Solo el creador activo o un propietario/administrador activo del espacio de trabajo puede eliminarlo; se borran los valores predeterminados de automatización, pero se conservan las referencias históricas de ejecución.
• list_mobile_schedules, create_mobile_schedule, delete_mobile_schedule — Enumeran, crean y eliminan programaciones para dispositivos reales. Las programaciones heredan el contexto del proyecto, el perfil de inicio de sesión y el perfil de variables no secretas de la automatización seleccionada. Los perfiles de inicio de sesión privados requieren que su creador esté activo; los perfiles de inicio de sesión compartidos requieren acceso activo al mismo proyecto. Los perfiles de variables no secretas conservan la política de creador o propietario/administrador. Los cambios y la eliminación de programaciones están restringidos al creador activo de la programación o a un propietario/administrador activo del espacio de trabajo.

Catálogo de datos de prueba web

El mismo catálogo de proyectos no secretos está disponible en Automate Web. Estas herramientas requieren la habilitación automation del espacio de trabajo y el ámbito de clave de API automations:write, incluso para las lecturas. No requieren acceso a Mobile. Los valores nunca comparten registros con los perfiles de inicio de sesión cifrados. El catálogo aún no permite vincular ni inyectar valores de perfil en ejecuciones web.

• create_web_variable_profile: requiere project_id, name, variables; platform es opcional (web o both), predeterminado web. Usa los mismos límites DATA_* que en móvil. Devuelve el perfil, incluido su platform.
• list_web_variable_profiles: requiere project_id; devuelve { profiles: [...] } que contiene solo registros Web/Both.
• get_web_variable_profile: requiere id; devuelve un perfil Web/Both accesible y sus valores sintéticos.
• update_web_variable_profile: requiere id; son opcionales name, la sustitución completa variables o platform (web o both). Requiere que el creador activo o un propietario/administrador activo del espacio de trabajo realice la operación. Para restringir Both a Mobile, usa el catálogo Mobile con acceso a Mobile.
• delete_web_variable_profile: requiere id; se aplican los mismos permisos de administración. Realiza una eliminación lógica y devuelve { deleted: true }, conservando el historial de auditoría.

Ejemplo: resuelve un proyecto con list_projects, llama a create_web_variable_profile con {"project_id":"PROJECT_UUID","name":"Canadian checkout","platform":"both","variables":{"DATA_REGION":"CA"}} y luego verifícalo con list_web_variable_profiles. Los proyectos/perfiles inaccesibles generan un error sin exponer sus valores; se rechazan los datos no válidos o los nombres duplicados en todo el proyecto.

Flujo de trabajo de ejemplo — Android

1. list_projects → resuelve el project_id de destino
2. upload_mobile_app → registra el APK en ese proyecto
3. Graba de forma segura en el panel o usa import_mobile_script / create_mobile_automation
4. list_mobile_automations → resuelve la automatización en el mismo proyecto
5. run_mobile_automation → ejecútala en un dispositivo real, opcionalmente con un perfil de inicio de sesión
6. list_mobile_runs → comprueba el estado, el resumen de resultados, los enlaces visuales privados y los metadatos de la sesión de BrowserStack
7. Los errores crean automáticamente informes de errores con una captura del fallo y el desglose de los pasos

Flujo de trabajo de ejemplo — iOS

1. upload_mobile_app → registra tu IPA con project_id para las ejecuciones en dispositivos reales
2. Carga la compilación de simulador .app en la página de detalles de la aplicación (para grabar)
3. Graba la prueba en el navegador → se capturan las acciones del simulador
4. run_mobile_automation → ejecuta la automatización guardada en un iPhone (usa el IPA)
5. update_mobile_app → sustituye el IPA por una versión nueva cuando esté lista

Flujo de trabajo de ejemplo — Maestro nativo

1. upload_mobile_app → registra el APK o IPA en el proyecto de destino
2. create_mobile_credential → crea opcionalmente un perfil del mismo proyecto para un flujo autenticado
3. create_mobile_variable_profile → crea opcionalmente valores sintéticos DATA_* del mismo proyecto que use el flujo
4. create_mobile_automation → pasa un único flujo YAML funcional con el appId exacto del paquete/bundle de la aplicación vinculada, script_type: maestro y execution_mode: browserstack_maestro. Usa ${USERNAME} / ${PASSWORD} para el inicio de sesión y marcadores de posición del tipo ${DATA_EMAIL} para la entrada sintética; pasa los ID de perfil para guardar los valores predeterminados.
5. run_mobile_automation → selecciona un dispositivo compatible y, opcionalmente, anula el perfil de inicio de sesión o de variables. Omite el perfil de variables para heredarlo o pasa null para desactivarlo en una ejecución.
6. list_mobile_runs → inspecciona los resúmenes autorizados de aprobado/suspenso, los videos y capturas de pantalla privados, los registros filtrados, los nombres reales de los pasos, los errores detallados y los metadatos de la sesión. Si no se puede garantizar una sanitización segura para una ejecución con credenciales, se omite el texto detallado, pero se mantienen el estado y la evidencia visual disponible.

Perfeccionar con IA: la versión beta con lista de permitidos está disponible mediante el panel y los endpoints REST de perfeccionamiento. Aún no hay herramientas MCP de perfeccionamiento en el catálogo público.

✅

Cumplimiento y evidencias (Enterprise)

• collect_compliance_evidence — Activa la recopilación automatizada de evidencias de los servicios conectados (Cloudflare, GitHub, Sentry, Supabase, Railway). Devuelve el ID de ejecución. Recopila la configuración de SSL/TLS, el estado de WAF, las alertas de Dependabot, las tendencias de errores, el historial de despliegues y mucho más.
• check_config_drift — Comprueba si hay desviaciones en la configuración de seguridad de todos los servicios conectados con respecto a las líneas base (modo SSL, versión de TLS, HSTS, reglas de WAF, encabezados de seguridad).
• generate_access_review — Crea un informe trimestral de revisión de accesos. Audita a los miembros del equipo, los roles, el estado de MFA y el uso de claves de API, y genera recomendaciones (p. ej., revocar las claves inactivas).
• get_security_events — Consulta la cronología de eventos de seguridad entre servicios. Filtra por origen (cloudflare, sentry, github) y gravedad (crítica, alta, media, baja, informativa). Los eventos se correlacionan automáticamente entre servicios.

Cobertura de cumplimiento

Estas herramientas ayudan a cumplir los requisitos de 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) y GDPR (Art. 5, 25, 32, 33).

Clientes compatibles

bugAgent funciona con cualquier cliente compatible con Model Context Protocol. Aquí tienes guías de configuración para algunos clientes populares:

Abre Settings → Developer → Edit Config y añade:

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

Reinicia Claude Desktop después de guardar.

✳️

Cursor

Abre Settings → MCP Servers → Add Server o edita .cursor/mcp.json en la raíz del proyecto:

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

🌊

Windsurf

Abre Settings → MCP → Add Server o edita el archivo de configuración de MCP:

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

Añade bugAgent directamente desde la terminal:

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

Esto se conecta directamente al servidor Streamable HTTP alojado.

Para los clientes que requieren stdio, usa el puente publicado bugagent-mcp:

• Comando: npx
• Línea de comandos: npx -y bugagent-mcp
• Args: ["-y", "bugagent-mcp"]
• Env: BUGAGENT_API_KEY

Obtener ayuda

¿Necesitas ayuda? Estamos aquí para ayudarte.

Comunidad de Discord

Únete a nuestro Discord para recibir asistencia en tiempo real y participar en debates de la comunidad.

Asistencia por correo electrónico

support@bugagent.com — Normalmente respondemos en un plazo de 24 horas.