Debugg AI

oficial

Permite que tus agentes de generación de código creen y ejecuten pruebas integrales sin configuración contra nuevos cambios de código en navegadores remotos a través de la plataforma de pruebas Debugg AI.

¿Qué puedes hacer con Debugg AI MCP?

  • Ejecutar pruebas de navegador con IA — Pídele al asistente que use check_app_in_browser contra cualquier URL o localhost, describiendo qué probar en lenguaje natural, y obtén resultados de aprobado/fallido con capturas de pantalla.
  • Explorar múltiples páginas rápidamente — Usa probe_page para verificar en lote de 1 a 20 URLs en busca de errores de consola, problemas de red y estado renderizado, sin costo de LLM ni bucles de agente.
  • Activar rastreos del grafo de conocimiento — Llama a trigger_crawl para ejecutar un rastreo de agente de navegador del lado del servidor que complete el grafo de conocimiento del proyecto con artefactos de HAR y registros de consola.
  • Gestionar suites y casos de prueba — Crea, ejecuta y revisa resultados para entidades test_suite y test_case, con resultados por prueba y tasas de aprobación.
  • Inspeccionar artefactos de ejecución — Recupera detalles completos de ejecución mediante executions, incluyendo capturas de pantalla, trazas de red HAR y registros de consola para depurar problemas en tiempo de ejecución.
  • Gestionar entornos y sesiones — Crea o actualiza entornos con credenciales mediante environment, y usa sessions/clearSessions para controlar la reutilización de sesiones de inicio de sesión activas.

Documentación

Debugg AI — Servidor MCP

Pruebas de navegador impulsadas por IA a través del Protocolo de Contexto de Modelo. Apúntalo a cualquier URL (o localhost) y describe qué probar: un agente de IA navega por tu aplicación y devuelve aprobado/fallido con capturas de pantalla.

Debugg AI MCP server

Configuración

Requiere Node.js 20.20.0 o posterior (requisito transitivo de posthog-node@^5.26.0).

Probar URLs http://localhost:... requiere el binario caddycheck_app_in_browser, probe_page y trigger_crawl tunelizan objetivos localhost a través de un proxy inverso Caddy local. Esto se instala automáticamente: la dependencia npm @radically-straightforward/caddy descarga una versión fijada de Caddy para tu plataforma durante npm install/npx, igual que este proyecto ya hace para el binario ngrok — no necesitas instalar nada tú mismo en el caso normal. Si esa descarga nunca se ejecutó (npm install --ignore-scripts, una instalación sin conexión/aislada), apunta CADDY_BIN a tu propia instalación (brew install caddy / apt install caddy / consulta caddyserver.com/docs/install) — su ausencia se manifiesta como un error claro en la primera llamada a una URL localhost, no como un cuelgue silencioso. Las llamadas a URLs públicas, todas las herramientas que no son de navegador y test_suite {action:"run"} (que usa su propio túnel dedicado y omite Caddy por completo) no lo necesitan en ningún caso.

Obtén una clave API en debugg.ai y luego añádela a la configuración de tu cliente MCP:

{
  "mcpServers": {
    "debugg-ai": {
      "command": "npx",
      "args": ["-y", "@debugg-ai/debugg-ai-mcp"],
      "env": {
        "DEBUGGAI_API_KEY": "your_api_key_here"
      }
    }
  }
}

O con Docker:

docker run -i --rm --init -e DEBUGGAI_API_KEY=your_api_key quinnosha/debugg-ai-mcp

El paso npm install del Dockerfile detectaría caddy de la misma manera automática que las instalaciones locales lo hacen, en principio — pero al momento de escribir esto, el Dockerfile no COPY varios directorios que el build ahora necesita (handlers, tools, types, config) y todavía referencia un directorio tunnels/ que ya no existe, por lo que un build nuevo probablemente falle antes de que eso importe. Esa es una brecha preexistente, no relacionada con Caddy. La imagen quinnosha/debugg-ai-mcp actualmente publicada es anterior a la dependencia de Caddy de todos modos — las llamadas a URLs localhost hacia check_app_in_browser/probe_page/trigger_crawl fallarán con CaddyBinaryNotFoundError dentro de esa imagen hasta que se reconstruya (Dockerfile corregido) y se vuelva a publicar, o CADDY_BIN apunte a una integrada por separado. Las llamadas a URLs públicas, las herramientas que no son de navegador y test_suite {action:"run"} no se ven afectadas en ningún caso.

