Backtesting Arena

Backtesting Arena

Zum Blog

73 MCP-Tools im Betrieb: 10 Lehren aus dem Bauen für KI-Agenten

Dein gründlichster Leser bekommt am wenigsten zu lesen. Zehn Stellen, an denen das Bauen für KI-Agenten anders funktioniert als das Bauen für Menschen — mit Zahlen aus dem Betrieb.

Backtesting Arena·29. Juli 2026·10 Min. Lesezeit·0 Aufrufe
73 MCP-Tools im Betrieb: 10 Lehren aus dem Bauen für KI-Agenten

Dein gründlichster Leser bekommt am wenigsten zu lesen.

Jemand fragt seinen KI-Assistenten: Welche Strategie ist die beste? Der Assistent ruft unser Werkzeug auf, bekommt eine Liste zurück und antwortet: die mit 340 Prozent.

Über genau dieser Liste steht auf unserer Website, dass sie die Spitze aus 4.500 getesteten Kombinationen ist. Dieser Satz hat den Nutzer nie erreicht. Er stand auf der Seite. Der Assistent hat die Seite nie gesehen.

Das ist keine Geschichte über schlechte KI. Der Assistent hat genau das getan, was wir ihm gegeben haben. Wir haben ihm nur nicht alles gegeben.

Für wen das gilt

Wenn irgendetwas, das du baust, von einer Maschine gelesen wird — eine Schnittstelle, eine Dokumentation, ein Produktdatensatz — dann gilt der Rest dieses Textes für dich. Wir schreiben hier über MCP, weil wir so einen Server betreiben. Aber jede API, deren Antworten in einem Sprachmodell landen, hat dieselben zehn Probleme.

Der Satz dahinter:

Alles, was ein Mensch nebenbei mitliest, ohne es anzuklicken, musst du ab jetzt ausliefern.

Ein Agent, der eine Seite abruft, liest sie übrigens ganz — gründlicher als jeder Mensch, der die Überschrift überfliegt und sich eine Meinung bildet. Das Problem ist nicht, wie er liest. Es ist, was bei ihm ankommt.

Dass eine Agenten-Schnittstelle im Grunde eine Benutzeroberfläche für einen nicht-menschlichen Nutzer ist, hat Philipp Schmid im Januar 2026 gut auf den Punkt gebracht. Der Gedanke ist nicht neu. Was hier dazukommt, sind Zahlen aus dem Betrieb: 73 Werkzeuge, und zehn Dinge, die uns dabei um die Ohren geflogen sind.


1. Der Vorbehalt muss in die Antwort

Was nicht in der Antwort steht, existiert nicht.

Zurück zur Bestenliste vom Anfang. Auf der Website steht die Einordnung darüber. Der Besucher liest sie vielleicht nicht bewusst — aber sie ist in seinem Blickfeld, während er auf die Tabelle schaut.

Der Agent bekommt zehn Datensätze. Die Überschrift ist kein Datensatz.

Wir haben die Sätze deshalb dorthin verschoben, wo dieser Leser sie bekommt: in die Beschreibung des Werkzeugs selbst. Drei, die wir wirklich gebraucht haben:

  • Eine Bestenliste ist ein herausgesuchtes Extrem, kein Durchschnitt.
  • Wer zehn Strategien vergleicht, hat zehnmal getestet — und muss das Ergebnis entsprechend entwerten.
  • Unsere Auswahlliste von Coins ist nicht so zusammengestellt, wie sie 2019 ausgesehen hätte. Man darf also nicht so tun, als hätte man damals gewusst, welche liquide bleiben.

Keine dieser Warnungen war neu. Sie standen alle schon irgendwo. Nur nicht dort, wo dieser Leser hinschaut.


2. Drei Arten von „nichts gefunden"

Mach aus „keine Ergebnisse" drei verschiedene Antworten.

Hier ist der Agent sogar im Vorteil — wenn du ihn lässt.

Ein Mensch sieht eine leere Tabelle und stutzt. War die Abfrage falsch? Gibt es die Daten nicht? Ist der Zeitraum zu kurz? Er rät. Meistens richtig.

Ein Agent rät nicht, sobald es ein eigenes Feld gibt. Er wertet „Stichprobe zu klein" zuverlässig aus — zuverlässiger, als ein Mensch einen Nebensatz beachtet.

Vorausgesetzt, das Feld existiert. Also trennen wir:

  1. Es gibt keine Daten.
  2. Die Frage passt hier nicht.
  3. Es gibt Daten, aber zu wenige.

Der dritte Fall ist der wichtige. Unter dreißig Beobachtungen ist etwas eine Anekdote, kein Befund. Als Feld überlebt das den Weg zum Nutzer. Als Halbsatz nicht.


