Este era un flujo de trabajo normal hasta hace poco.
Llega un reporte de bug. Abres el panel, lo lees, encuentras el error de consola y lo copias. Cambias al editor, lo pegas en Claude Code y añades algo de contexto. El agente pregunta qué devolvió la petición. Vuelves al panel, buscas el registro de red, copias la respuesta y la pegas. Y así sucesivamente.
Eres un portapapeles. El agente razona y tú transportas datos entre dos sistemas que podrían hablar entre sí.
Así que hice que hablaran entre sí.
El servidor MCP
BugDump incluye un servidor de Model Context Protocol. Conéctalo a Claude Code y el agente lee tus reportes de bug directamente. Siete herramientas:
Herramienta | Devuelve |
|---|---|
| El proyecto al que está vinculada esta clave |
| Tareas, para encontrar una |
| Una tarea, por ID público o ID de tarea |
| El historial de una tarea |
| Los reportes adjuntos a una tarea |
| Un reporte: consola, red, capturas de pantalla |
| La telemetría completa, por páginas |
Todo el flujo se reduce a una frase:
Mira la tarea #42 en BugDump y arréglala.
El agente lee la tarea, trae los reportes adjuntos, relaciona el error de consola con la petición que falla, encuentra el código correspondiente en tu repositorio y propone un arreglo. Nunca abres el panel.
Por qué funciona mejor que pegar
La ventaja obvia es que dejas de ser un portapapeles. Hay otras dos menos obvias.
El agente hace mejores preguntas que tú. Cuando copias un stack trace, ya has decidido qué es relevante, y lo decidiste antes de entender el bug. Un agente con acceso directo puede seguir las pruebas: leer la consola, fijarse en una petición que falla, recorrer el registro de red para ver su cuerpo completo, comprobar si otros reportes de la misma tarea muestran el mismo fallo. Son muchas consultas pequeñas. Cada una es trivial de servir y tediosa de hacer a mano, y justo por eso no se hacen.
Puede comparar entre reportes. Pregúntale qué navegadores están afectados por la tarea #17 y el agente lee todos los reportes adjuntos y te lo dice. Es un trabajo tedioso de verdad: del tipo que se salta quien hace el triaje, y del tipo que identifica un bug como propio de un navegador en diez segundos en lugar de en una tarde.
Las decisiones de diseño
Dos decisiones definieron cómo funciona esto.
Las claves están vinculadas para siempre a un proyecto. Ninguna herramienta tiene un parámetro de proyecto. Una clave MCP recibe su alcance al crearse y no se puede ampliar después. Cuando le das una clave a un agente autónomo, «esta clave solo podrá ver un proyecto» es una garantía mucho más fuerte que «al agente le han dicho que solo mire un proyecto».
Además, las claves MCP son de solo lectura y están separadas de las claves del widget. La clave de tu frontend no puede leer reportes; la clave que lee reportes nunca se acerca a un navegador.
Resumen por defecto, telemetría completa a petición. get_report devuelve las últimas 50 entradas de consola, sin los cuerpos de red. Un reporte puede contener miles de entradas, y volcarlo todo en una ventana de contexto en cada consulta es la forma de acabar con un agente que lo ha leído todo y no ha entendido nada.
Pero un truncado que se esconde es peor que no truncar. Así que el resumen dice qué se recortó, y get_report_telemetry recorre por páginas el historial completo (consola, red con cuerpos, acciones) en bloques cronológicos hasta que no queda nada.
La regla que importa: un resumen que no muestra nada no es prueba de que no haya nada.
Prompts que funcionan
Mira la tarea #42 en BugDump y arréglala.
¿Qué tienen en común las tareas abiertas en BugDump?
Lee los reportes de #17 y dime qué navegadores están afectados.
Revisa la tarea #8: ¿es el mismo bug que #3?
Esa última es mi favorita. Decidir si dos reportes son el mismo bug exige comparar al detalle dos conjuntos de telemetría, que es justo el trabajo que todos se saltan y justo el que mantiene las tareas duplicadas fuera de tu tablero.
La idea de fondo
Construí primero la capa de captura porque el problema eran los reportes de bug incompletos. El servidor MCP no estaba en el plan; se volvió obvio después.
Un reporte completo (consola, red, acciones, repetición, entorno) resulta ser una entrada bien formada para un agente. Y un agente no puede hacer una pregunta de seguimiento. No puede escribirle un correo a un usuario para preguntarle qué navegador usaba. Tiene una sola oportunidad con las pruebas.
Así que la disciplina que hace que un reporte sea bueno para una persona es la misma que lo hace útil para una máquina: capturarlo todo, en el momento en que pasa, sin preguntar.
Hacerlo bien trajo una recompensa que no había planeado.
Actualización, octubre de 2026: el acceso por MCP ya está incluido en todos los planes, también en Gratis, y Claude, ChatGPT y VS Code se conectan iniciando sesión. Consulta Cómo conectar Claude, ChatGPT o VS Code a BugDump.
Te puede interesar
Lo que aprendí creando un servidor MCP para una herramienta de desarrollo — siete decisiones de diseño que separan un servidor que el agente usa bien al primer intento de uno con el que se pelea.
Por qué tu agente de IA hace 40 llamadas para responder una pregunta — el problema N+1 trasladado del ORM al servidor MCP, y las tres preguntas que lo resuelven.
Depura reportes de bug de usuarios con Claude Code: el servidor MCP de BugDump — cómo conectar el servidor MCP a Claude Code o Cursor para que tu asistente lea la consola, la red y la repetición de un bug.