Herramientas

El servidor expone 8 herramientas: tres herramientas de Navegador más una herramienta basada en acciones por entidad gestionada. Las herramientas principales son check_app_in_browser (agente de IA completo) y probe_page (sonda de página ligera sin LLM). El resto — project, environment, test_suite, test_case, executions — cada una toma un discriminador action (p. ej. {"action":"list"}) que selecciona la operación. Las acciones destructivas delete requieren confirmación (una solicitud de aclaración donde se admita; de lo contrario, confirm: true).

Navegador

check_app_in_browser

Ejecuta un agente de navegador de IA contra tu aplicación. El agente navega, interactúa e informa con capturas de pantalla. Las URLs localhost se tunelizan automáticamente mediante ngrok.

ParámetroTipoDescripción
descriptioncadena obligatorioQué probar (lenguaje natural)
urlcadena obligatorioURL de destino — http://localhost:3000 se tuneliza automáticamente
environmentIdcadenaUUID de un entorno específico
credentialIdcadenaUUID de una credencial específica
credentialRolecadenaElegir una credencial por rol (p. ej. admin, guest)
usernamecadenaNombre de usuario para iniciar sesión (efímero — no se persiste)
passwordcadenaContraseña para iniciar sesión (efímera — no se persiste)
loginCredentialsmatrizCuentas para los inicios de sesión que el agente encuentra durante la tarea — [{username, password, label?}]
useEnvironmentCredentialsbooleanoPor defecto true. false prohíbe autocompletar las credenciales almacenadas del entorno; sin una cuenta nombrada significa no iniciar sesión en absoluto
freshSessionbooleanoPor defecto false. true fuerza un inicio de sesión real en lugar de reutilizar la sesión cálida mantenida para esa cuenta
authobjetoPrecondición de autenticación — {precondition, entryUrl, deepUrl, environmentId, username, password}
repoNamecadenaAnular el nombre del repositorio git detectado automáticamente (p. ej. my-org/my-repo)

Una comprobación enfocada por llamada. El agente tiene un presupuesto interno de ~25 pasos; divide las suites más amplias en varias llamadas.

Credenciales: pásalas como parámetros, no como prosa

Nombrar una cuenta solo en description no hace que el agente la use — recurre a la credencial almacenada del entorno, y el rechazo de la cuenta incorrecta por parte de la aplicación parece un fallo de la aplicación. Cualquier cosa que pases como parámetro supera al valor predeterminado del entorno para cada inicio de sesión en la ejecución, no solo el primero:

  • username / password (o credentialId / credentialRole) — la identidad de la ejecución.
  • auth.username / auth.password — fija el inicio de sesión de precondición cuando también usas auth.precondition: "login".
  • loginCredentials — cuentas para un formulario de inicio de sesión que el agente encuentra a mitad de la tarea. Esta es la opción para flujos como establecer contraseña → ser redirigido al inicio de sesión → iniciar sesión como la cuenta que acabas de crear, donde dividir en llamadas separadas perdería el estado del navegador.

Establece useEnvironmentCredentials: false cuando una recurrencia silenciosa al usuario de prueba predeterminado invalidaría la comprobación.

¿Comprobando una página que no necesita inicio de sesión? Pasa useEnvironmentCredentials: false y no nombres ninguna cuenta. Esa combinación significa exactamente lo que dice — no iniciar sesión — y la ejecución omite la autenticación por completo en lugar de buscar un formulario de inicio de sesión. Úsalo para páginas públicas, sitios de marketing, documentación y cualquier cosa previa a la autenticación. También es más rápido: en el valor predeterminado (auto), el agente seguirá un enlace "Iniciar sesión" fuera de tu página e intentará la cuenta almacenada del entorno antes de evaluar cualquier cosa.

Reutilización de sesiones: por qué una comprobación puede informar "sin formulario de inicio de sesión"

