Entwickler, die lokale Large Language Models (LLMs) nutzen, stellen fest, dass ein einziger Multi-Channel-Protocol (MCP)-Server das gesamte Kontextfenster aufbrauchen kann, noch bevor ein Benutzer überhaupt einen Prompt eingibt. Sie müssen sich zwischen eingeschränkten Tool-Beschreibungen oder einem unterbrochenen Gesprächsfluss entscheiden.

Warum Token-Bloat für lokale LLMs entscheidend ist

MCP ermöglicht es einem LLM, externe Tools – APIs, Skripte oder Dateisystem-Utilities – aufzurufen, indem dem Modell eine Beschreibung jedes Tools übergeben wird. In der Cloud gehostete Modelle mit einem Kontextfenster von 128 k Token können viele Tool-Definitionen aufnehmen und bieten dennoch Raum für den Dialog mit dem Benutzer. Ein 7-Milliarden-Parameter-Modell, das lokal mit einem 8 k-Token-Fenster läuft, stößt bereits nach dem Laden weniger Tools an seine Grenzen. Der Kompromiss ist drastisch: Kurze, kostengünstige Beschreibungen führen zu Fehlleitungen der Aufrufe; lange, detaillierte Beschreibungen verbrauchen das Budget, das für den Chat benötigt wird.

Die Kette der Ereignisse, die dazu geführt hat

MCP wurde entwickelt, um benutzerdefinierten Integrationscode durch eine einzige, modellgesteuerte Schnittstelle zu vielen Datenquellen zu ersetzen. Die meisten MCP-Server fungieren als dünne Wrapper um REST-Endpunkte, die für menschliche Bediener und nicht für Maschinen gedacht sind. Wenn diese Wrapper in einer lokalen LLM-Sitzung landen, muss das Modell den Namen, die Parameter und die Nutzungshinweise jedes Tools lesen, bevor es entscheiden kann, welches es aufrufen soll. Winzige Kontextfenster verwandeln diesen „Beschreibungs-Overhead“ in einen strukturellen Flaschenhals.

Wer gewinnt, wer verliert

  • Entwickler, die On-Device-Assistenten bauen, verlieren an Flexibilität. Sie müssen entweder Tool-Kataloge ausdünnen, was das Risiko häufiger Fehler birgt, oder einen aufgeblähten Prompt akzeptieren, der die Benutzereingabe abschneidet.
  • Endbenutzer erleben unzuverlässiges Verhalten, wenn der Assistent das falsche Tool auswählt oder die Ausführung verweigert, weil der Kontext voll ist.
  • Tool-Anbieter gewinnen einen einheitlichen Einstiegspunkt.

Die Kosten bestehen nicht nur in einer schlechteren Benutzererfahrung; es entstehen auch Sicherheitsbedenken. Wenn ein MCP-Agent jede lokale Datei lesen kann, kollabiert das Berechtigungsmodell zu einem „Alles-oder-Nichts“-Prinzip. Ohne Sandbox kann ein falsch konfigurierter Tool das gesamte Dateisystem offenlegen.

Was Entwickler dagegen unternehmen

Drei Workarounds dominieren die Community:

  • Beschreibungen kürzen – Tool-Metadaten auf das absolute Minimum reduzieren. Dies spart Token, erhöht aber die Wahrscheinlichkeit, dass das Modell den falschen Endpunkt wählt, was zu Fehlern führt, die Entwickler abfangen und erneut versuchen müssen.
  • Dynamisches Laden – Nur die Teilmenge der Tools laden, die für die aktuelle Konversation relevant sind. Ein leichtgewichtiger Dispatcher entscheidet basierend auf der Absicht des Benutzers, welcher Tool-Satz injiziert wird. Dies reduziert die inaktive Token-Nutzung, erhöht aber die Latenz und die Code-Komplexität.
  • Aktive Server begrenzen – Die Anzahl der MCP-Server pro Sitzung deckeln, was Entwickler dazu zwingt, die wichtigsten Integrationen zu priorisieren. Dies hält die Prompt-Größe handhabbar, opfert jedoch die Breite der Funktionalität.

Keine dieser Lösungen ist ein Allheilmittel. Das Kürzen von Beschreibungen beeinträchtigt die Zuverlässigkeit; dynamisches Laden fügt eine Entscheidungsebene hinzu, die die Antworten verlangsamt; die Begrenzung von Servern erzwingt harte Entscheidungen darüber, welche Datenquellen unterstützt werden sollen.

Sicherheitsrisiken im Zusammenhang mit dem Token-Problem

Lokale Agenten laufen oft mit uneingeschränktem Dateisystemzugriff. Das MCP-Protokoll bietet keine Granularität zwischen „lies diesen Ordner“ und „lies alles“. Einige Teams haben Gateway-Layer gebaut, um das Problem des Vollzugriffs zu lösen, was die Komplexität weiter erhöht. Diese Gateways mildern das „Vollkontroll“-Problem ab, vergrößern aber auch die Codebasis.

Tools für kleine Modelle entwerfen

Große Cloud-Modelle können Fehler in Beschreibungen kompensieren, weshalb Entwickler manchmal die Notwendigkeit präziser Tool-Definitionen übersehen. Für lokale Modelle sollten Sie diese Prinzipien befolgen:

  • Eingeschränkte Funktionalität – Jedes Tool sollte nur eine Sache tun. Ein „Search“-Tool, das auch Dateien schreibt, wird ein Modell verwirren, das keine überlappenden Verantwortlichkeiten verwalten kann.
  • Eindeutige Benennung – Vermeiden Sie generische Namen wie „process“ oder „handle“. Namen sollten die exakte Operation vermitteln, um die kognitive Last des Modells zu verringern.
  • Klare, prägnante Beschreibungen – Geben Sie nur die Parameter an, die das Modell wirklich benötigt, um eine Entscheidung zu treffen. Verwenden Sie ein konsistentes Format, damit das Modell Muster schnell erkennen kann.

Gegenargument: Das Protokoll hat dennoch einen Wert

Trotz der Reibungspunkte bleibt MCP attraktiv, da es Boilerplate-Code abstrahiert. Eine einzige, modellgesteuerte Schnittstelle kann mit Dutzenden von Diensten verbunden werden, ohne für jeden benutzerdefinierte Adapter schreiben zu müssen. Teams, die sich Cloud-Scale-Modelle leisten können, sehen Token-Bloat als kein Problem an, und der Komfort überwiegt den Overhead. Die Herausforderung besteht darin, diesen Komfort auf die eingeschränkte Welt der On-Device-LLMs zu übertragen.

Fazit

Wenn Sie einen On-Device-Assistenten entwickeln, sollten Sie MCP-Tool-Beschreibungen als knappe Ressource behandeln. Kürzen Sie diese, laden Sie sie dynamisch und entwerfen Sie eng gefasste Tools, um das Kontextfenster für das eigentliche Gespräch freizuhalten. Schützen Sie sich gleichzeitig vor dem impliziten „Full-Access“-Sicherheitsmodell, indem Sie eine Berechtigungsebene einführen, selbst wenn dies ein paar zusätzliche Token kostet. Die Balance, die Sie hierbei finden, entscheidet darüber, ob sich Ihr lokales LLM wie ein hilfreicher Begleiter oder wie ein fehlerhafter Chatbot anfühlt.