3. Zahlen von Hand pflegen geht jetzt schief

Jede Zahl, die du von Hand pflegst, wird irgendwann falsch behauptet.

Ein Mensch, der eine Zahl in der Dokumentation sieht, misstraut ihr ein bisschen. Doku hinkt hinterher, das weiß jeder. Im Zweifel schaut er in der Oberfläche nach.

Ein Agent hat keinen zweiten Ort zum Nachschauen. Er nimmt die Zahl und gibt sie weiter, mit voller Überzeugung, an seinen Nutzer.

Bei uns stand eine einzige Zahl — wie viele Werkzeuge wir anbieten — an dreizehn Stellen von Hand gepflegt. Sie war auf vier verschiedene Werte gleichzeitig auseinandergelaufen. Fünf dieser Stellen waren öffentlich.

Die Lösung ist langweilig: nicht abschreiben, sondern ausrechnen. Ein kleines Skript startet unsere Werkzeugliste und zählt sie durch. Die Liste ist die Wahrheit, alles andere zieht nach.

Zwei Regeln haben wir uns dabei gegeben. Der Zähler darf kein Passwort brauchen — sonst läuft er nicht automatisch mit und damit irgendwann gar nicht. Und er darf nichts wirklich ausführen. Er zählt, er ruft nicht auf.

Nebenbei: Die Zahl in der Überschrift dieses Artikels ist so eine Stelle. Sie wird mitgezählt.


4. Die Prüfung, die still durchwinkt

Eine Prüfung, die nichts findet, muss laut werden — nicht still.

Diesen Fehler haben wir beim ersten Anlauf gemacht, und er ist gemeiner als der davor.

Wir hatten ein Skript, das alle dreizehn Stellen prüft. Nur: Wenn eine Stelle umgeschrieben wird und das Skript sie nicht mehr findet, meldet es keinen Fehler. Es meldet gar nichts. Die Prüfung leuchtet grün, während genau die Stelle wegdriftet, die sie schützen sollte.

Die Regel daraus: Findet die Prüfung eine erwartete Stelle nicht mehr, ist das ein Fehler — nicht ein „alles in Ordnung".

Das gilt für jede automatische Prüfung, überall. Bei Agenten fällt es nur stärker auf, weil niemand mehr zufällig darüberstolpert.


5. Alles mitschicken geht nicht

Was du mitschickst, bezahlt jemand anderes.

Der naheliegende Einwand zu allem bisher: Wenn die Antwort das Nadelöhr ist, pack eben alles hinein.

Geht nicht. Ein Agent hat einen begrenzten Arbeitsspeicher für den laufenden Auftrag. Jede Werkzeugbeschreibung, die er lädt, belegt davon einen Teil — und der fehlt ihm für die eigentliche Aufgabe.

Das Unangenehme: Du merkst nichts davon. Deine Antwortzeiten bleiben gleich. Deine Fehlerquote bleibt gleich. Der Agent wird nur ein bisschen schlechter, und niemand weiß, warum.

„Schreib alle Vorbehalte in jede Antwort" ist deshalb keine Lösung, sondern eine Verschiebung. Die Arbeit ist zu entscheiden, welcher Vorbehalt das Ergebnis wirklich verändert — und welcher nur Platz kostet.

Dasselbe gilt für die Anzahl der Werkzeuge, und da wird es unbequem für uns. Workato empfiehlt in seiner Design-Dokumentation (Stand April 2026) fünf bis acht pro Server, hält acht bis zwölf für vertretbar und rät ab fünfzehn zum Aufteilen. Wir haben 73.

Der Kern dieser Empfehlung stimmt, und sie ist besser begründet als die meisten: Die Anzahl ist ein Budget. Klarheit schlägt Vollständigkeit. Ein Server, dessen Zweck sich nicht in einem Satz sagen lässt, ist zu breit. Nichts davon würden wir bestreiten.

Unsere Einschränkung: Die Zahl allein misst das Falsche. Von unseren 73 gehören siebzehn paarweise zusammen — sieben Fälle, in denen ein Werkzeug den heutigen Wert liefert und ein zweites denselben Wert über die Zeit, dazu vier, die sich nur im Auslöser unterscheiden. Das sind Zusammenlegungen ohne Verlust. 73 Werkzeuge mit siebzehn Dubletten sind etwas anderes als 73 verschiedene Fähigkeiten. Und beides ist etwas anderes als fünfzehn.

Aufteilen hilft außerdem nur, wenn der Nutzer danach wirklich weniger lädt. Verbindet er beide Server, hat er dieselben Beschreibungen im Speicher, nur auf zwei Einträge verteilt.