Las ejecuciones no inician sesión cada vez. Después de un inicio de sesión verificado, el backend captura la sesión de esa cuenta y la restaura en la siguiente ejecución para la misma identidad, lo que omite el inicio de sesión por completo — por eso una comprobación puede legítimamente volver con submitted: false y sin formulario de inicio de sesión: ya estaba autenticada. Una ejecución restaurada se informa a sí misma en logins con reason: "restored_session", para que puedas distinguirla de una ejecución que genuinamente no encontró ningún formulario.

Las sesiones se clasifican por cuenta, por lo que nombrar una cuenta diferente nunca reutiliza la de otra persona. Dos formas de omitir la reutilización:

  • freshSession: true en una sola llamada — inicia sesión de verdad esta vez y luego vuelve a capturar. Úsalo cuando el flujo de inicio de sesión es lo que estás comprobando, cuando sospeches que la sesión almacenada está obsoleta, o cuando la única ruta de la aplicación entre personas sea cerrar sesión.
  • Herramienta environment, action: "clearSessions" — invalida las sesiones almacenadas para que las ejecuciones posteriores inicien sesión. Limita con username / credentialId; las limpiezas sin alcance requieren confirmación porque cada cuenta en el entorno se vuelve a autenticar.

Usa action: "sessions" para ver qué está reteniendo actualmente un entorno y si cada una se reutilizaría.

Los resultados informan la identidad realmente utilizada, por lo que una incorrecta es visible en lugar de hacerse pasar por una aplicación rota:

"logins": [
  { "username": "qa+invitefix@example.com", "source": "task", "submitted": true, "authenticated": true }
],
"credentialWarning": {
  "requested": "qa+invitefix@example.com",
  "used": ["qatest123@example.com"],
  "message": "This run signed in with an environment default credential even though '…' was specified. …"
}

source es task | explicit | credential_id (una cuenta que nombraste) o env | env_default (la cuenta almacenada del entorno). credentialWarning aparece solo cuando nombraste una cuenta y se usó un valor predeterminado del entorno de todos modos. loginError aparece cuando una cuenta nombrada no pudo resolverse y la ejecución se negó a sustituir una diferente.

Cada ejecución exitosa devuelve un bloque browserSession junto con la captura de pantalla — URLs S3 prefirmadas para el HAR capturado (traza de red completa) y el registro de consola (cada mensaje de consola JS). Úsalos para detectar bucles de reobtención, errores de hidratación y otros problemas de tiempo de ejecución que pasan las comprobaciones de tipos y las pruebas unitarias:

"browserSession": {
  "harUrl": "https://...session_18139.har?X-Amz-...",
  "consoleLogUrl": "https://...session_18139_console.json?X-Amz-...",
  "recordingUrl": "https://...session_18139_recording.webm?X-Amz-...",
  "harStatus": "downloaded",
  "consoleLogStatus": "downloaded",
  "harRedactionStatus": "redacted",
  "consoleLogRedactionStatus": "redacted"
}

Las URLs son S3 prefirmadas de corta duración — vuelve a obtener la ejecución principal mediante executions {action:"get", uuid} para renovarlas. harStatus / consoleLogStatus desambiguan 'downloaded' (URL obtenible), 'not_available' (la página no emitió nada), 'failed' (la captura falló). En una ejecución nueva, las URLs suelen ser null porque la captura se sube de forma asíncrona después de que el agente termina — consulta executions {action:"get", uuid: executionId} hasta que el estado alcance 'downloaded'. Los encabezados de Autorización / Cookie / token/secret/api_key se depuran en el servidor antes de que los artefactos se persistan.

trigger_crawl

Dispara un rastreo de agente de navegador del lado del servidor para poblar el grafo de conocimiento del proyecto. Las URLs localhost se tunelizan automáticamente. Devuelve {executionId, status, targetUrl, durationMs, outcome?, crawlSummary?, knowledgeGraph?, browserSession?} con knowledgeGraph.imported === true en la ingesta exitosa. El bloque browserSession (URLs de HAR + registro de consola, misma forma que arriba) también está presente en rastreos completados.

probe_page

