Gib Agenten ein Tool, um dir Feedback zu senden
Wenn du einen MCP-Server veröffentlichst, sind die meisten Nutzer keine Menschen. Ein Agent liest deine Tool-Beschreibungen, wählt ein Tool aus, sendet eine Nutzlast, erhält ein Ergebnis und entscheidet, was als Nächstes zu tun ist. Dieser ganze Ablauf findet statt, ohne dass jemand zusieht.
Wenn dabei etwas schiefgeht, erfährst du also nichts davon. Der Agent versucht es erneut, findet einen Umweg oder gibt auf und sagt seinem Nutzer, dass sich die Aufgabe nicht erledigen lässt. Du bekommst nichts davon mit.
Die Lösung ist einfach: Füge deinem MCP ein weiteres Tool hinzu, über das der Agent dir das Problem melden kann.
Ein Tool mit einer Beschreibung, die den richtigen Einsatz erklärt
Das Tool verändert das Produkt nicht. Es nimmt eine Beschreibung des Problems entgegen und leitet sie an dich weiter. Entscheidend ist die Beschreibung, die der Agent liest, denn sie ist seine einzige Anweisung.
Hier ist das Tool, das ich bei AI Glot verwende:
Verwende dieses Tool bei der Nutzung von AI Glot, wenn sich ein AI Glot-Tool,
eine Antwort, ein Fehler oder ein Workflow anders verhält als erwartet oder du
dir wünschst, dass etwas anders funktioniert. Rufe es auf, sobald das Problem
klar ist. Beschreibe die Situation, was du beobachtet hast und was hätte
passieren sollen. Gib, sofern bekannt, das betreffende Tool, den API-Aufruf
oder CLI-Befehl, das KI-Modell und das Agenten-Harness an. Füge keine API-
Schlüssel, Tokens, signierten URLs oder vollständigen Dateiinhalte ein. Dieses
Tool erfasst nur Feedback, wiederholt den Vorgang nicht und ändert deine
Übersetzung nicht. Es kostet keine Credits.Drei Formulierungen darin erfüllen einen wichtigen Zweck. „Sobald das Problem klar ist“ verhindert, dass das Tool schon beim ersten vorübergehenden Fehler aufgerufen wird. „Wiederholt den Vorgang nicht“ hält den Agenten davon ab, das Tool als Wiederherstellungsmaßnahme zu verwenden, wenn ein Aufruf fehlschlägt. „Kostet keine Credits“ ist wichtig, weil Agenten bei allem vorsichtig sind, was Geld kosten könnte. Und ein Tool, bei dem sie unsicher sind, wird nicht aufgerufen.
- 1Der Agent stößt auf ein ProblemEine Ablehnung, eine Überraschung, ein fehlendes Tool
- 2Er ruft das Feedback-Tool aufDer gesamte Kontext liegt noch vor
- 3Dein Server ergänzt bekannte InformationenArbeitsbereich, Oberfläche, Zeitstempel
- 4Der Bericht landet am gewünschten OrtEin Webhook, und dann liegt es an dir
Die Felder
Hier steckt der größte Teil des Nutzens. Ein freies Textfeld liefert dir „Es hat nicht funktioniert“. Benannte Felder liefern dir Informationen, mit denen du etwas anfangen kannst.
Das fragt das Tool von AI Glot ab, zuerst die drei Pflichtfelder:
expected_solution würde ich behalten, wenn ich nur ein Feld haben könnte. Ein Nutzer sagt dir, dass etwas kaputt ist. Ein Agent sagt dir, was der Aufruf seiner Erwartung nach tun sollte. Daran erkennst du direkt, ob deine Toolbeschreibung zum Tool passt.
Die drei optionalen Felder gibt es, weil „nicht raten“ eine echte Anweisung ist, an die sich ein Agent hält. Mir ist das Feld lieber leer, als mit einem plausiblen Modellnamen ausgefüllt. Sind die Felder ausgefüllt, kannst du nach Modell und Harness sortieren. Ein Problem, das nur bei einem davon auftritt, wirkt dann nicht mehr zufällig.
So sieht ein echter Bericht aus
Das ist ein echter Bericht, genau so, wie er mich am 10 September erreicht hat:
Das ist ein Fehlerbericht mit Reproduktion, Diagnose und Lösungsvorschlag, verfasst von demjenigen, der auf das Problem gestoßen ist, nur Sekunden danach. Ich habe nicht darum gebeten und nichts dafür bezahlt.
Warum das besser ist als das Feedback, das du sonst bekommst
Ich sage nicht, dass Agenten Nutzer ersetzen. Ich sage, dass dieser spezielle Feedbackkanal Eigenschaften hat, die Nutzerfeedback nicht bietet.
Was ein Nutzer dir sagtStunden oder Tage später
- Aus der Erinnerung, teilweise rekonstruiert
- Gefiltert danach, was der Nutzer für erwähnenswert hält
- Abgeschwächt, weil sich Beschweren unhöflich anfühlt
- Sagt selten, was stattdessen erwartet wurde
- Nur von den wenigen, die sich die Mühe machen
Was der Agent dir sagtSekunden später
- Verfasst, solange der gesamte Kontext noch präsent ist
- Keine Einschätzung, ob es deine Zeit wert ist
- Nennt die Erwartung, weil dafür ein eigenes Feld vorgesehen ist
- Gibt den genauen Aufruf, das Modell und das Harness an
- Von jedem Durchlauf, bei dem das Problem auftritt
Der unvoreingenommene Blick ist der Punkt, auf den ich immer wieder zurückkomme. Ein Agent hat keine Beziehung zu dir, die er schützen muss, und keine Sorge, anspruchsvoll zu wirken. Er hat deine Beschreibung gelesen, eine Erwartung gebildet und festgestellt, dass sie nicht erfüllt wurde. Diese Lücke ist der ganze Bericht und die ehrlichste Prüfung deiner Dokumentation, die du je bekommen wirst.
Wohin die Berichte gehen
Meine werden per POST an einen Webhook gesendet und landen in einem Kanal, den ich lese. Das ist die ganze Einrichtung, und sie hat sich schon gelohnt.
Du kannst noch mehr daraus machen. Sobald die Berichte strukturiert sind, werden die Möglichkeiten interessant:
- Speichere sie und gruppiere sie nach
related_action. Drei Berichte zum selben Tool sind eine Spezifikation, keine Anekdote. - Lass dich bei wichtigen Berichten benachrichtigen, gefiltert nach dem, was dich interessiert: ein Tool, ein Modell oder ein Harness.
- Setze einen Agenten auf die Warteschlange, damit er Duplikate zusammenführt, priorisiert und einen Lösungsvorschlag für dein Repo entwirft. Die Berichte enthalten bereits eine Reproduktion und das erwartete Verhalten, also fast alles, was für eine Korrektur nötig ist.
- Lass den Ablauf automatisch laufen, wenn du deinen Tests genug vertraust. Ich tue das noch nicht.
Nichts davon ist erforderlich. Schon der Webhook allein verändert, was du über dein eigenes Produkt weißt.
Zwei Regeln, die ich nicht übergehen würde
Das Tool darf niemals das Gespräch unterbrechen, in dem es aufgerufen wurde. Wenn dein Webhook nicht erreichbar ist, gibt das Tool schlicht zurück: „Die Übermittlung war nicht möglich, es ist nichts weiter zu tun“, statt einen Fehler auszugeben. Bekommt ein Agent von einem Feedback-Tool eine Ausnahme, behandelt er den Fehler womöglich als Teil seiner aktuellen Aufgabe. Aus demselben Grund hat mein Tool auch ein kurzes Timeout: Ein hängender Webhook hält den Agenten in seinem Zug fest.
Sag, was nicht gesendet werden soll. Agenten helfen gern. Bittest du sie um Kontext, senden sie dir sonst API-Schlüssel, signierte URLs und Dateiinhalte. Es reicht, diese Dinge in der Beschreibung zu nennen. So speicherst du nichts, was du nie haben wolltest.
Auf deinem eigenen MCP ausprobieren
Wenn du bereits einen MCP-Server betreibst, brauchst du dafür ein Tool, einen Webhook und eine Beschreibung, die du zweimal überarbeitest. Der erste eingehende Bericht verrät dir etwas über dein Produkt, das du noch nicht wusstest, und es geht um ein Tool, von dem du dachtest, es sei in Ordnung.
Als die ersten Produktionsberichte eintrafen, entwickelte ich eine zweite Hälfte, die vor dem Release denselben Ablauf durchführt: Für einen halben Cent pro Durchlauf werden für jede Oberfläche neue Agents ohne jeglichen Kontext gestartet. Den gesamten Aufbau habe ich dokumentiert und das Test-Framework als Open Source veröffentlicht: So veröffentlicht man MCPs mit 10/10.
Agenten sind jetzt deine Nutzer. Gib ihnen einen Ort, an dem sie sich beschweren können.