FinMCP-Bench: Benchmarking von LLM-Agenten für den realen Einsatz von Finanz-Tools unter MCP

MCP hat sich zum De-facto-Verbindungsstandard für die LLM-Tool-Nutzung entwickelt – Anthropic führte es Ende 2024 ein, und bis Anfang 2026 hatten alle wichtigen Modellanbieter es übernommen. FinMCP-Bench (arXiv:2603.24943, ICASSP 2026) ist der erste Benchmark, der auf echten MCP-Tool-Servern speziell für Finanz-Agenten aufbaut. Er kommt genau zum richtigen Zeitpunkt, um uns zu sagen, ob diese standardisierte Infrastruktur den Agenten tatsächlich hilft, nützliche Finanzarbeit zu leisten.

Das Paper

Jie Zhu, Yimin Tian und Kollegen vom Alibaba Cloud Qwen DianJin Team, YINGMI Wealth Management und der Soochow University präsentieren FinMCP-Bench, eine Evaluations-Suite mit 613 Proben, die 10 Kategorien von Finanzszenarien und 33 Unter-Szenarien abdeckt. Die Tools sind nicht bloß simuliert – 65 echte MCP-konforme Finanz-Tool-Server bilden das Rückgrat des Benchmarks, basierend auf realen Produktionslogs des Finanzassistenten der Qieman-App. Die Autoren kategorisieren die Proben in drei Typen: 145 Single-Tool-, 249 Multi-Tool- und 219 Multi-Turn-Aufgaben. Sie testen sechs Modelle: die Qwen3-Familie mit 4B, 30B und 235B Parametern (alle mit "Extended Thinking"), dazu DeepSeek-R1, GPT-OSS-20B und Seed-OSS-36B. Die zentralen Evaluationsmetriken sind Tool-Präzision, Tool-Recall, Tool-F1 und eine Exact Match Rate (EMR), die voraussetzt, dass jeder Tool-Aufruf in einer Sequenz exakt korrekt ist.

Kernideen

• MCP als Evaluationsgrundlage: Die Verwendung echter MCP-Serverdefinitionen anstelle synthetischer API-Schemas schließt eine große Lücke zwischen der Benchmark-Evaluierung und dem, womit Agenten in real eingesetzten Finanzsystemen tatsächlich konfrontiert sind.
• Dreifache Schwierigkeitsabstufung: Single-Tool-, Multi-Tool- und Multi-Turn-Proben weisen nicht nur quantitative Unterschiede auf – sie legen qualitativ unterschiedliche Fehlermodi offen.
• Multi-Turn-Kollaps: Das beste Modell (Qwen3-235B) erreicht 60 % EMR bei Single-Tool-, 10,62 % EMR bei Multi-Tool- und 3,08 % EMR bei Multi-Turn-Aufgaben. Der Abfall von Single-Tool zu Multi-Turn ist 20-fach.
• Tool-F1 ist nachsichtiger: Dasselbe Modell erreicht 66,85 %, 69,42 % und 41,56 % TF1 über die drei Einstellungen hinweg – was zeigt, dass Modelle oft die richtigen Tools finden, aber bei der Reihenfolge, Parametrisierung oder Gesprächsverfolgung scheitern.
• Recall schlägt Präzision bei Single-Tool: Modelle neigen dazu, bei Unsicherheit eher zu viele Tools aufzurufen als zu wenige. Dies ist der sicherere Fehlermodus für Finanzaufgaben, bedeutet aber dennoch verschwendete API-Aufrufe und Rauschen in der Argumentationskette.
• Nicht-monotone Skalierung nach Größe: Qwen3-30B übertrifft Qwen3-4B nicht konsistent in allen Unter-Szenarien, was die Annahme widerlegt, dass größere Modelle bei mehrstufiger Tool-Nutzung immer gewinnen.

Was Bestand hat – und was nicht

Die Verwendung echter Produktionslogs als Quelle für Single-Tool-Beispiele ist die methodisch stärkste Entscheidung hier. Sie verankert den Benchmark im tatsächlichen Nutzerverhalten anstatt in von Forschern erfundenen Szenarien, was in der Literatur zu Finanz-KI selten ist. Die Multi-Tool- und Multi-Turn-Proben wurden synthetisch mithilfe von Abhängigkeitsgraphen und Rollenspiel-Prompts erweitert, was angesichts der Labeling-Kosten angemessen ist, aber ein Risiko birgt: Der Syntheseprozess neigt dazu, sauberere und eindeutigere Anfragen zu erzeugen, als sie echte Nutzer schreiben würden. Die 3,08 % EMR bei Multi-Turn-Aufgaben sind alarmierend, sollten aber vorsichtig interpretiert werden – EMR erfordert, dass die komplette Sequenz exakt korrekt ist, sodass ein einziger falscher Zwischenaufruf die gesamte Aufgabe scheitern lässt. Das ist ein strenger und wohl unrealistischer Produktionsstandard; Metriken mit Teilwertung wie TF1 erzählen eine differenziertere Geschichte.