Sonda de página por lotes ligera sin LLM. Pasa 1-20 URLs; cada una navega, se asienta en el contenido (el DOM se silencia, con límite — nunca en silencio de red, que una aplicación en vivo nunca alcanza) y devuelve el estado renderizado — captura de pantalla + metadatos de página + errores de consola estructurados + resumen de red. Sin bucle de agente, sin costo de LLM, sin aserciones de escenario. Úsalo para "¿acabo de romper /settings?", pruebas de humo de múltiples rutas después de una refactorización, barridos por PR en CI y comprobaciones rápidas de disponibilidad donde el bucle de agente de 60-150s de check_app_in_browser es excesivo.

ParámetroTipoDescripción
targetsmatriz obligatorio1-20 entradas: [{url, waitForSelector?, waitForLoadState?, timeoutMs?}]
targets[].urlcadena obligatorioURL pública o localhost (tunelizado automáticamente)
targets[].waitForLoadStateenumeración'domcontentloaded' (predeterminado, + un asentamiento de contenido con límite) / 'load' (también bloquea en incrustaciones de terceros) / 'networkidle' (aceptado, nunca emitido — la red de un sitio en vivo no se vuelve inactiva)
targets[].waitForSelectorcadenaSelector CSS opcional para esperar después de la navegación
targets[].timeoutMsnúmeroTiempo de espera por URL, 1000-30000 (predeterminado 10000)
includeHtmlbooleanoDevolver HTML sin procesar en cada resultado (predeterminado falso)
captureScreenshotsbooleanoDevolver un PNG por objetivo (predeterminado verdadero)

Todos los objetivos en un lote comparten un túnel de sesión, pero solo los lotes del mismo puerto (o todos públicos) comparten una única ejecución de backend — 5 URLs en un puerto en una llamada es dramáticamente más rápido que 5 llamadas paralelas de una sola URL. Un lote que mezcla múltiples puertos locales se descompone en una ejecución de backend secuencial por grupo de puertos (sigue siendo una llamada, sigue siendo un results[] fusionado en tu orden original, pero N viajes de ida y vuelta de backend en lugar de uno — más lento, no rechazado). El campo error por URL preserva la resiliencia del lote: un objetivo fallido no hace fallar a los demás.

La clave de agregación de networkSummary es origin + pathname — los bucles de reobtención (?n=0..4 golpeando repetidamente el mismo endpoint) se colapsan en una sola entrada con el conteo, por lo que /api/poll apareciendo con count: 47 es la señal accionable de "bucle de reobtención infinito" que los usuarios pidieron originalmente.

Presupuesto de rendimiento: <10s para 1 URL, <25s para 20. Un puerto muerto en localhost devuelve LocalServerUnreachable en <2s sin consumir una ejecución de flujo de trabajo.

project

AcciónParámetrosResultado
get{uuid}Detalle de proyecto curado
list{q?, page?, pageSize?}Resúmenes paginados
create{name, platform, (teamUuid|teamName), (repoUuid|repoName)}Proyecto creado

El equipo y el repositorio se resuelven por uuid o nombre (coincidencia exacta sin distinción de mayúsculas; NotFound si ninguno, AmbiguousMatch si varios). No hay update/delete — renombra o elimina un proyecto desde la aplicación web de DebuggAI.

environment

AcciónParamsResultado
get{uuid, projectUuid?}Entorno con credenciales incrustadas (las contraseñas nunca se devuelven)
list{projectUuid?, q?, page?, pageSize?}Entornos paginados, cada uno con un array de credenciales
create{name, url, description?, projectUuid?, credentials?}Entorno creado (opcionalmente siembra credenciales)
update{uuid, name?, url?, description?, addCredentials?, updateCredentials?, removeCredentialIds?}Entorno parcheado; las operaciones de credenciales se ejecutan eliminar → actualizar → agregar
delete{uuid, projectUuid?, confirm?}Elimina el entorno (cascada de credenciales) — requiere confirmación
sessions{uuid, username?, credentialId?}Sesiones de inicio de sesión capturadas que el entorno mantiene, por cuenta, con isUsable y un usableCount
clearSessions{uuid, username?, credentialId?, confirm?}Las invalida para que la próxima ejecución inicie sesión de verdad — las limpiezas sin alcance requieren confirmación