Die sinnvolle Zielgröße ist deshalb keine Obergrenze. Sie ist: keine zwei Werkzeuge, die dasselbe für zwei Zeiträume tun.

Warum wir das trotzdem noch nicht umgesetzt haben, steht in Punkt 8.


6. Der Name ist alles, was er sieht

Schreib auch hin, wofür dein Werkzeug nicht da ist.

Die nächsten zwei Punkte greifen, bevor irgendetwas gelesen wird. Da hilft die beste Antwort nichts, weil es noch keine gibt.

Ein Mensch entscheidet aus dem Zusammenhang: wo der Knopf sitzt, was daneben steht, welche Seite er offen hat. Ein Agent hat nur Name und Beschreibung.

Ähnlich klingende Werkzeuge werden deshalb zuverlässig verwechselt. Bei uns waren das die Paare aus „heutiger Wert" und „Wert über die Zeit" — und vier Werkzeuge zum Starten eines Tests, die sich in Zweck und Umfang unterscheiden, aber ähnlich heißen.

Geholfen hat nicht, die Funktion besser zu beschreiben. Geholfen hat, die Abgrenzung zu beschreiben. Nicht nur „liefert X", sondern „liefert X für heute — für den Verlauf nimm das andere".

Der Satz, der sagt, wofür etwas nicht da ist, ist oft der nützlichere.


7. Leere Felder werden ausgefüllt, nicht erfragt

Ein Feld ohne Beschreibung wird geraten.

Ein Mensch, der nicht weiß, was ein Feld erwartet, fragt nach oder probiert es und liest die Fehlermeldung. Ein Agent füllt aus.

Bei einer Bestandsaufnahme fanden wir 52 Parameter ohne jede Beschreibung. Das sind 52 Einladungen, sich etwas auszudenken: eine Einheit, einen Standardwert, eine plausible Obergrenze.

Jedes Feld braucht drei Angaben: Einheit, Standardwert, Grenzen.

„Tage" reicht nicht. „Länge der Reihe in Tagen, Standard 365, erlaubt sind 90 bis 1095" reicht.

Nebenbei, weil es dazugehört: Beim Nachmessen stellten sich sechs unserer eigenen Beanstandungen als Fehlalarm heraus. Unsere Prüfregel war zu grob. Wir haben die Regel korrigiert, statt korrekte Texte umzuschreiben. Langweiliger, aber richtig herum.


8. Es gibt kein Banner, das ihn erreicht

Eine Umbenennung ist für einen Agenten ein Ausfall ohne Vorwarnung.

Bei einer Website kannst du eine Änderung ankündigen. Banner, Hinweis, Übergangsfrist — die Leute sehen es beim nächsten Besuch.

Wer einen Agenten betreibt, hat die Verbindung einmal eingerichtet und schaut nie wieder hin. Es gibt keine Stelle, an der du ihn erreichst. Der Tag, an dem du ein Werkzeug umbenennst, ist der Tag, an dem seine Automatisierung stumm aufhört zu funktionieren.

Genau deshalb haben wir die Zusammenlegung aus Punkt 5 nicht gemacht, obwohl wir sie für richtig halten. Sie kommt mit einer Übergangszeit: alter und neuer Name laufen eine Weile parallel, der alte weist auf den Wechsel hin, und erst danach verschwindet er.

Das ist mehr Arbeit als ein Stichtag. Ein Stichtag ist aber keine Umstellung, sondern ein Ausfall, den du deinen Nutzern zumutest, ohne dass sie ihn kommen sehen.


9. Lizenzen reichen weiter als gedacht

Anzeigen ist ein Ende. Eine Schnittstelle ist ein Anfang.

Eine Datenlizenz, die dir erlaubt, etwas auf deiner Seite zu zeigen, erlaubt nicht automatisch, dass ein Agent dieselben Zahlen in ein fremdes Produkt weiterträgt.

Und er trägt sie vollständig weiter. Er nimmt die Reihe, wie sie kommt, und legt sie in einer Antwort ab, in einer Datei, in einem anderen Dienst.

Wir prüfen Lizenzen deshalb je Ausspielweg, nicht je Datenquelle. Dieselbe Zahl kann auf der Website erlaubt sein und über die Schnittstelle nicht.

Uns ist das zweimal bei Quellen aufgefallen, die wir für unproblematisch gehalten hatten. Beide Male, weil jemand die Bedingungen gelesen hat statt der Zusammenfassung der Bedingungen.


10. Du kannst nicht gegen dich selbst testen

Du füllst die Lücke im Kopf. Miss stattdessen.

Der Punkt, der alle anderen zusammenhält.

