Seu agente de IA deveria ler os seus relatórios de bug

MCPDenis Povarov20 de agosto de 2026

Este é um fluxo de trabalho que era normal até pouco tempo atrás.

Chega um relatório de bug. Você abre o painel, lê, encontra o erro do console, copia. Vai para o editor, cola no Claude Code, adiciona algum contexto. O agente pergunta o que a requisição retornou. De volta ao painel, você encontra o log de rede, copia a resposta, cola. E assim por diante.

Você é uma área de transferência. O agente faz o raciocínio, e você faz o transporte de dados entre dois sistemas que poderiam conversar entre si.

Então eu fiz os dois conversarem.

O servidor MCP

O BugDump vem com um servidor Model Context Protocol. Conecte-o ao Claude Code e o agente lê os seus relatórios de bug diretamente. São sete ferramentas:

Ferramenta	Retorna
`get_current_project`	O projeto ao qual esta chave está vinculada
`list_tasks`	Tarefas, para encontrar uma
`get_task`	Uma tarefa, pelo ID público ou pelo ID da tarefa
`get_task_activity`	O histórico de uma tarefa
`list_reports_for_task`	Os relatórios anexados a uma tarefa
`get_report`	Um relatório — console, rede, capturas de tela
`get_report_telemetry`	A telemetria completa, paginada

O fluxo inteiro se reduz a uma frase:

Veja a tarefa #42 no BugDump e corrija.

O agente lê a tarefa, puxa os relatórios anexados, relaciona o erro do console com a requisição que falhou, encontra o código correspondente no seu repositório e propõe uma correção. Você nunca abre o painel.

Por que isso funciona melhor do que colar

O benefício óbvio é que você deixa de ser uma área de transferência. Há dois menos óbvios.

O agente faz perguntas melhores do que você. Quando você copia um stack trace, já decidiu o que é relevante — e decidiu antes de entender o bug. Um agente com acesso direto pode seguir as evidências: ler o console, notar uma requisição que falhou, paginar o log de rede atrás do corpo completo dela, verificar se outros relatórios da mesma tarefa mostram a mesma falha. São muitas consultas pequenas. Cada uma é trivial de atender e tediosa de fazer à mão, e é exatamente por isso que ninguém as faz.

Ele compara relatórios entre si. Pergunte quais navegadores são afetados pela tarefa #17, e o agente lê todos os relatórios anexados e responde. É um trabalho tedioso de verdade — do tipo que quem faz a triagem pula, e do tipo que identifica um bug específico de um navegador em dez segundos, em vez de uma tarde.

As decisões de design

Duas escolhas definiram como isso funciona.

As chaves ficam vinculadas a um projeto para sempre. Nenhuma ferramenta tem parâmetro de projeto. Uma chave MCP recebe o escopo na criação e não pode ser ampliada depois. Quando você entrega uma chave a um agente autônomo, «esta chave só pode ver um projeto, sempre» é uma garantia muito mais forte do que «o agente foi instruído a olhar só um projeto».

As chaves MCP também são somente leitura e separadas das chaves do widget. A chave do seu frontend não consegue ler relatórios; a chave que lê relatórios nunca chega perto de um navegador.

Resumo por padrão, telemetria completa sob demanda. get_report devolve as últimas 50 entradas de console, sem os corpos de rede. Um relatório pode ter milhares de entradas, e despejar tudo isso numa janela de contexto a cada consulta é o caminho para um agente que leu tudo e não entendeu nada.

Mas um truncamento que se esconde é pior do que nenhum truncamento. Por isso o resumo informa o que foi cortado, e get_report_telemetry pagina o histórico completo — console, rede com corpos, ações — em blocos cronológicos até não sobrar nada.

A regra que importa: um resumo que não mostra nada não é prova de que não há nada.

Prompts que funcionam

Veja a tarefa #42 no BugDump e corrija.

O que as tarefas abertas no BugDump têm em comum?

Leia os relatórios da #17 e me diga quais navegadores são afetados.

Confira a tarefa #8 — é o mesmo bug da #3?

Esse último é o meu favorito. Decidir se dois relatórios são o mesmo bug exige comparar dois conjuntos de telemetria em detalhe, que é exatamente o trabalho que todo mundo pula e exatamente o trabalho que mantém tarefas duplicadas fora do seu quadro.

A lição maior

Construí primeiro a camada de captura, porque o problema eram os relatórios de bug incompletos. O servidor MCP não estava nos planos; ficou óbvio depois.

Um relatório completo — console, rede, ações, replay, ambiente — acaba sendo uma entrada bem formada para um agente. E um agente não tem como pedir mais detalhes. Não pode mandar e-mail para o usuário perguntando qual navegador ele usou. Ele tem uma única chance com as evidências.

Ou seja, a disciplina que torna um relatório bom para uma pessoa é a mesma que o torna utilizável por uma máquina: capturar tudo, no momento em que acontece, sem perguntar.

Acertar nisso trouxe um retorno que eu não tinha planejado.

Atualização, outubro de 2026: o acesso via MCP agora está incluído em todos os planos, inclusive no Grátis, e Claude, ChatGPT e VS Code podem se conectar fazendo login — veja Como conectar Claude, ChatGPT ou VS Code ao BugDump.