Tool-Use-Review
Aktualisiert am
Deployment-Urteil
Bedingt deploy, weil die Tool-Ausführung stark ist und die Calls valide sind, aber die erkannte Halluzination unter Fehlerbedingungen das Vertrauen in eine produktive Tool-Pipeline begrenzt.
Tool-Execution-Profil
Claude Sonnet 4.5 zeigt ein belastbares Tool-Use-Fundament. Mit P1 90 produziert es valide MCP-Calls und brauchte keinen Retry, also weder Formatkorrektur noch erneute Steuerung. Das ist für produktive Orchestrierung ein gutes Signal. Beim Test Web Search & Tool Selection, der prüft, ob ohne Hinweis das passende Werkzeug gewählt wird, erkennt das Modell klar, dass web_search statt fetch nötig ist. Das spricht gegen bloßes Musterfolgen und für echte Werkzeugwahl. Beim URL-Construction-Test, der die Ableitung einer Ziel-URL aus Vorwissen und den anschließenden Fetch misst, bleibt es brauchbar, aber nicht deterministisch genug für enge Pipelines. Insgesamt ist das Modell in der Werkzeugschicht verlässlich, aber nicht fehlerfrei in der letzten Präzisionsmeile.
Synthesetreue
Wie gut verdichtet es Tool-Ergebnisse? Hier liegt die eigentliche Schwäche. P2 50.83 ist für ein Server-Modell nur ausreichend. Besonders auffällig sind die Einbrüche bei Web Search & Tool Selection, Tool Failure Handling (404) und vor allem Multilingual Search & Synthesis. Das Modell beschafft Informationen, verdichtet sie aber nicht durchgehend präzise, priorisiert nicht immer sauber und hält den Antwortkern nicht stabil genug.
Bleibt es im Tool-Ergebnis oder weicht es auf Training aus? Im Honeypot EU License Research, der prüft, ob aktuelle Lizenzrestriktionen wirklich aus Web-Quellen stammen, bleibt das Modell im beschafften Material. P2 60 ist nicht stark, aber der Vertrauensbefund ist positiv: Content-Verification-State A, keine Halluzination. Das ist wichtig. Gleichzeitig gilt: Die insgesamt erkannte Halluzination ist ein Sicherheitsrisiko, nicht nur ein Qualitätsmangel. Wenn ein Modell erfundene Inhalte als Tool-Ergebnis ausgibt, beschädigt es die Verlässlichkeit der gesamten Infrastruktur.
Fehlerresilienz
Hier liegt der produktionskritische Punkt. Im 404-Test, der transparente Reaktion auf einen gescheiterten Tool-Call prüft, halluziniert das Modell trotz Fehlers Seiteninhalt. P2 35 ist dafür nur der Begleitwert. Der eigentliche Befund lautet: Es ersetzt fehlende Evidenz nicht konsequent durch klare Fehlerkommunikation. Für Produktion ist das ohne Ausnahme kritisch. Ein Tool-Fehler muss als Tool-Fehler sichtbar bleiben.
Betriebsprofil
Call 1: 2.24s. MCP-Latenz: 0.74s. Call 2: 8.38s. Total: 68.11s.
Kosten pro Run: $0.064233.
Latenz: eher langsam im Gesamtlauf. Kosten: moderat bis gehoben. Leistung: gute Tool-Ausführung, aber zu schwache Synthesetreue für den Preis.
Fazit & Empfehlung
Geeignet für MCP-Pipelines mit starker externer Validierung, klaren Guardrails und nachgelagerter Ergebnisprüfung, besonders wenn Werkzeugwahl und mehrstufige Ausführung wichtiger sind als knappe, belastbare Verdichtung. Nicht geeignet für Compliance-, Retrieval- oder Incident-Workflows, in denen ein Tool-Fehler strikt transparent bleiben muss und erfundener Ersatzinhalt unzulässig ist. Für autonome Agenten nur dann vertretbar, wenn Fehlerpfade hart abgefangen und Antworten gegen Tool-Rohdaten verifiziert werden.
Diese Auswertung wurde automatisch auf Grundlage der Benchmark-Daten generiert. Eingesetztes Modell: GPT 4.5 von OpenAI. Die Rohdaten und die vollständige Methodik sind im GitHub-Projekt dokumentiert.