projectUuid se resuelve automáticamente desde el repositorio git cuando se omite. Los fallos por credencial aparecen en credentialWarnings[] sin bloquear la operación del entorno.

sessions / clearSessions gestionan las sesiones autenticadas en caliente que el backend reutiliza para omitir el inicio de sesión (ver Reutilización de sesiones). El contenido de las sesiones nunca se devuelve — una cookie de sesión es una credencial portadora. clearSessions marca las sesiones como inválidas en lugar de eliminar las filas, de modo que la reutilización se detiene inmediatamente mientras el historial de captura permanece legible.

test_suite

AcciónParamsResultado
list{projectUuid|projectName, search?, page?, pageSize?}Suites paginados con estado + tasa de aprobación
create{name, description, projectUuid|projectName}Suite creado
run{suiteUuid|(suiteName+project), targetUrl?}Dispara todas las pruebas de forma asíncrona
results{suiteUuid|(suiteName+project)}Suite + resultados por prueba
delete{suiteUuid|(suiteName+project), confirm?}Eliminación suave — requiere confirmación

test_case

AcciónParamsResultado
create{name, description, agentTaskDescription, suiteUuid|(suiteName+project), relativeUrl?, maxSteps?}Caso de prueba creado (no se ejecuta automáticamente)
update{testUuid, name?, description?, agentTaskDescription?}Caso de prueba parcheado
delete{testUuid, confirm?}Eliminación suave — requiere confirmación

executions

AcciónParamsResultado
get{uuid}Detalle completo (nodeExecutions + estado + errorInfo) + artefactos de captura de pantalla/gif
list{status?, projectUuid?, page?, pageSize?}Resúmenes paginados

El 404 del backend se presenta como isError: true con {error: 'NotFound', message, uuid}. Las credenciales siempre se devuelven sin contraseñas.

Paginación

Cada respuesta en modo filtro está paginada. Forma de la respuesta:

{
  "filter": { "...echoed query params..." },
  "pageInfo": { "page": 1, "pageSize": 20, "totalCount": 47, "totalPages": 3, "hasMore": true },
  "<items>": [ ... ]
}

Pase el page opcional (indexado desde 1, predeterminado 1) y pageSize (predeterminado 20, máximo 200; los valores sobredimensionados se limitan). Ninguna respuesta se trunca silenciosamente.

Recursos

Junto a las herramientas, el servidor expone las entidades de solo lectura como recursos de MCP para que los clientes puedan navegar y mencionarlos con @ como contexto:

URIQué
debugg-ai://projectsTodos los proyectos (primera página)
debugg-ai://environmentsEntornos para el proyecto auto-detectado
debugg-ai://executionsEjecuciones recientes (primera página)
debugg-ai://project/{uuid}Un proyecto, detalle completo
debugg-ai://environment/{uuid}Un entorno (credenciales incrustadas, contraseñas redactadas)
debugg-ai://execution/{uuid}Una ejecución, detalle completo del nodo + enlaces de artefactos

Las lecturas se envían a los mismos manejadores que las herramientas project / environment / executions, por lo que los datos y la autenticación son idénticos. Los recursos son aditivos — los clientes sin soporte de recursos siguen usando las herramientas.

Invariantes de seguridad

  • Las contraseñas son de solo escritura. Nunca aparecen en ningún cuerpo de respuesta de ninguna herramienta.
  • Las URL de túnel (*.ngrok.debugg.ai) se eliminan de todas las respuestas del agente de navegador, incluido el texto escrito por el agente.
  • Los 404 del backend se presentan como isError: true con {error: 'NotFound', ...}, nunca como excepciones lanzadas.
  • La falta de DEBUGGAI_API_KEY se presenta como un error de herramienta estructurado en la primera invocación — el servidor aún registra y lista las herramientas normalmente.

Migración a v3.0.0 (herramientas basadas en acciones)

v3 consolidó las 20 herramientas por verbo en 8 herramientas basadas en acciones. Herramienta antigua → nuevo tool {action}:

