Dein KI-Agent sollte deine Fehlerberichte lesen

MCPDenis Povarov20. August 2026

Hier ist ein Ablauf, der bis vor Kurzem normal war.

Ein Fehlerbericht kommt rein. Du öffnest das Dashboard, liest ihn, findest den Console-Fehler, kopierst ihn. Du wechselst in den Editor, fügst ihn in Claude Code ein, ergänzt etwas Kontext. Der Agent fragt, was der Request zurückgegeben hat. Zurück ins Dashboard, das Netzwerk-Log suchen, die Response kopieren, einfügen. Und so weiter.

Du bist eine Zwischenablage. Der Agent denkt nach, und du transportierst Daten zwischen zwei Systemen, die miteinander reden könnten.

Also habe ich sie miteinander reden lassen.

Der MCP-Server

BugDump bringt einen Server für das Model Context Protocol mit. Verbinde ihn mit Claude Code, und der Agent liest deine Fehlerberichte direkt. Sieben Tools:

Tool	Liefert
`get_current_project`	Das Projekt, an das dieser Schlüssel gebunden ist
`list_tasks`	Aufgaben, um eine bestimmte zu finden
`get_task`	Eine Aufgabe, per öffentlicher ID oder Aufgaben-ID
`get_task_activity`	Den Verlauf einer Aufgabe
`list_reports_for_task`	Die Berichte, die an einer Aufgabe hängen
`get_report`	Einen Bericht: Console, Netzwerk, Screenshots
`get_report_telemetry`	Die komplette Telemetrie, seitenweise

Der ganze Ablauf schrumpft auf einen Satz:

Schau dir Aufgabe #42 in BugDump an und behebe sie.

Der Agent liest die Aufgabe, holt die angehängten Berichte, bringt den Console-Fehler mit dem fehlgeschlagenen Request zusammen, findet den passenden Code in deinem Repo und schlägt einen Fix vor. Das Dashboard öffnest du nie.

Warum das besser funktioniert als Einfügen

Der offensichtliche Vorteil: Du bist keine Zwischenablage mehr. Es gibt zwei weniger offensichtliche.

Der Agent stellt bessere Fragen als du. Wenn du einen Stack-Trace kopierst, hast du schon entschieden, was relevant ist, und zwar bevor du den Bug verstanden hast. Ein Agent mit direktem Zugriff kann den Belegen folgen: die Console lesen, einen fehlgeschlagenen Request bemerken, im Netzwerk-Log zu dessen vollständigem Body blättern, prüfen, ob andere Berichte zur selben Aufgabe denselben Fehler zeigen. Das sind viele kleine Abfragen. Jede ist für den Server trivial und von Hand mühsam, und genau deshalb macht sie niemand.

Er kann Berichte miteinander vergleichen. Frag, welche Browser von Aufgabe #17 betroffen sind, und der Agent liest jeden angehängten Bericht und sagt es dir. Das ist wirklich mühsame Arbeit, die Menschen bei der Triage gern überspringen, und genau die Arbeit, die einen Bug in zehn Sekunden statt an einem Nachmittag als browserspezifisch entlarvt.

Die Designentscheidungen

Zwei Entscheidungen haben geprägt, wie das funktioniert.

Schlüssel sind dauerhaft an ein Projekt gebunden. Kein Tool hat einen Projekt-Parameter. Ein MCP-Schlüssel bekommt seinen Scope beim Anlegen, und der lässt sich danach nicht erweitern. Wenn du einem autonomen Agenten einen Schlüssel gibst, ist „dieser Schlüssel kann immer nur ein Projekt sehen“ eine viel stärkere Garantie als „dem Agenten wurde gesagt, nur in ein Projekt zu schauen“.

MCP-Schlüssel sind außerdem reine Lese-Schlüssel und von den Widget-Schlüsseln getrennt. Der Schlüssel in deinem Frontend kann keine Berichte lesen, und der Schlüssel, der Berichte liest, kommt nie in die Nähe eines Browsers.

Standardmäßig eine Zusammenfassung, die volle Telemetrie auf Anfrage. get_report liefert die letzten 50 Console-Einträge, ohne Netzwerk-Bodys. Ein Bericht kann Tausende Einträge enthalten, und wer bei jeder Abfrage alles in ein Kontextfenster kippt, landet bei einem Agenten, der alles gelesen und nichts verstanden hat.

Aber eine Kürzung, die sich versteckt, ist schlimmer als gar keine. Deshalb sagt die Zusammenfassung, was gekürzt wurde, und get_report_telemetry blättert in chronologischen Abschnitten durch den kompletten Verlauf, mit Console, Netzwerk samt Bodys und Interaktionen, bis nichts mehr übrig ist.

Die Regel, auf die es ankommt: Eine Zusammenfassung, die nichts zeigt, beweist nicht, dass da nichts ist.

Prompts, die funktionieren

Schau dir Aufgabe #42 in BugDump an und behebe sie.

Was haben die offenen Aufgaben in BugDump gemeinsam?

Lies die Berichte zu #17 und sag mir, welche Browser betroffen sind.

Schau dir Aufgabe #8 an: Ist das derselbe Bug wie #3?

Der letzte ist mein Lieblings-Prompt. Ob zwei Berichte derselbe Bug sind, lässt sich nur entscheiden, wenn man zwei Sätze Telemetrie im Detail vergleicht. Genau diese Arbeit lassen alle aus, und genau sie hält doppelte Aufgaben von deinem Board fern.

Der größere Zusammenhang

Ich habe zuerst die Capture-Schicht gebaut, weil unvollständige Fehlerberichte das Problem waren. Der MCP-Server war nicht geplant, er lag erst danach auf der Hand.

Ein vollständiger Bericht mit Console, Netzwerk, Interaktionen, Replay und Umgebung ist, wie sich herausstellt, ein sauber strukturierter Input für einen Agenten. Und ein Agent kann nicht nachfragen. Er kann niemandem eine E-Mail schreiben und fragen, welcher Browser es war. Er hat genau einen Versuch mit den Belegen.

Die Disziplin, die einen Bericht für einen Menschen gut macht, ist also dieselbe, die ihn für eine Maschine brauchbar macht: alles erfassen, in dem Moment, in dem es passiert, ohne zu fragen.

Das richtig hinzubekommen, hat sich auf eine Weise ausgezahlt, die ich nie geplant hatte.

Update, Oktober 2026: Der MCP-Zugang ist jetzt in jedem Plan enthalten, auch im kostenlosen, und Claude, ChatGPT und VS Code verbinden sich per Anmeldung. Siehe Claude, ChatGPT oder VS Code mit BugDump verbinden.