MCP-Tool‑Bloat zu Skills: Agent‑Architektur für Kosten & Datenschutz

Agenten, die viele Tools kennen, wirken mächtig — bis die Kosten in Form langer Prompts, wiederholter Schema‑Uploads und steigender Token‑Rechnungen sichtbar werden. In Projekten mit hunderten Endpunkte entsteht schnell das, was Entwickler “Tool‑Bloat” nennen. Eine Antwort lautet: progressive tool discovery. Dieses Muster stellt nur die nötigsten Metadaten bereit, findet relevante Tools dynamisch und verhindert, dass das gesamte Ökosystem in jeden Prompt hineingedrückt wird. Im folgenden Artikel lesen Sie, wie sich dieses Prinzip mit wiederverwendbaren Skills verbinden lässt, um Kosten, Datenschutzrisiken und Betreiber-Komplexität gleichzeitig zu senken.

Die Model Context Protocol‑Spezifikation erlaubt es, Tools mit umfassenden Schemas als Teil des Kontexts bereitzustellen. Das ist nützlich: ein vollständiges inputSchema hilft dem Agenten, korrekte Aufrufe zu formen. In großen Ökosystemen führt diese Praxis aber dazu, dass Promptgröße und damit Token‑Kosten exponentiell wachsen. MCP‑Zero‑Forschung (2025) zeigte, wie ein naiver Schema‑Preload Token‑Kosten drastisch erhöht und wie selektive Auswahl Token‑Verbrauch um große Prozentsätze senken kann.

“Je mehr Tools man vorgibt, desto mehr vom Kontext wird verschwendet — das kostet direkt Geld und senkt Echtzeit‑Performance.”

Tool‑Bloat entsteht in drei typischen Schritten: Erstens: ein Entwickler registriert viele Services mit ausführlichen Schemata. Zweitens: der Orchestrator fügt diese Beschreibungen in System‑Prompts ein, um Wahlfreiheit zu erhalten. Drittens: jeder Anfragezyklus trägt unnötige Metadaten mit sich, die weder zur Entscheidung noch zur Ausführung benötigt werden.

Die Symptome sind klar: steigende Token‑Rechnungen, höhere Latenz, schwierigeres Debugging und größere Angriffsflächen für manipulierte Metadaten. Praktiker berichten ebenfalls von schlechteren Retrieval‑Ergebnissen, wenn Indices auf LLM‑Summaries statt auf verifizierten Metadaten beruhen. Einfache Gegenmaßnahmen reichen von Limitierungen der vorab geladenen Tools bis zu strukturiertem, hierarchischem Discovery.

Eine kompakte Vergleichstabelle hilft, die Unterschiede zu visualisieren:

Fazit dieses Kapitels: Ohne gezielte Discovery‑Strategie verwandelt sich ein vielfältiges Tool‑Ökosystem schnell in einen Kostenfresser. Das Problem ist technisch lösbar, erfordert aber Architekturentscheidungen, die über einfache Datenschutz‑ oder Sicherheitspolicies hinausgehen.

Anthropic führte das Skills‑Konzept als praktisches Gegenmittel ein: Kurze Metadaten werden vorab angezeigt, die vollständige SKILL.md aber nur nach Relevanz heruntergeladen. Dieses Muster ähnelt dem Prinzip progressive tool discovery und reduziert sofort den Kontextbedarf. Bei intern kontrollierten Workflows bietet die Dateibasiertheit von Skills eine weitere Stärke: Skill‑Bundles lassen sich signieren, versionieren und lokal auditieren.

Skills sind kein Allheilmittel, aber sie bringen wichtige Vorteile: erstens, eine deutliche Verringerung der Anzahl der vorgeladenen Konstrukte; zweitens, klarere Ownership‑Informationen für jeden Mechanismus; drittens, mechanische Grenzen wie Upload‑Größen und Max‑Skills‑per‑Request, die unabsichtlich als Sicherheitsdämpfer wirken. In der Praxis sehen Teams, dass wiederverwendbare Scripts und SKILL‑Beschreibungen Entwicklungszyklen verkürzen und die Fehleranfälligkeit bei Tool‑Aufrufen reduzieren.

Die technische Formel hinter Skills ist simpel: metadata → lightweight decision → fetch full definition → execute in isolierter Laufzeit. Entscheidend ist die Laufzeitumgebung: Container‑basierte Ausführung ohne Netzwerkzugriff, strikte Paketlisten und Ressourcenlimits minimieren Risiken. Dennoch bleiben Fragen: Wie signiert man Skill‑Bundles vertrauenswürdig? Wie testet man realistische Eingaben, bevor man Code in Containern zulässt? Diese Fragen gehören zur Governance, nicht lediglich zur Technik.

Ein weiterer praktischer Punkt: Skills fördern Wiederverwendbarkeit. Teams können Skill‑Kataloge als interne „App‑Stores” betreiben, mit Reviews, Tests und Zugriffskontrollen. Das ist ein großer Gewinn gegenüber ad‑hoc Endpunkten, die jeder Entwickler beliebig anbinden kann. Gleichzeitig erlaubt das progressive Laden eine hybride Architektur: Nur Top‑N Kandidaten werden vollständig geladen, der Rest bleibt als Metadaten im Index.

Aus Sicht des Datenschutzes ist das Modell vorteilhaft: Sensible Schemas müssen nicht in jeden Prompt; stattdessen steuern Policies, wann ein Skill vollständig offenbart wird. Für Unternehmen bedeutet das: weniger Daten im Kontext, weniger Risiko der unbeabsichtigten Exfiltration und klarere Audit‑Spuren für jeden Skill‑Aufruf.