Was das Paper nicht anspricht: Es gibt keine Analyse darüber, ob die Leistungslücke primär ein Problem des Eingabeverständnisses ist (das Modell interpretiert die Benutzerabsicht falsch), ein Problem der Ausgabeformatierung (korrekte Absicht, aber fehlerhafter Tool-Aufruf) oder ein Problem der Logik (falsche Zwischenschlüsse). Ohne diese Aufschlüsselung ist es schwer zu wissen, wo Engineering-Aufwand investiert werden sollte. Das Paper evaluiert Modelle zudem isoliert; es gibt keinen Test, ob das Hinzufügen eines Verifizierungs- oder Reflexionsschritts das Multi-Turn-Bild verändert.

Der Benchmark ist zudem tief an die spezifischen 65 Tools von Qieman gebunden, was die Übertragbarkeit der Ergebnisse auf andere Finanzplattformen mit anderem Tool-Inventar einschränkt.

Warum dies für Finanz-KI wichtig ist

FinMCP-Bench ist die am nächsten an der Realität liegende veröffentlichte Evaluation dessen, was ein Beancount-Agent mit Schreibzugriff tatsächlich tun würde: eine Benutzeranfrage empfangen, das passende Tool (oder eine Kette von Tools) identifizieren, diese der Reihe nach aufrufen und Folgeschritte bearbeiten. Die Multi-Turn-EMR von 3,08 % ist ein ernüchternder Realitätscheck. Ein Beancount-Agent, der eine mehrstufige Journal-Korrektur verwaltet – zum Beispiel die Umklassifizierung einer Reihe von Transaktionen über Konten hinweg innerhalb eines Datumsbereichs, gefolgt von einer Abstimmung und dem Erstellen eines Berichts – ist genau die Art von Multi-Turn-, Multi-Tool-Aufgabe, an der aktuelle Modelle nach Exact-Match-Standards fast universell scheitern.

Das MCP-Framework ist hierbei direkt relevant: Die Python-API von Beancount, die beanquery-Schnittstelle und die REST-Ebene von Fava könnten alle als MCP-Server gekapselt werden. FinMCP-Bench zeigt uns, dass nicht das Protokoll der Flaschenhals ist – sondern die Logik über Tool-Aufrufsequenzen hinweg.

Die Erkenntnis, dass der Tool-Recall die Präzision übersteigt (Modelle rufen zu viele Tools auf), ist auch für die Sicherheit bei Schreibvorgängen wichtig: Ein Agent, der ein Tool zur Journal-Mutation aufruft, wenn eigentlich nur ein Lesezugriff nötig war, könnte das Journal unbemerkt korrumpieren. Präzisionsorientierte Evaluationsmetriken, nicht Recall-orientierte, sollten daher das primäre Sicherheitssignal für schreibende Agenten sein.

Was Sie als Nächstes lesen sollten

• JSONSchemaBench (arXiv:2501.10868) – evaluiert die Zuverlässigkeit strukturierter Ausgaben über 10.000 JSON-Schemas hinweg; befasst sich direkt mit der Frage, ob Fehler bei der Tool-Aufruf-Formatierung in FinMCP-Bench ein Problem des eingeschränkten Dekodierens (Constrained Decoding) sind.
• ToolLLM (arXiv:2307.16789, ICLR 2024) – das grundlegende Trainings-Framework für Tool-Nutzung, gegenüber dem sich FinMCP-Bench positioniert; das Verständnis seiner Tiefensuche-Baumexploration verdeutlicht, was die Produktionslog-Methodik von FinMCP-Bench ergänzt.
• WildToolBench (arXiv:2604.06185) – evaluiert die Tool-Nutzung anhand realer Benutzeranfragen aus der Praxis; die Erkenntnis, dass kein Modell eine Genauigkeit von mehr als 15 % bei realem Nutzerverhalten erreicht, ergänzt den Produktionslog-Ansatz von FinMCP-Bench.