MCP Server Response Formate für KI Agenten optimieren und massiv Token sparen

Wer MCP Server für Vibe Coding baut verschwendet oft 90% der Token durch zu große API Responses. Das haben wir am eigenen Leib erfahren. Unser Sulu CMS MCP Server hat nach jeder Operation die komplette Seite zurückgegeben. 15.000 Zeichen pro Call, von denen der KI Agent vielleicht 1.500 brauchte. In diesem Artikel zeigen wir welche vier Änderungen am Response Format und an der Tool-Architektur den Token Verbrauch um 90% gesenkt haben und welche Design Prinzipien für jeden gelten der APIs oder Tools für KI Agenten baut.

Wer mit KI-Agenten arbeitet kennt das Spiel. Du baust einen MCP Server, der Agent ruft ein Tool auf und bekommt eine fette JSON Response zurück. Bei einem CMS mit 15 Content Blöcken sind das schnell 15.000 Zeichen pro Antwort. Der Agent braucht davon vielleicht 10%.

Das war genau unsere Situation. Wir haben einen MCP Server für Sulu CMS gebaut, über den Claude direkt Seiten lesen, erstellen und bearbeiten kann. Am Anfang hat jede Operation die komplette Seite zurückgegeben: Alle Blöcke, den vollen HTML Content, Metadaten, einfach alles. Hat funktioniert aber war brutal teuer.

Das eigentliche Problem: MCP Server werden meist von Entwicklern gebaut, die an menschliche API Konsumenten denken. Aber ein KI-Agent ist kein Mensch. Er braucht andere Informationen, in anderen Formaten, zu anderen Zeitpunkten. Wer das versteht spart nicht nur Token sondern macht den ganzen Workflow schneller und zuverlässiger.

Unser Sulu CMS MCP Server hatte anfangs eine einzige Read Operation: get. Die holt eine komplette Seite mit allen Blöcken und dem vollen HTML Content. Für eine typische Glossar Seite mit 15 Blöcken sah die Response so aus:

Das Problem: Wenn der Agent nur wissen will welche Blöcke auf der Seite sind um dann einen bestimmten zu bearbeiten, braucht er den ganzen HTML Content nicht. Er braucht eine Übersicht. Trotzdem haben wir ihm jedes Mal die komplette Seite geschickt.

Bei einem typischen Content Workflow passiert das mehrfach. Agent liest die Seite, bearbeitet Block 3, bekommt die ganze Seite zurück, bearbeitet Block 7, bekommt wieder die ganze Seite zurück. Pro Glossar Artikel haben wir so leicht 100.000+ Zeichen nur für Responses verbraucht.

Wir haben vier Änderungen am MCP Server gemacht die zusammen rund 90% der Response Token eingespart haben. Keine davon war besonders aufwendig. Man muss nur verstehen was der KI-Agent in welcher Situation tatsächlich braucht.

Die größte Ersparnis kam von einer neuen Read Operation: get_structure. Statt der kompletten Seite liefert sie nur die Metadaten und eine Block Übersicht ohne Content. Für dieselbe PHPUnit Seite sieht das so aus:

~1.650 statt ~15.800 Zeichen. Das sind rund 90% weniger.

Der Agent sieht auf einen Blick welche Blöcke wo stehen, welchen Typ sie haben und wie die Headline lautet. Das reicht um zu entscheiden welchen Block er lesen oder bearbeiten will. Erst dann holt er mit get_block gezielt den einen Block den er braucht.

Der zweite große Hebel waren die Write Responses. Wenn der Agent einen Block aktualisiert braucht er als Bestätigung nicht die komplette Seite zurück. Er will nur wissen ob es geklappt hat und wie die Blöcke jetzt aussehen.

Vorher kam nach jedem update_block die volle Seite zurück. Jetzt gibt es nur noch kompakte Metadaten:

