Fallstudie · Automatisierung im Kundensupport

Der Support-Agent verbrauchte mehr Kontext für Tool-Definitionen als für das Ticket.

Der KI-Agent eines Support-Teams war mit einem Dutzend MCP-Server verbunden und ertränkte jeden Prompt in Tool-Schemata. Der Wechsel zum Code Mode von onemcp gab den Kontext dem Problem des Kunden zurück — und senkte Kosten und Latenz je Antwort.

Branche: SaaS-Kundensupport
Team: Support-Organisation von ~15 Personen
Tech-Stack: Zendesk · Stripe · Postgres · interne Bestell-API · Slack

# Überblick

Tool-Overhead pro Anfrage um rund 90 % gesenkt
Tool-Schema pro Aufruf von ~15.000 auf ~500 Tokens
Geringere Kosten und Latenz bei jeder Antwort

Illustratives Szenario, angelehnt an gängige onemcp-Bereitstellungen. Das Team ist eine Komposition und kein namentlich genannter Kunde; die Zahlen sind repräsentativ, nicht gemessen.

Hintergrund

Ein SaaS-Support-Team hatte einen KI-Agenten gebaut, um Tickets zu sichten und zu beantworten. Um echte Arbeit zu leisten, brauchte er Reichweite: Zendesk für das Ticket, Stripe für die Zahlung, Postgres und eine interne Bestell-API für den Kontostand und Slack für die Eskalation. Jedes davon war ein MCP-Server, direkt in den Agenten verdrahtet.

Der Agent war vom ersten Tag an nützlich. Er war zugleich langsam und teuer auf eine Weise, die das Team nicht ganz erklären konnte — bis es untersuchte, was tatsächlich in jedem Prompt steckte.

Die Herausforderung

Jeder MCP-Server, mit dem sich der Agent verband, spielte bei jeder Anfrage sein gesamtes Tool-Schema in den Kontext ein. Mit einem Dutzend verbundener Server bedeutete das Hunderte von Tool- und Parameterdefinitionen, die jedes Ticket begleiteten — ob das aktuelle Ticket sie brauchte oder nicht.

Die Kosten zeigten sich auf dreierlei Weise:

Verschwendeter Kontext. Rund 15.000 Tokens an Tool-Textbausteinen standen in jedem Prompt vor der eigentlichen Frage des Kunden. In langen Threads verdrängten die Definitionen die Konversation selbst.
Höhere Kosten und Latenz. Diese Eingabe-Tokens wurden in jeder Runde bezahlt und verarbeitet, multipliziert über Tausende Tickets pro Woche.
Mehr Raum für Fehler. Ein größerer, verrauschter Prompt gab dem Modell mehr Gelegenheiten, das falsche Werkzeug zu wählen oder in einem mehrstufigen Ticket den Faden zu verlieren.

Der Ansatz

Das Team stellte sämtliche Server des Agenten hinter ein einziges onemcp-Portal und ließ den Agenten über den Code Mode mit ihm sprechen.

Statt jede Definition vorab zu laden, stellt das Portal drei Meta-Tools bereit:

search — die für das vorliegende Ticket relevanten Werkzeuge finden.
describe — die genaue Signatur eben dieser Werkzeuge bei Bedarf abrufen.
execute — ein kurzes Skript ausführen, das sie aufruft, in einem einzigen Roundtrip.

So lädt ein Erstattungsticket die Stripe- und Bestell-Werkzeuge, die es braucht, und nichts sonst. Der vollständige Katalog bleibt verfügbar — er wird nur nicht mehr in jeden Prompt gezerrt.

Die Ergebnisse

Rund 90 % weniger Tool-Overhead pro Anfrage. Das Tool-Schema pro Aufruf sank von etwa 15.000 auf rund 500 Tokens. Die Ersparnis wiederholt sich in jeder Runde jedes Tickets.
Günstigere und schnellere Antworten. Weniger Eingabe-Tokens pro Aufruf bedeuteten eine niedrigere Rechnung und eine schnellere Erstantwort, ohne dem Agenten ein Werkzeug zu nehmen.
Stabilere mehrstufige Bearbeitung. Mit dem Kontext auf dem Ticket statt auf dem Werkzeugkasten blieb der Agent über Erstattungen, Kontoabfragen und Eskalationen hinweg auf Kurs.

Der Agent wurde am Tag des Umstiegs schneller und günstiger, und wir haben kein einziges Werkzeug entfernt. Er hat bloß aufgehört, sie alle in jede Nachricht mitzuschleppen.