EliminadaReemplazo
search_projectsproject {action:"get"} / project {action:"list"}
create_projectproject {action:"create"}
update_project, delete_projectEliminadas — use la aplicación web de DebuggAI
search_environmentsenvironment {action:"get"} / {action:"list"}
create_environment / update_environment / delete_environmentenvironment {action:"create"|"update"|"delete"}
create_test_suite / search_test_suites / run_test_suite / get_test_suite_results / delete_test_suitetest_suite {action:"create"|"list"|"run"|"results"|"delete"}
create_test_case / update_test_case / delete_test_casetest_case {action:"create"|"update"|"delete"}
search_executionsexecutions {action:"get"|"list"}
trigger_crawl headless paramEliminado — siempre sin interfaz gráfica

Las acciones de delete ahora requieren confirmación (mensaje de elicitación, o confirm: true). Los clientes adoptan la nueva superficie al reiniciar MCP.

Migración desde v1.x (cambio disruptivo en v2.0.0)

v2 redujo una superficie de 22 herramientas a 11. Mapeo de herramienta antigua → herramienta nueva:

EliminadaReemplazo
list_projects, get_projectsearch_projects (modo uuid vs modo filtro)
list_environments, get_environmentsearch_environments
list_credentials, get_credentialsearch_environments — credenciales incrustadas en cada entorno
create_credentialcreate_environment({credentials: [...]}) seed, o update_environment({addCredentials: [...]})
update_credentialupdate_environment({updateCredentials: [{uuid, ...patch}]})
delete_credentialupdate_environment({removeCredentialIds: [uuid]})
list_teams, list_reposcreate_project({teamName, repoName}) — resolución de nombres con manejo de ambigüedad
list_executions, get_executionsearch_executions
cancel_executionEliminada — el apagado del backend es automático

Cambios en la forma de las respuestas: el campo count en las respuestas de lista ha desaparecido — use pageInfo.totalCount.

Configuración

Variable de entornoRequeridaPropósito
DEBUGGAI_API_KEYClave API del backend. Aliases: DEBUGGAI_API_TOKEN, DEBUGGAI_JWT_TOKEN.
DEBUGGAI_API_URLnoURL base del backend. Predeterminada: https://api.debugg.ai.
DEBUGGAI_TOKEN_TYPEnotoken (predeterminado) o bearer.
DEBUGGAI_EVAL_TEMPLATEnoSobrescribe el slug del flujo de trabajo de Evaluación de Apps al que check_app_in_browser envía. Predeterminado: flow/e2es/app-eval. El envío se fija a este slug para que un cambio de nombre de plantilla del backend no lo rompa.
LOG_LEVELnoerror / warn / info (predeterminado) / debug.
POSTHOG_API_KEYnoSobrescribe la clave de proyecto de telemetría incrustada (p. ej., fork privado).
DEBUGGAI_TELEMETRY_DISABLEDnoEstablézcala en 1 / true / yes / on para deshabilitar la telemetría por completo.
DEBUGGAI_API_KEY=your_api_key

Transporte remoto / HTTP (opcional)

Por defecto, el servidor habla stdio (npx local). Puede ejecutarse como un MCP remoto alojado y multiusuario sobre Streamable HTTP sin estado + OAuth:

DEBUGGAI_MCP_TRANSPORT=http PORT=3000 DEBUGGAI_TOKEN_TYPE=bearer npx -y @debugg-ai/debugg-ai-mcp@latest

Es un Servidor de Recursos OAuth: cada POST /mcp necesita Authorization: Bearer <token>; los tokens faltantes o inválidos reciben un 401 con un WWW-Authenticate que apunta a los metadatos RFC 9728, y los clientes ejecutan el flujo OAuth contra el servidor de autorización anunciado. El portador tiene alcance por solicitud — api.debugg.ai lo valida.

EndpointPropósito
POST /mcpMCP Streamable HTTP (protegido por portador)
GET /.well-known/oauth-protected-resourceMetadatos RFC 9728 (descubrimiento del servidor de autorización)
GET /healthVerificación de salud del balanceador de carga / ECS
Variable de entornoPredeterminadaPropósito
DEBUGGAI_MCP_TRANSPORTstdioEstablézcala en http para el transporte remoto
PORT3000Puerto de escucha HTTP
DEBUGGAI_MCP_PUBLIC_URLhttps://mcp.debugg.aiURL pública de recursos de este servidor (RFC 9728 resource)
DEBUGGAI_OAUTH_ISSUERhttps://auth.debugg.aiServidor de autorización anunciado a los clientes
DEBUGGAI_TOKEN_TYPEtokenEstablézcala en bearer para que los tokens OAuth se reenvíen como Authorization: Bearer