Bei einem Workflow mit 10 Block Änderungen pro Seite spart das allein schon rund 150.000 Zeichen. Das ist der Unterschied zwischen einem teuren und einem günstigen Content Workflow.

Die dritte Optimierung betrifft die Anzahl der Calls. Statt 5 einzelne update_block Aufrufe gibt es jetzt update_blocks das bis zu 10 Änderungen in einem Call verarbeitet. Und remove_blocks löscht mehrere Blöcke auf einmal statt einzeln.

Weniger Calls bedeuten weniger Overhead, weniger Latenz und weniger Token für die Conversation History. Denn jede Response wird Teil des Kontexts und verbraucht bei jedem weiteren Call erneut Token.

Aus unserer Erfahrung mit dem Sulu CMS MCP Server haben sich vier Prinzipien herauskristallisiert die für jeden gelten der Tools oder APIs für KI-Agenten baut. Egal ob MCP Server, Function Calling oder Custom Tools.

1. Gib nur zurück was der Agent braucht um weiterzumachen. Nach einem Write braucht der Agent eine Bestätigung und vielleicht die neue Blockstruktur. Nicht die komplette Seite. Nach einem Read für die Navigation braucht er Headlines und Positionen. Nicht den vollen HTML Content.

2. Stufe Read Operationen ab. Nicht jeder Read ist gleich. Manchmal will der Agent einen Überblick (get_structure), manchmal ein Detail (get_block), manchmal alles (get). Drei Abstufungen statt einer einzigen Operation machen einen riesigen Unterschied.

3. Biete Batch Operationen an. Wenn der Agent regelmäßig 5 Blöcke hintereinander ändert dann gib ihm eine Operation die alle 5 auf einmal verarbeitet. Jeder einzelne Call wird Teil der Conversation History und kostet bei jedem weiteren Call erneut Token.

4. Denke in Workflows nicht in Endpoints. Schau dir an wie der Agent deine API tatsächlich nutzt. Welche Calls kommen immer zusammen? Wo gibt es unnötige Roundtrips? Optimiere für die häufigsten Workflows, nicht für theoretische Vollständigkeit.

Token Kosten klingen abstrakt bis man sie auf echte Produktionszahlen hochrechnet. Bei Never Code Alone erstellen und pflegen wir über 130 Seiten mit dem MCP Server. Glossar Einträge, Landing Pages, Artikel. Jede Seite durchläuft einen Workflow aus Lesen, Bearbeiten und Publizieren.

Mit den alten Response Formaten hätte die Erstellung von 50 Glossar Artikeln rund 5 Millionen Zeichen nur an Response Token verbraucht. Mit den optimierten Formaten sind es unter 500.000 Zeichen. Das ist nicht nur günstiger sondern auch schneller, weil weniger Daten verarbeitet werden müssen und die Context Window Limits später erreicht werden.

Der Effekt wird bei langen Conversations noch stärker. Jede Tool Response wird Teil des Kontexts. Bei 20 Tool Calls mit jeweils 15.000 Zeichen Response sind das 300.000 Zeichen nur aus alten Responses die bei jedem neuen Call mitgeschickt werden. Mit kompakten Responses sind es nur 4.000 Zeichen. Das bedeutet mehr Platz für den eigentlichen Content und weniger Risiko dass der Agent wichtige Informationen aus dem Kontext verliert.

Ein oft übersehener Kostenfaktor sind die Tool Descriptions des MCP Servers. Jedes Tool das der Server anbietet wird dem KI Agenten bei jedem einzelnen Call als Kontext mitgegeben. Ein einzelnes Tool mit ausführlicher Beschreibung kann 500 bis 1.000 Token kosten. Bei 20 Tools sind das bis zu 20.000 Token die anfallen bevor der Agent überhaupt mit der eigentlichen Arbeit beginnt.

Die Lösung: Weniger Tools die mehr können. Statt für jede einzelne Aktion ein eigenes Tool anzubieten fasst man zusammengehörige Funktionen zusammen. Ein einzelnes sulu_pages Tool mit einem action Parameter ersetzt 20 Einzel-Tools. Der Agent wählt die Aktion über den Parameter statt über die Tool-Auswahl.

