Warum 87 % Ihres Prompts nicht Ihr Prompt sind

Als OpenAI im Juni 2023 Function Calling einführte, wirkte das wie das fehlende Teil, um nützliche KI-Agenten zu bauen. Endlich konnten LLMs mit der echten Welt interagieren. Doch wer Systeme in den Produktivbetrieb brachte, lernte schnell die Wahrheit: Es war heikel. Sie mussten die Tool-Call-Schleife selbst verwalten, Fehler sauber abfangen und hoffen, dass das Modell aus Ihren sorgfältig formulierten Definitionen die richtige Funktion wählte.

Dann kam MCP.

Im November 2024 stellte Anthropic das Model Context Protocol als Open Source bereit: einen universellen Adapter, der LLMs mit externen Systemen verbindet. Statt N×M eigener Integrationen (N Anwendungen × M Datenquellen) bauen Sie nur noch N+M: Jede Anwendung implementiert den MCP-Client einmal, jedes Tool den Server einmal, und alles arbeitet zusammen.

Innerhalb eines Jahres erreichte MCP etwas Seltenes: Es wurde über Wettbewerbsgrenzen hinweg übernommen. OpenAI, Google und Microsoft unterstützen es alle. Es gibt SDKs für Python, TypeScript, Go, Rust und mehr. Die Community hat Tausende Server gebaut, die von GitHub über Salesforce bis zu lokalen Dateisystemen reichen.

Das MCP-Protokoll

MCP-Server erlauben LLMs, Tools zur Laufzeit zu entdecken und zu nutzen. Zu jedem Tool erhalten Sie eine Beschreibung sowie Angaben zu den Ein- und Ausgabeformaten. Anhand dieser Informationen wählt das LLM das passende Tool für die aktuelle Aufgabe.

So lassen sich Tools dynamisch implementieren und dem LLM bereitstellen. Doch während MCP das Problem der Tool-Entdeckung löst, schafft es ein neues: die Zusammensetzung des Kontexts.

Das passiert, wenn Sie einen MCP-fähigen Agenten aufrufen: Das Context Window setzt sich aus drei Teilen zusammen: dem User-Prompt, Ihren System-Anweisungen und allen Tool-Definitionen der verbundenen MCP-Server.

Bei Hyground haben wir unsere KI-Ops-Agenten mit den Tools verbunden, die sie brauchten: Log- und Metrik-Analyse, Dokumentations-Anbindung, Anbindung an den Infrastruktur-Provider und mehr.

Die 87 %, die nicht Ihr Prompt sind

87 % unseres Kontexts waren MCP-Tool-Definitionen. 11,4 % waren Anweisungen. Der eigentliche Prompt des Nutzers? 1,6 %.

Das ist kein Hyground-spezifisches Problem. Die MCP-Spezifikation verlangt, dass alle Tool-Definitionen vorab geladen werden. Es gibt keinen nativen Mechanismus für semantisches Filtern oder Lazy Loading. Jeder verbundene Server kippt sein vollständiges Schema in den Kontext, bevor das LLM ein einziges Nutzer-Token sieht.

Die Folgen summieren sich. Große Clients haben harte Grenzen gezogen: Cursor begrenzt auf 40 Tools, GitHub Copilot auf 128. Diese Grenzen gibt es, weil die Leistung von LLMs nachlässt, sobald sie aus großen, flachen Tool-Listen auswählen. Das Modell verschwendet Attention auf irrelevante Tool-Beschreibungen, und Zwischenergebnisse der Tools blähen den Kontext zusätzlich auf.

Die Lösung: dynamische Tool-Entdeckung

Die Branche bewegt sich auf ein Muster zu: nicht alle Tools vorab laden. Geben Sie dem Agenten stattdessen einen Mechanismus zum Entdecken.