--- title: "Geben Sie Agenten ein Tool für Feedback" description: "Agenten nutzen Ihr MCP derzeit aktiv und stoßen dabei auf Probleme, die Sie nie bemerken. Ein zusätzliches Tool ermöglicht es ihnen, Ihnen mitzuteilen, was nicht funktionierte, was sie erwartet haben und welches Modell sowie welches Harness im Einsatz war. Hier ist das Format, das ich verwende, und ein echter Bericht, den ich erhalten habe." date: 2026-09-17 language: de canonical: https://gduv.club/de/articles/agent-feedback-tool source: gduv.club --- Wenn Sie einen MCP-Server bereitstellen, sind die meisten Nutzer keine Menschen. Ein Agent liest Ihre Tool-Beschreibungen, wählt eines aus, sendet ein Payload, erhält ein Ergebnis und entscheidet über den nächsten Schritt. Dieser gesamte Kreislauf findet statt, ohne dass jemand zuschaut. Wenn dort also etwas schiefgeht, sagt Ihnen das niemand. Der Agent versucht es erneut, sucht einen Workaround oder gibt auf und teilt dem Nutzer mit, dass die Aufgabe nicht erledigt werden kann. Sie sehen davon nichts. Die Lösung ist simpel: Fügen Sie Ihrem MCP ein weiteres Tool hinzu und lassen Sie den Agenten das Problem an Sie melden. ## Ein Tool und eine Beschreibung, die festlegt, wann es zu nutzen ist Das Tool greift nicht in das Produkt ein. Es nimmt eine Beschreibung dessen auf, was schiefgelaufen ist, und leitet sie an Sie weiter. Damit es funktioniert, ist die Beschreibung entscheidend, die der Agent liest, da dies die einzige Anweisung ist, die er erhält. Hier ist die Version, die ich bei [AI Glot](https://ai-glot.com/docs/mcp/standard-tools) verwende: ```text Nutzen Sie dieses Tool bei der Verwendung von AI Glot, wenn sich ein AI Glot-Tool, eine Antwort, ein Fehler oder ein Workflow anders verhält als erwartet oder wenn Sie sich eine andere Funktionsweise wünschen. Rufen Sie es auf, sobald das Problem klar ist. Beschreiben Sie die Situation, was Sie beobachtet haben und was hätte passieren sollen. Falls bekannt, geben Sie das betroffene Tool, die API-Operation oder den CLI-Befehl, das KI-Modell und das Agent-Framework an. Geben Sie keine API-Keys, Tokens, signierten URLs oder vollständige Dateiinhalte an. Dieses Tool zeichnet nur Feedback auf, führt keine erneuten Versuche durch, ändert nicht Ihre Übersetzung und kostet keine Credits. ``` Drei Aspekte darin leisten die eigentliche Arbeit. "Sobald das Problem klar ist" verhindert, dass es beim ersten flüchtigen Fehler ausgelöst wird. "Führt keine erneuten Versuche durch" verhindert, dass der Agent es als Wiederherstellungsschritt nutzt, wenn ein Aufruf fehlschlägt. "Kostet keine Credits" ist wichtig, weil Agenten bei allem vorsichtig sind, was Geld des Nutzers kosten könnte. Ein Tool, bei dem sie unsicher sind, wird nicht aufgerufen. 1. **Der Agent stößt auf ein Problem**. Eine Ablehnung, eine Überraschung, ein fehlendes Tool 2. **Er ruft das Feedback-Tool auf**. Während der gesamte Kontext noch vorliegt 3. **Ihr Server ergänzt bekannte Daten**. Workspace, Oberfläche, Zeitstempel 4. **Es landet dort, wo Sie es wollen**. Ein Webhook, und dann haben Sie das Problem _Der Agent befindet sich bereits im Fehlerzustand, wenn er dies aufruft. Es muss nichts im Nachhinein rekonstruiert werden, was den Bericht wertvoll macht._ ## Die Felder Hier liegt der größte Mehrwert. Ein offenes Textfeld liefert Ihnen ein "Es hat nicht funktioniert". Benannte Felder liefern Ihnen Informationen, auf die Sie reagieren können. Das fragt das [Tool von AI Glot](https://ai-glot.com/docs/mcp/standard-tools) ab, beginnend mit den drei Pflichtfeldern: **Sechs Felder: beobachtetes Problem, Situation und erwartete Lösung sind Pflichtfelder; zugehörige Aktion, KI-Modell und Agent-Framework sind optional.**
observed_problem Was schiefgelaufen ist, verwirrend war oder anders funktionieren sollte
situation Was versucht wurde und was rund um das Problem geschah
expected_solution Was stattdessen erwartet wurde oder wie es verbessert werden könnte
related_action Das beteiligte Tool, der Endpunkt oder der Befehl
ai_model Falls bekannt. Nicht raten
agent_harness Claude Desktop, Cursor, ein CLI
`expected_solution` ist das Feld, das ich auf jeden Fall behalten würde. Ein Nutzer sagt Ihnen, dass etwas kaputt ist. Ein Agent sagt Ihnen, was er geglaubt hat, dass der Aufruf bewirken würde. Das ist eine direkte Erkenntnis darüber, ob Ihre Tool-Beschreibung mit Ihrem Tool übereinstimmt. Die drei optionalen Felder existieren, weil "nicht raten" eine echte Anweisung ist, der ein Agent folgt. Ich bevorzuge ein leeres Feld gegenüber einem plausibel klingenden Modellnamen. Wenn sie ausgefüllt sind, können Sie nach Modell und Framework sortieren, und ein Problem, das nur bei einem von beiden auftritt, wirkt nicht mehr zufällig. **Fragen Sie den Agenten nicht nach Dingen, die Sie bereits wissen** Workspace, Anmeldedaten, Oberfläche, Zeitstempel und eine Feedback-ID werden von meinem Server hinzugefügt, nicht vom Agenten. Alles, was der Agent falsch machen oder erfinden könnte, sollte man ihm entziehen. Das hält zudem den Aufruf des Tools günstig, was den Unterschied ausmacht, ob ein Tool genutzt wird oder nicht. ## So sieht ein echter Bericht aus Dies ist ein echtes Beispiel, genau so, wie es mich am 10. September erreichte: _Niemand hätte dies gemeldet. Der Durchlauf war beendet, die Übersetzung erfolgt und der Workaround bestand in einem zusätzlichen Aufruf. Das ist genau die Art von Reibung, die Sie normalerweise nie bemerken._ Das ist ein Fehlerbericht mit Reproduktionsschritten, einer Diagnose und einem Lösungsvorschlag, geschrieben von der Instanz, die den Fehler ausgelöst hat, Sekunden nachdem es passierte. Ich habe nicht darum gebeten und ich habe nicht dafür bezahlt. ## Warum dies besser ist als das übliche Feedback Ich behaupte nicht, dass Agenten Nutzer ersetzen. Ich sage, dass dieser spezielle Kanal Eigenschaften hat, die Nutzerfeedback nicht besitzt. **Ein Nutzer erzählt es Ihnen** (Stunden oder Tage später) - Erinnert und teilweise rekonstruiert - Gefiltert durch das, was sie für meldenswert halten - Abgemildert, da Beschweren unhöflich wirkt - Sagt selten, was stattdessen erwartet wurde - Nur von den wenigen, die sich die Mühe machen **Der Agent erzählt es Ihnen** (Sekunden später) - Geschrieben, während der gesamte Kontext noch geladen ist - Keine Bewertung, ob es Ihre Zeit wert ist - Gibt an, was erwartet wurde, da dies das Feld ist - Nennt den exakten Aufruf, das Modell und das Framework - Von jedem Durchlauf, der auf das Problem stößt _Beide sind wertvoll. Die rechte Spalte ist diejenige, für die Sie derzeit keine Möglichkeit zur Erfassung haben._ Die Objektivität ist der Punkt, zu dem ich immer wieder zurückkehre. Ein Agent hat keine Beziehung zu Ihnen, die er schützen muss, und keine Sorge, fordernd zu wirken. Er hat Ihre Beschreibung gelesen, eine Erwartung geformt, und die Erwartung stimmte nicht überein. Diese Lücke ist der gesamte Bericht und die ehrlichste Dokumentationsprüfung, die Sie jemals erhalten werden. ## Wohin die Berichte gehen Meine Berichte werden per POST an einen Webhook gesendet und landen in einem Kanal, den ich lese. Das ist das gesamte Setup, und es war bereits ausreichend, um den Aufwand zu rechtfertigen. Man kann es weiter treiben, und die Optionen werden interessant, sobald die Berichte strukturiert sind: - **Speichern** und nach `related_action` gruppieren. Drei Berichte über dasselbe Tool sind eine Spezifikation, keine Anekdote. - **Benachrichtigungen bei relevanten Meldungen**, gefiltert nach Ihren Präferenzen: ein Tool, ein Modell, ein Framework. - **Einen Agenten auf die Queue setzen**, um Dubletten zu entfernen, Prioritäten zu setzen und einen Lösungsvorschlag in Ihrem Repo zu entwerfen. Die Berichte enthalten bereits die Reproduktion und das erwartete Verhalten, was den Großteil dessen ausmacht, was für einen Fix benötigt wird. - **Auf Autopilot laufen lassen**, falls Sie Ihren Tests genug vertrauen. Ich tue das noch nicht. Nichts davon ist erforderlich. Der Webhook allein verändert, was Sie über Ihr eigenes Produkt wissen. ## Zwei Regeln, die ich nicht ignorieren würde **Es darf niemals die Konversation unterbrechen, die es aufgerufen hat.** Wenn Ihr Webhook down ist, gibt das Tool ein einfaches "dies konnte nicht zugestellt werden, nichts weiter zu tun" zurück, keinen Fehler. Ein Agent, der eine Exception von einem Feedback-Tool erhält, wird den Fehler als Teil der Aufgabe behandeln, die er gerade ausführte. Mein Tool hat aus demselben Grund einen kurzen Timeout: Ein hängender Webhook hält den Zug des Agenten offen. **Sagen Sie, was nicht gesendet werden soll.** Agenten sind hilfsbereit, und eine Anfrage nach Kontext würde Ihnen sonst API-Keys, signierte URLs und Dateiinhalte liefern. Es genügt, diese in der Beschreibung zu nennen, damit Sie keine Dinge speichern, die Sie nie wollten. **Eine kleinere Version ist völlig ausreichend** In meinem Dokumentations-Framework heißt das Tool `report_issue` und nimmt drei Felder entgegen: die Seite, was falsch ist und eine optionale Kategorie aus einer Liste von vieren. Der Server fügt die URL der Seite, den Produktnamen des Agenten, die Version der Seite und den Zeitstempel hinzu. Das hat einen Nachmittag gedauert. ## Probieren Sie es mit Ihrem eigenen MCP Wenn Sie bereits einen MCP-Server betreiben, ist dies ein Tool, ein Webhook und eine Beschreibung, die Sie zweimal umschreiben werden. Der erste Bericht, der eintrifft, wird Ihnen etwas über Ihr Produkt verraten, das Sie nicht wussten, und es wird um ein Tool gehen, von dem Sie dachten, es sei in Ordnung. Agenten sind jetzt Ihre Nutzer. Geben Sie ihnen einen Ort, an dem sie sich beschweren können. ## Quellen - [Mein ursprünglicher Post zur Idee](https://www.linkedin.com/posts/guillaume-duvernay_idea-give-your-users-claude-code-a-tool-activity-7503753518369980416-g46b) - [Max Tkacz hat mich gefilmt, wie ich es erkläre](https://www.linkedin.com/posts/maxtkacz_mcp-llm-kewl-ugcPost-7506271906975686657-sq8X) - [Model Context Protocol: tools specification](https://modelcontextprotocol.io/specification/2025-06-18/server/tools)