Die bessere Frage ist selten „MCP oder Skills?”, sondern eher: Wie orchestrieren wir beide Muster, um Kosten, Datenschutz und Skalierbarkeit auszubalancieren? Ein pragmatischer Architekturentwurf kombiniert hierarchisches Discovery‑Routing mit lokalen Skill‑Bundles. Das Grundprinzip lautet: Frage zuerst mit minimalen Metadaten ab; wenn nötig, injiziere nur die Top‑K vollständigen Schemas oder Skill‑Files.

Konkrete Komponenten einer Hybrid‑Architektur:

• Discovery‑Layer: Semantisches Ranking von Tool‑Metadaten mittels Vektor‑Index; kann LLM‑Summaries als Feature nutzen, darf sich aber nicht allein darauf verlassen.
• Top‑K Injection: Nur wenige, vertrauenswürdige Schemas/Skill‑Manifeste werden in den System‑Prompt aufgenommen.
• Skill‑Cache & Signaturen: Bereits verifizierte Skill‑Bundles lokal cachen; Signaturen verhindern Manipulation.
• Policy‑Gate: Policies prüfen, ob sensible Felder oder personenbezogene Daten für das vollständige Laden nötig sind; bei Bedarf erfolgt eine zusätzliche Genehmigungsstufe.
• Audit & Kill‑Switch: Jeder Skill‑Call wird geloggt; Anomalien triggern automatisierte Unterbrechungen.

In der Praxis bringt diese Kombination mehrere Vorteile: Sie verbindet die Token‑Effizienz der MCP‑Zero‑Idee mit der Wartbarkeit und Auditierbarkeit von Skills. Unternehmen mit großen Tool‑Parks profitieren besonders, weil häufig genutzte Integrationen als signierte Skill‑Bundles vorgehalten werden können, während seltene oder externe Tools nur bei Bedarf angefragt werden. Das senkt den langfristigen Wartungsaufwand.

Dennoch ist Vorsicht geboten. Die Reliance auf Indices und Rankings erhöht die Angriffsfläche: manipulierte Metadaten oder vergiftete Indices können dazu führen, dass falsche Tools geladen werden. Deshalb ist ein robustes Test‑ und Reproduzierbarkeits‑Setup unerlässlich: Offline‑Benchmarks gegen einen reproduzierbaren Tool‑Pool, Cross‑Validation zwischen Retrieval‑Strategien und Canary‑Rollouts neuer Discovery‑Modelle sind Bestandteile eines sicheren Einführungsplans.

Kurz: Die Hybrid‑Architektur ist kein Singularity‑Versprechen; sie ist ein pragmatischer Bauplan, der Kosten senkt und Governance ermöglicht — sofern er mit strengen Prüfungen und Signaturen betrieben wird.

Technische Prinzipien müssen messbar sein. Drei Kennzahlen sollten Architekten auf dem Radar haben: Token‑Kosten pro Anfrage, Top‑K Recall der Tool‑Selection und die Latenz bis zur Ausführung. Token‑Kosten sind unmittelbar finanziell spürbar; Recall beeinflusst die Richtigkeit der gewählten Tools; Latenz beeinträchtigt die UX. Ergänzende Metriken sind Anomalie‑Rates bei Tool‑Aufrufen und die Anzahl der vollständigen Skill‑Downloads pro Tag.

Ein pragmatisches Mess‑Setup sieht so aus: Sammeln Sie Baselines mit Schema‑Preload, führen Sie dann A/B‑Tests mit progressive tool discovery durch und messen Sie Token‑Einsparungen, Selektionsfehler und Nutzer‑sichtbare Latenz. MCP‑Zero‑Experimente zeigen erhebliche Token‑Einsparungen in Benchmarks; das lässt sich als Zielgröße nutzen, aber betriebliche Tests sind unerlässlich, weil reale Tool‑Pools heterogener sind als Benchmarks.

Datenschutz‑Metriken sind ebenso wichtig: Anzahl der sensiblen Felder, die in Prompts landen; Volumen der personenbezogenen Daten (PII) pro Anfrage; und die Dauer, für die Logs aufbewahrt werden. Progressive Disclosure hilft hier, weil vollständige Schemas nur bei Bedarf offenbart werden. Ergänzt man das mit Policy‑Gates und signierten Skill‑Bundles, reduziert man die Chance unbeabsichtigter Datenexposition.

Skalierungsstrategien umfassen horizontale Discovery‑Shards, asynchrone Skill‑Vorladung bei erwarteten Workloads und adaptive Top‑K‑Limits, die sich an Echtzeit‑Fehlerquoten orientieren. Operationalisierung heißt außerdem: Canary‑Rollouts neuer Indices, regelmäßige Re‑indexierung mit überprüften Metadaten und automatisierte Tests, die sowohl Retrieval‑Qualität als auch Sicherheit prüfen.

Implementations‑Checklist (Kurzform): 1) Pilot mit klaren Baselines, 2) Signatur‑Workflow für Skill‑Bundles, 3) Index‑Audit & Re‑Indexing‑Plan, 4) Policy‑Gates für PII, 5) Observability (Token, Recall, Latenz, Anomalien). Diese Schritte sorgen dafür, dass Einsparungen nicht durch Sicherheitsvorfälle erkauft werden.

Tool‑Bloat ist kein theoretisches Ärgernis, sondern ein operatives Problem mit messbaren Kosten. Progressive tool discovery reduziert Prompt‑Overhead; wiederverwendbare Skills bringen Governance und Wiederverwendbarkeit. Eine Hybrid‑Architektur verbindet beide Ansätze und erlaubt gleichzeitig Kostenoptimierung und Datenschutzkontrolle. Entscheidend sind Signaturen, Audit‑Pipelines und realistische Benchmarks, bevor man große Tool‑Pools produktiv schaltet.