Las instalaciones stdio no necesitan ninguna de estas.

Implementaciones multi-réplica (decisión de ir/no ir antes del lanzamiento): el estado del túnel (la sesión del túnel ngrok, su instancia de Caddy y su bloqueo de ruta de puerto) está en proceso, con clave por llamador mediante un hash del token portador — no hay coordinación entre procesos. Ejecutar varias réplicas detrás de un balanceador de carga round-robin simple significa que las llamadas de un llamador pueden aterrizar en réplicas diferentes y crear un túnel por réplica que toquen en lugar de uno para toda la sesión (costo extra de ngrok, limitado por el número de réplicas, auto-reparable mediante el apagado automático por inactividad de 55 minutos existente — nunca un error de corrección entre sesiones, ya que cualquier llamada de herramienta individual permanece en una réplica durante toda su duración). Para obtener el comportamiento previsto de "un túnel por sesión" en una implementación HTTP multi-réplica, configure enrutamiento afín a la sesión en el balanceador de carga (hash fijo/consistente con clave en la misma identidad de la que getSessionKey() deriva — en la práctica, el token portador Authorization del llamador). Ver docs/local-tunnel-multiplexer-architecture-2026-07-31.md §2.1 para el razonamiento completo y la ruta de degradación honesta si esto no está configurado.

Telemetría

El servidor MCP incluye telemetría habilitada por defecto — una clave de proyecto PostHog de solo escritura incrustada (phc_*) para que el equipo pueda observar tasas de acierto de caché, cadencia de sondeo, confiabilidad del túnel y otras métricas operativas en toda la base de instalaciones. Eventos capturados:

EventoCuándo
tool.executed / tool.failedPor llamada de herramienta
workflow.executedPor ejecución de agente de navegador (lleva pollCount, durationMs, finalIntervalMs)
tunnel.provisioned / tunnel.provision_retry / tunnel.stoppedPor evento del ciclo de vida del túnel
template.lookup / project.lookupAcierto/fallo de caché con durationMs en llamada en frío

Postura de privacidad:

  • El ID distinto es SHA-256(api_key).slice(0, 16) — nunca la clave cruda, sin PII.
  • Las claves de phc_* son de solo escritura por convención de PostHog; seguras para incrustar en el código fuente.
  • Establezca DEBUGGAI_TELEMETRY_DISABLED=1 para optar por no participar por completo (se resuelve a un proveedor no operativo; ningún evento sale del proceso).

El modo activo se registra al arrancar:

Telemetry enabled (PostHog, DebuggAI default project). Set DEBUGGAI_TELEMETRY_DISABLED=1 to opt out.
Telemetry enabled (PostHog, custom POSTHOG_API_KEY)
Telemetry disabled (DEBUGGAI_TELEMETRY_DISABLED is set)

Desarrollo Local

npm install
npm run build
npm run test:e2e        # real end-to-end evals against the backend

La suite de evaluación inicia el servidor MCP compilado como subproceso, ejercita cada herramienta contra un backend real y escribe artefactos por flujo en scripts/evals/artifacts/<timestamp>/. Ver scripts/evals/flows/ para los escenarios individuales.

Registro MCP: debugg-ai-local vs debugg-ai

Este repositorio incluye un .mcp.json que registra un servidor con alcance de proyecto llamado debugg-ai-local que apunta a node dist/index.js — el código local recién compilado. Solo se activa cuando el directorio de trabajo de Claude Code es este repositorio.

Sus otros proyectos deberían usar el registro debugg-ai con alcance de usuario que extrae del paquete npm publicado:

npm run mcp:global      # registers debugg-ai in ~/.claude.json to npx -y @debugg-ai/debugg-ai-mcp

Después de editar código aquí, ejecute npm run mcp:local (que solo recompila) para que la próxima invocación de debugg-ai-local recoja sus cambios.

Enlaces

Dashboard · Docs · Issues · Discord


Licencia Apache-2.0 © 2025 DebuggAI