Gleichzeitig sollten die Beschreibungen prägnant sein. Der KI Agent braucht genug Information um das richtige Tool zu wählen, nicht mehr. Wer diesen Ansatz konsequent umsetzt kann die Input Token für Tool Definitionen um bis zu 96 Prozent reduzieren. Bei unserem Sulu CMS MCP Server hat genau diese Konsolidierung den größten Effekt auf die Gesamtkosten pro Session gehabt.

Du musst kein Entwickler sein um zu prüfen ob ein MCP Server effizient arbeitet. Diese vier Fragen zeigen dir sofort wo Optimierungspotenzial liegt:

1. Gibt es abgestufte Abfragen? Oder liefert jede Anfrage den kompletten Datensatz? Wenn der Server nur eine einzige Read Operation hat die immer alles zurückgibt ist das das größte Einsparpotenzial.

2. Was kommt nach einer Änderung zurück? Eine kompakte Bestätigung oder der komplette aktualisierte Datensatz? Letzteres ist bei 10 Änderungen pro Workflow ein Kostentreiber.

3. Können mehrere Änderungen gebündelt werden? Oder braucht jede kleine Anpassung einen eigenen Call? Batch Operationen sind bei Content Workflows der zweitgrößte Hebel.

4. Wie viele Token verbrauchen die Tool Definitionen? Wenn der Dienstleister diese Zahl nicht kennt hat er sich nie mit der Agenten-Perspektive beschäftigt.

Wenn dein Dienstleister bei diesen Fragen ausweicht oder sie nicht versteht ist das ein klares Warnsignal. Die Prinzipien hinter diesen Fragen sind kein Geheimwissen, sie gehören 2026 zum Standardrepertoire jedes MCP Server Entwicklers.

Wir haben das am Beispiel eines CMS MCP Servers gezeigt, aber die Prinzipien gelten überall wo KI-Agenten mit Tools arbeiten. Ein paar Beispiele wo dieselbe Logik greift:

Datenbank Tools: Statt komplette Tabellen zurückzugeben lieber nur Spaltennamen und Zeilenanzahl. Den vollen Content erst auf Nachfrage.

File System Tools: Ein Directory Listing braucht keine Dateiinhalte. Erst Struktur zeigen, dann gezielt einzelne Dateien lesen.

API Wrapper: Wenn ein Agent mit einer externen API arbeitet, filtere die Response auf die Felder die der Agent tatsächlich braucht. Nicht einfach die komplette API Response durchreichen.

Monitoring Tools: Dashboard Daten zusammenfassen statt rohe Metriken zu liefern. Der Agent braucht Trends und Anomalien, keine 10.000 Datenpunkte.

Die wichtigste Lektion die wir beim Bauen unseres MCP Servers gelernt haben: Designe deine API Responses für den KI-Agenten, nicht für den Menschen. Ein Agent braucht strukturierte kompakte Daten um Entscheidungen zu treffen. Kein vollständiges HTML, keine redundanten Metadaten, keine unnötigen Verschachtelungen.

90% Token Ersparnis klingt nach viel ist aber eigentlich logisch. Die meisten APIs wurden nie für KI-Agenten als Konsumenten gebaut. Sobald man anfängt aus der Perspektive des Agenten zu denken fallen die Optimierungsmöglichkeiten fast von allein auf.

Wer eigene MCP Server oder KI Tools baut sollte sich drei Fragen stellen: Was braucht der Agent wirklich um weiterzumachen? Welche Daten kann ich weglassen? Und welche Operationen kommen so oft zusammen dass sie ein Batch verdienen?

Du baust eigene MCP Server oder willst deine KI Workflows optimieren? Wir helfen bei der Architektur und Implementierung. Ruf uns an oder schreib an roland@nevercodealone.de.