Du weißt, was dein Werkzeug tut. Deshalb liest sich jede Beschreibung, die du schreibst, für dich vollständig. Du siehst die Lücke nicht, weil du sie beim Lesen automatisch füllst. Jedes Mal.

Gegenlesen hilft dagegen nicht. Messen hilft.

Wir messen drei Dinge, alle stumpf und alle wirksam:

  • Wie viele Felder haben überhaupt eine Beschreibung?
  • Wie lang ist die kürzeste?
  • Wo liegt der Mittelwert?

Die kürzeste ist die aussagekräftigste. Ein guter Durchschnitt verdeckt, dass irgendwo ein Werkzeug mit einem Halbsatz steht — und dieser Halbsatz ist die Stelle, an der ein Agent falsch abbiegt.


Was das nicht heißt

Das ist kein Plädoyer dafür, alles doppelt zu dokumentieren. Punkt 5 sagt, warum das nicht geht.

Und es heißt ausdrücklich nicht, dass Agenten die schlechteren Leser wären. Im Gegenteil: Ein Agent überspringt keinen Absatz, weil er es eilig hat. Er bildet sich keine Meinung nach der Überschrift. Beim Lesen ist er den meisten Menschen überlegen.

Das Problem sitzt eine Ebene früher. Nicht wie gelesen wird, sondern was überhaupt ankommt. Und darüber entscheidet nicht der Leser, sondern du — mit jedem Feld, das du in die Antwort legst oder eben nicht.

Bleibt die unbequeme Folgerung. Wo deine Vorbehalte standen, war bisher fast egal, solange sie irgendwo standen: Das menschliche Auge nimmt Randständiges mit. Diese Großzügigkeit fällt weg.


Die Kurzfassung

  1. Was nicht in der Antwort steht, existiert nicht.
  2. Mach aus „keine Ergebnisse" drei verschiedene Antworten.
  3. Jede Zahl, die du von Hand pflegst, wird irgendwann falsch behauptet.
  4. Eine Prüfung, die nichts findet, muss laut werden — nicht still.
  5. Was du mitschickst, bezahlt jemand anderes.
  6. Schreib auch hin, wofür dein Werkzeug nicht da ist.
  7. Ein Feld ohne Beschreibung wird geraten.
  8. Eine Umbenennung ist für einen Agenten ein Ausfall ohne Vorwarnung.
  9. Anzeigen ist ein Ende. Eine Schnittstelle ist ein Anfang.
  10. Du füllst die Lücke im Kopf. Miss stattdessen.

Der billigste erste Schritt ist Nummer 10: Zähl nach, wie viele deiner Felder eine Beschreibung haben. Ein Nachmittag Arbeit, und du weißt, wie groß das Problem bei dir ist.

Häufige Fragen

Wie viele MCP-Werkzeuge sind zu viele? Veröffentlichte Empfehlungen liegen bei fünf bis acht pro Server, mit einer Aufteilungsschwelle um fünfzehn (Workato, April 2026). Als Ausgangspunkt vernünftig. Wir halten die reine Anzahl trotzdem für die schwächere Kennzahl: Entscheidend ist, wie viele deiner Werkzeuge sich zusammenlegen lassen, ohne dass eine Fähigkeit verlorengeht. Und Aufteilen hilft nur, wenn der Nutzer danach wirklich weniger lädt.

Gilt das nur für MCP? Nein. Es gilt überall, wo ein Programm eine Antwort bekommt statt einer Seite — auch bei einer gewöhnlichen API, deren Antworten in einem Sprachmodell landen. Weniger gilt es für einen Agenten, der wirklich deine Website abruft: Der sieht die Seite, und er liest sie gründlicher als die meisten Besucher.

Muss ich meine Vorbehalte jetzt überall doppelt schreiben? Nicht doppelt, sondern dort, wo dieser Leser sie bekommt. Und dort auch nur die, die das Ergebnis wirklich verändern. Der Rest kostet Platz, den jemand anderes bezahlt.

Wie lang sollte eine Beschreibung sein? Wichtiger als die Länge ist der Inhalt: wofür das Werkzeug da ist, wofür ausdrücklich nicht, und je Feld Einheit, Standardwert und Grenzen. Miss die kürzeste, nicht den Durchschnitt.

Jetzt selbst testen

Fahre den Backtest mit deinen eigenen Parametern und Zeiträumen.

Backtest starten →
📬

Don't miss new blog posts

One short email per new post — strategies, backtests, market analysis. No spam, unsubscribe with one click anytime.

By subscribing you accept our privacy policy. We use Resend for delivery. Double opt-in confirmation required.

Comments (0)

Join free to post comments.

Sign up →

No comments yet. Be the first!