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 drei Änderungen am Response Format den Token Verbrauch um 90% gesenkt haben und welche Design Prinzipien für jeden gelten der APIs oder Tools für KI Agenten baut.
Inhaltsverzeichnis
Das Problem jeder API Call frisst Token
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.
Vorher eine Seite lesen kostet 15.000 Zeichen
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:
Code:
// Response von get: ~15.800 Zeichen
{
"title": "PHPUnit",
"blocks": [
{
"position": 0,
"type": "headline-paragraphs",
"headline": "Was ist PHPUnit?",
"items": [
{
"type": "description",
"description": "<p>PHPUnit ist das Standard-Framework... (500+ Zeichen HTML)</p>"
},
// ... noch mehr items mit vollem HTML
]
},
// ... 14 weitere Blöcke mit komplettem Content
]
}
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.
Die drei Optimierungen die alles geändert haben
Wir haben drei Ä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.
Erreichen Sie unsere PHP Consultant Spezialisten
Wir sind Experten für PHP und helfen Ihnen, Ihre digitalen Herausforderungen zu meistern. Unser erfahrenes Team unterstützt Sie bei PHP Updates, PHP Refactoring und berät Sie remote zu allen Fragen rund um PHP. Mit unseren vollautomatischen CI/CD Deployments und einer robusten Docker-Infrastruktur bringen wir Ihre PHP-Projekte auf das nächste Level. Vertrauen Sie auf unsere Expertise für zuverlässige und skalierbare PHP-Lösungen.
Erste Optimierung get_structure statt get
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:
Code:
// Response von get_structure: ~1.650 Zeichen
{
"title": "PHPUnit",
"uuid": "edcfbc1e-7e39-4dc8-aaca-e10e3d12e9fe",
"blocks_count": 15,
"blocks": [
{ "position": 0, "type": "excerpt-image" },
{ "position": 1, "type": "table-of-contents" },
{ "position": 2, "type": "headline-paragraphs", "headline": "Was ist PHPUnit?", "items_count": 2 },
{ "position": 3, "type": "contact" },
{ "position": 4, "type": "headline-paragraphs", "headline": "Was ist neu in Version 13?", "items_count": 3 },
// ... nur Position, Typ und Headline pro Block
]
}
~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.
Zweite Optimierung kompakte Write Responses
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:
Code:
// Write Response vorher: komplette Seite (~15.800 Zeichen)
// Write Response nachher: ~200 Zeichen
{
"success": true,
"message": "Block updated successfully",
"blocks": [
{
"position": 4,
"type": "headline-paragraphs",
"headline": "Was ist neu in Version 13?",
"items_count": 3
}
]
}
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.
Dritte Optimierung Batch Operationen statt Einzelcalls
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.
Code:
// Vorher: 5 einzelne Calls = 5 Responses
update_block(position: 2, ...)
update_block(position: 4, ...)
update_block(position: 6, ...)
update_block(position: 8, ...)
update_block(position: 10, ...)
// Nachher: 1 Call = 1 Response
update_blocks(updates: [
{ position: 2, headline: "...", items: [...] },
{ position: 4, headline: "...", items: [...] },
{ position: 6, headline: "...", items: [...] },
{ position: 8, headline: "...", items: [...] },
{ position: 10, headline: "...", items: [...] }
])
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.
Vorher Nachher Vergleich
| Operation | Vorher | Nachher |
|---|---|---|
| Seite lesen für Überblick | ~15.800 Zeichen | ~1.650 Zeichen (90% weniger) |
| Einzelnen Block lesen | ~15.800 Zeichen | ~500 bis 2.000 Zeichen |
| Write Response | ~15.800 Zeichen | ~200 Zeichen |
| 5 Blöcke ändern | 5 Calls à ~15.800 = ~79.000 | 1 Call: ~400 Zeichen |
| Kompletter Glossar Workflow | ~100.000+ Zeichen | ~5.000 bis 10.000 Zeichen |
Vier Design Prinzipien für KI optimierte APIs
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.
Der Business Case was das in der Praxis bedeutet
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.
Nicht nur für CMS das gilt überall
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.
Fazit denke vom Agenten aus
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.
Was ist ein MCP Server und wofür wird er 2026 eingesetzt?
Ein MCP Server ist eine Schnittstelle über die KI Agenten wie Claude mit externen Tools kommunizieren. 2026 werden MCP Server für CMS Steuerung, Datenbank Zugriff, Workflow Automatisierung und viele weitere Anwendungsfälle im Vibe Coding eingesetzt.
Wie viel Token spart man 2026 durch optimierte MCP Responses?
In unserem Praxistest mit dem Sulu CMS MCP Server rund 90% bei Read Operationen und ähnlich viel bei Write Responses. Bei einem typischen Content Workflow reduziert sich der Verbrauch von über 100.000 auf unter 10.000 Zeichen.
Warum verbrauchen MCP Server 2026 so viele Token?
Die meisten MCP Server werden nach klassischen API Design Prinzipien gebaut und geben vollständige Datensätze zurück. KI Agenten brauchen aber oft nur einen Bruchteil dieser Daten um ihre nächste Entscheidung zu treffen.
Was ist der Unterschied zwischen get und get_structure im Jahr 2026?
get liefert die komplette Seite mit allen Blöcken und vollem HTML Content. get_structure liefert nur Metadaten und eine Übersicht welche Blöcke wo stehen ohne den Content. Das spart rund 90% der Token.
Welche MCP Response Optimierungen sind 2026 am wirkungsvollsten?
Die drei wirkungsvollsten Optimierungen sind abgestufte Read Operationen wie get_structure statt get, kompakte Write Responses die nur Metadaten zurückgeben und Batch Operationen die mehrere Änderungen in einem Call bündeln.
Was sind kompakte Write Responses?
Nach einer Schreiboperation gibt der Server nur eine kurze Bestätigung mit den wichtigsten Metadaten zurück statt die komplette Seite. Das reduziert die Response von 15.000 auf rund 200 Zeichen.
Wie funktionieren Batch Operationen bei MCP Servern?
Batch Operationen fassen mehrere Einzelaufrufe zu einem Call zusammen. Statt 5 einzelne update_block Calls mit 5 Responses gibt es einen update_blocks Call mit einer kompakten Response.
Warum werden Tool Responses in der Conversation History zum Problem?
Jede Tool Response wird Teil des Kontexts und verbraucht bei jedem weiteren Call erneut Token. Bei 20 Calls mit jeweils 15.000 Zeichen Response sind das 300.000 Zeichen die ständig mitgeschickt werden.
Gilt die Response Optimierung nur für CMS oder auch für andere Tools?
Die Prinzipien gelten überall wo KI Agenten mit Tools arbeiten. Datenbank Tools, File System Tools, API Wrapper und Monitoring Tools profitieren genauso von kompakten zielgerichteten Responses.
Was bedeutet abgestufte Read Operationen?
Statt einer einzigen Read Operation die alles liefert gibt es mehrere Abstufungen. Erst den Überblick mit get_structure, dann gezielt einzelne Details mit get_block und nur bei Bedarf alles mit get.
Wie wirkt sich die Optimierung auf die Context Window Limits aus?
Kompakte Responses verbrauchen weniger Platz im Context Window. Das bedeutet mehr Raum für den eigentlichen Content und weniger Risiko dass der Agent wichtige Informationen verliert weil der Kontext voll ist.
Was kostet die Umstellung auf optimierte MCP Responses?
Der Aufwand ist überschaubar. Die drei Kernoptimierungen lassen sich in wenigen Tagen implementieren. Der Return on Investment zeigt sich sofort durch niedrigere Token Kosten und schnellere Workflows.
Kann Never Code Alone bei der MCP Server Entwicklung helfen?
Ja wir entwickeln MCP Server für verschiedene CMS und Backend Systeme. Von der Architektur über die Response Optimierung bis zum Produktivbetrieb. Kontaktiere uns unter roland@nevercodealone.de oder ruf an unter +49 176 24747727.
Welche Design Prinzipien gelten für KI optimierte APIs?
Vier Prinzipien: Gib nur zurück was der Agent braucht um weiterzumachen. Stufe Read Operationen ab. Biete Batch Operationen an. Und denke in Workflows statt in Endpoints.
Wo finde ich weitere Vibe Coding Best Practices?
Auf unserer Vibe Coding Best Practices Seite sammeln wir laufend neue Artikel aus der Praxis. Von MCP Server Optimierung über KI Workflow Automatisierung bis zu Content Produktion mit Claude und Sulu CMS.