Vorweg: Das Modell war nicht der Engpass.
„MCP-Server" klingt nach Klempnerarbeit. Eine Zeit lang haben wir ihn auch so behandelt: ein Stück Integrationscode zwischen einem KI-Agenten und einem System, das ohnehin schon existiert. Nützlich und unauffällig.
Dann haben wir ein Dashboard daraufgesetzt.
Bei SABO IT entwickeln wir eigene interne MCP-Server für Atlassian und Redmine. Das Model Context Protocol (MCP) ist ein offener Standard, über den ein KI-Agent definierte Tools gegen ein externes System aufrufen kann. In der Praxis bedeutet das: Ein Agent kann Daten in Jira, Confluence oder Redmine abrufen und damit arbeiten – anstatt dass ein Mensch drei Anwendungen öffnet, um herauszufinden, wann ein Ticket zuletzt aktualisiert wurde.
Wir haben diese Server von Anfang an instrumentiert, vor allem aus Gewohnheit. Die Messdaten der ersten Wochen waren dann der interessante Teil.
Unser Redmine-MCP-Server läuft seit etwa vier Wochen im internen Einsatz. In dieser Zeit wurden rund 1.000 erfolgreiche Tool-Calls verarbeitet. Daraus entstanden etwa 7.100 MCP-Protokollnachrichten und 1.080 Backend-API-Requests.
Zwei Dinge sind uns aufgefallen.
Rund sieben Protokollnachrichten pro nützlicher Aktion. Ein Tool-Call ist kein einzelner Austausch, sondern quasi ein kurzes Gespräch. Initialisierung, Capability-Negotiation, Notifications und Ergebnisse laufen alle über dieselbe Schicht. Ein Teil davon ist gewollt: Wir kapseln nicht einfach die API, sondern ganze Workflows – ein einzelner Aufruf ersetzt damit mehrere Schritte, die ein Mensch sonst von Hand erledigen würde. Bei unserem aktuellen Volumen kostet das nichts Nennenswertes. Das Verhältnis verbessert sich allerdings nicht von selbst, wenn das Volumen wächst. Es vervielfacht sich.
Etwa ein Backend-Request pro Tool-Call. Wir hatten erwartet, dass die Vervielfachung im Backend entsteht. Sie entsteht stattdessen in der Protokollschicht. Das war vor der Messung nicht unsere Annahme – was ehrlicherweise der einzige Grund ist, warum man überhaupt misst.
Ein Wort zur Größenordnung, bevor jemand mehr hineinliest, als darin steckt: Das ist die Version 0.1.0, vier Wochen alt, im internen Einsatz. Das ist kein Produktivbetrieb unter Last, und wir behaupten das auch nicht. Genau deshalb sind die Verhältnisse aussagekräftiger als die Summen. Verhältnisse beschreiben Verhalten, das mit dem Volumen skaliert. Summen beschreiben nur einen einzelnen Zeitpunkt.
Etwa 1 % der HTTP-Requests an den Redmine-Server kommen mit 405 zurück – Method Not Allowed, überwiegend GET-Requests an den MCP-Endpoint. Kein Nutzer hat sich beschwert. Kein Workflow ist sichtbar fehlgeschlagen. Unser Dashboard hat es lediglich erwähnt. Leise. Etwa 1.200 Mal.
Das ist das ehrliche Argument für Observability auf dieser Schicht. Nicht, dass sie eine These bestätigt – sondern dass sie zeigt, welche der eigenen Annahmen falsch waren, solange das System noch klein genug ist, dass die Korrektur eine Vormittagsaufgabe bleibt und kein Projekt wird.
Sie verändert außerdem die Priorisierung. Sobald Aufrufvolumen und Fehlerquoten pro Tool sichtbar sind, verteilt man den Entwicklungsaufwand nicht länger gleichmäßig, nur weil das gerecht wirkt. Ein selten genutztes Tool mit leicht höherer Latenz betrifft praktisch niemanden. Ein häufig genutztes Tool mit demselben Verhalten betrifft jeden Agenten und jeden Workflow, der es damit arbeitet. Caching, Retry-Logik, Fehlerbehandlung – und zunehmend die Token-Effizienz – gehen dorthin, wo die Last tatsächlich anfällt. Und die lag bisher nie ganz dort, wo wir sie vermutet hatten.
Der zweite Bereich, den wir entwickeln, sind erweiterte UI-Fähigkeiten innerhalb unserer MCP-Server.
Man stellt einem Agenten eine Frage zu Jira- oder Confluence-Daten und erhält ein Diagramm statt eines Absatzes. Das klingt nach einer Kleinigkeit. In der Nutzung fühlt es sich deutlich größer an, denn eine Zahl zu lesen ist nicht dasselbe, wie einen Satz über eine Zahl zu lesen.
Eine technische Unterscheidung ist hier wichtig, weil sie leicht missverstanden wird: Wir rendern nicht die UI-Komponenten der angebundenen Anwendungen. Wir nutzen das MCP-Protokoll, um UI-Ressourcen über MCP Apps zu übertragen. Die Oberfläche entsteht für die jeweilige Antwort – sie ist keine Nachbildung der Bildschirme von Jira oder Redmine.
Das ist der Teil unserer Arbeit, der am weitesten nach vorne zeigt. Die Interaktion mit Unternehmenssoftware bedeutete bisher: durch Menüs navigieren, bis man bei den Daten angekommen ist. Ein Teil davon lässt sich möglicherweise dadurch ersetzen, dass man den Informationsbedarf formuliert und beides zurückbekommt – die Daten selbst und eine Form, in der sie sich sinnvoll lesen lassen.
Und es ist zwangsläufig mehr Protokollverkehr. Womit wir wieder beim oben genannten Verhältnis.
In einem produktiven agentischen System ist Performance eine Eigenschaft der gesamten Kette:
KI-Modell → Agent → MCP-Schicht → Tools → Unternehmenssysteme
Fast die gesamte Diskussion konzentriert sich auf das erste Element. Welches Modell besser schlussfolgert, welches schneller ist, welches das größere Kontextfenster hat. Berechtigte Fragen – zu einem einzigen Kettenelement.
Wenn ein Agent Redmine benötigt, um eine Aufgabe abzuschließen, ist die Qualität dieses Austauschs Teil des Ergebnisses. Ein leistungsfähiges Modell kann eine langsame oder unzuverlässige Tool-Schicht nicht dauerhaft kompensieren. Die Latenz dieser Schicht wird zur Latenz des Nutzers. Deren Fehler wandern in die Workflows. Deren Zuverlässigkeit setzt die Obergrenze für die Zuverlässigkeit des Agenten. Das Modell bekommt die Aufmerksamkeit; die Schicht darunter bekommt die Schuld.
Und die Konsequenz ist nicht in erster Linie technisch. Wenn ein Agent häufig genug scheitert, hören Menschen auf, ihn zu benutzen Und gehen zurück zu dem manuellen Weg, dem sie vertrauen. Die Investition ist dann nicht schlechter geworden. Sie wird einfach nicht genutzt.
Unsere Server sind an Atlassian und Redmine angebunden – Entwicklungs- und Projektsysteme, vergleichsweise nachsichtige. Die architektonische Frage ist identisch, sobald die Systeme hinter dem Agenten operativ sind: ERP, MES, Instandhaltung, Qualitätsmanagement.
In industriellen Umgebungen werden die Anforderungen strenger. Software muss sich in das einfügen, was bereits existiert, und über Lebenszyklen von Jahren verlässlich bleiben. Eine Integrationsschicht, die als Wegwerfcode behandelt wird, übersteht diese Belastung nicht.
Deshalb behandeln wir MCP-Server inzwischen wie jede andere zuverlässigkeitskritische Komponente: instrumentiert, gemessen, versioniert – und mit einem klaren Verantwortlichen.
Bei einem Proof of Concept geht es um eine einzige Frage: Kann der Agent die Aufgabe erledigen?
Bei einem produktiven System geht es um die unangenehmen Fragen. Wie zuverlässig läuft es? Wie viele Tool-Calls braucht der Agent dafür? Wo sammelt sich Latenz? Welche Integrationen erzeugen die meisten Fehler? Was passiert, wenn ein Backend nicht erreichbar ist? Welches Tool wird als erstes zum Engpass?
Diese Fragen erhalten weniger Aufmerksamkeit als Modell-Benchmarks. Aber sie entscheiden darüber, ob ein Agent eine überzeugende Demonstration bleibt oder etwas wird, worauf sich ein Unternehmen verlassen kann.
Den Agenten zu entwickeln ist ein Teil der Ingenieursarbeit. Ihn im Zusammenspiel mit realen Systemen zuverlässig zu machen, ist der Punkt, an dem Produktionsreife beginnt.
Genau das bedeutet Knowledge in Action für uns in der Praxis. Nicht KI einzusetzen, weil sie verfügbar ist – sondern sie so in reale Systeme und Prozesse zu integrieren, dass sie dort funktioniert, wo die eigentliche Arbeit stattfindet.
