15. April 2026
Skills, Agents und MCP — Die drei Erweiterungsschichten von Claude Code
Claude Code bietet drei fundamentale Erweiterungsmechanismen: Skills, Agents und MCP-Server. Obwohl sie ähnliche Zwecke erfüllen, unterscheiden sie sich grundlegend in Architektur und Einsatzszenarien.
Was im Hype um Claude Code und Claude Cowork häufig in Vergessenheit gerät. Es folgen meine fundierten Erfahrungen nach intensiver Nutzung in mehreren Projekten.
Einleitung: Skills, Agents, MCP
Claude Code bietet drei fundamentale Erweiterungsmechanismen: Skills, Agents und MCP-Server. Obwohl sie auf den ersten Blick ähnliche Zwecke erfüllen — Claude mit zusätzlichem Wissen und Fähigkeiten auszustatten — unterscheiden sie sich grundlegend in Architektur, Token-Verbrauch, Timing und Einsatzszenarien. Dieser Artikel analysiert die drei Schichten anhand einer realen 10-Projekte-Produktionsumgebung, berechnet den tatsächlichen Context-Window-Impact und leitet daraus Architekturprinzipien für die effiziente Nutzung ab.
1. Problemstellung: Das Context Window als knappe Ressource
Das Context Window von Claude (200k Tokens bei Opus 4.6, Stand Februar / März 2026) erscheint grosszügig — bis man die Fixkosten versteht. Bei jedem Gesprächsbeginn werden folgende Elemente geladen: System Prompt (~4.000 Tokens), CLAUDE.md global (~800 Tokens), CLAUDE.md projekt-spezifisch (~250 Tokens), MEMORY.md (~400 Tokens), Plugin-Metadaten (variabel), MCP Tool Descriptions (variabel). Basis-Overhead: ~5.500+ Tokens.
Die variablen Kosten ergeben sich aus der Anzahl aktiver Erweiterungen. In unserem Produktionssetup sah die Rechnung vor der Optimierung so aus: 74 Skills × ~100 Wörter = ~7.400 Tokens, 56 Commands × ~50 Wörter = ~2.800 Tokens, 24 Agents × ~100 Wörter = ~2.400 Tokens, 3 MCP-Server × ~8 Tools = ~1.900 Tokens. Total: ~14.500 Tokens NUR für Erweiterungs-Metadaten.
20.000 Tokens Fixkosten bei Session-Start — 10% des Context Windows, bevor der User ein einziges Wort geschrieben hat. Bei langen Sessions mit viel Code-Kontext wird der verbleibende Platz kritisch.
2. Die drei Erweiterungsschichten im Vergleich
2.1 Skills — Prozedurales Wissen auf Abruf
Skills sind Markdown-Dokumente (SKILL.md) mit optionalen Referenz-Dateien, die Claude domänenspezifisches Prozesswissen vermitteln. Sie laden in drei Ebenen: Metadaten (immer im Context, ~100 Wörter pro Skill), SKILL.md Body (nur wenn die Description matcht, ~1.500-2.000 Wörter), References (nur wenn Claude sie explizit braucht, unbegrenzt). Architekturmuster: Progressive Disclosure.
Token-Profil eines typischen Skills: Description ~70 Tokens (immer geladen), SKILL.md Body ~2.400 Tokens (bei Trigger), Reference 1 ~2.000 Tokens (bei Bedarf), Reference 2 ~1.600 Tokens (bei Bedarf). Total wenn alles geladen: ~6.070 Tokens. Typisch (nur Trigger): ~2.470 Tokens.
Stärken: Deterministisches Wissen (Code-Patterns, Checklisten, Konfigurationen), kein Laufzeit-Overhead — alles ist Text, Progressive Disclosure spart Context wenn Details nicht gebraucht werden, versionierbar und testbar. Schwächen: Können nicht selbst handeln — nur informieren, kein Zugang zu externen Systemen, Trigger-Matching basiert auf Textähnlichkeit.
2.2 Agents — Autonome Spezialisten
Agents sind Markdown-Dateien mit Frontmatter, die eine Agent-Persona definieren — inklusive Tool-Beschränkungen, Systemanweisungen und Kontext. Sie laden in zwei Stufen: Agent-Beschreibung (immer im Context, ~50-100 Wörter), Agent-Body (nur wenn der Agent spawnt, ~500-2.000 Wörter). Architekturmuster: Delegation.
Token-Profil: Agent-Beschreibung ~100 Tokens (immer im Hauptkontext), Agent-Body beim Spawn ~1.000 Tokens, Agent-Arbeit ~5.000-50.000 Tokens (im Subprocess), Ergebnis zurück ~500-2.000 Tokens. Impact auf Hauptkontext: ~600-2.100 Tokens.
Stärken: Eigener Context Window — belastet nicht den Hauptkontext, kann parallel laufen, hat Zugang zu allen Tools, kann komplexe Multi-Step-Tasks autonom erledigen. Schwächen: Latenz (5-30s Spawn), eigene API-Kosten, kein Gedächtnis zwischen Spawns, können über-engineered sein.
Praktisches Beispiel: electron-developer Agent + electron-best-practices Skill — der Agent stellt das WER bereit (Electron-Spezialist), der Skill das WIE (konkrete IPC-Patterns, Anti-Patterns, Code-Referenzen).
2.3 MCP-Server — Brücke zu externen Systemen
MCP-Server sind eigenständige Prozesse, die Claude mit externen Datenquellen und Aktions-Fähigkeiten verbinden. Tool Descriptions sind immer im Context (~80 Wörter pro Tool), Tool Execution erfolgt nur bei Aufruf. Token-Profil RAG-MCP-Server: 12 Tool Descriptions ~960 Tokens (immer), pro Aufruf ~50-100 Tokens Parameter + ~500-3.000 Tokens Result. Fixkosten: ~960 Tokens.
Stärken: Zugang zu externen Systemen (Datenbanken, APIs, Dateisysteme), eigener Prozess, unbegrenzte Daten — nur Ergebnisse kommen in den Context, Standard-Protokoll (JSON-RPC). Schwächen: Tool Descriptions sind IMMER im Context, jedes Tool-Result vergrössert den Context, Prozess-Overhead.
3. Architektur-Vergleich: Wann welche Schicht?
- Daten-Quelle statisch (Markdown) → Skill - Daten-Quelle aus Codebase (Tools) → Agent - Daten-Quelle extern (DB, API) → MCP-Server - Ausführung in-Context (Text) → Skill - Ausführung als Sub-Prozess → Agent - Ausführung als separater Prozess → MCP-Server - Latenz 0 (schon geladen) → Skill - Latenz 5-30s (Spawn) → Agent - Latenz 1-5s (Tool Call) → MCP-Server
Entscheidungsbaum:
Braucht Claude Zugang zu externen Daten? → Ja → MCP-Server. Nein → Skill oder Agent? → Prozedurales Wissen (How-To, Patterns, Checklisten)? → Ja → Skill. → Autonome Multi-Step-Arbeit nötig? → Ja → Agent. Nein → Skill (Default-Wahl).
Kombinationsmuster in der Praxis:
- Muster 1: Agent + Skill (Synergie) — electron-developer Agent liest electron-best-practices Skill → Architektur-Verständnis + konkrete Patterns - Muster 2: Skill + MCP (Datengestütztes Wissen) — qdrant-patterns Skill + MCP-Tool list_materials → Skill-Wissen + Live-Daten - Muster 3: Agent + MCP (Autonome Recherche) — rag-specialist Agent nutzt MCP-Tools für Quellensuche - Muster 4: Alle drei (Vollausbau) — User fragt "Optimiere die Hybrid Search", Agent spawnt, nutzt Skills + MCP, liefert konkreten Plan
4. Token-Ökonomie — Berechnungen aus der Praxis
Vor der Optimierung (56 Plugins aktiv): - System Prompt + CLAUDE.md: ~5.500 Tokens - Plugin-Metadaten (74 Skills): ~7.400 Tokens - Plugin-Metadaten (56 Commands): ~2.800 Tokens - Agent-Beschreibungen (24 Agents): ~2.400 Tokens - MCP Tool Descriptions (3 Server, ~24 Tools): ~1.900 Tokens - Fixkosten pro Session: ~20.000 Tokens (10% von 200k) Nach der Optimierung (20 Plugins aktiv): - System Prompt + CLAUDE.md: ~5.500 Tokens (unverändert) - Plugin-Metadaten (~23 Skills): ~2.300 Tokens - Plugin-Metadaten (~15 Commands): ~750 Tokens - Agent-Beschreibungen (~15 Agents): ~1.500 Tokens - MCP Tool Descriptions (3 Server, ~24 Tools): ~1.900 Tokens - Fixkosten pro Session: ~11.950 Tokens (6% von 200k) Einsparung: ~8.050 Tokens pro Session (40% Reduktion der Fixkosten)
Key Insight zu Agents: Agents sind teurer in Total-Tokens, aber günstiger für den Hauptkontext. Ein 30.000-Token-Agent-Lauf belastet den Hauptkontext nur mit ~1.000 Tokens — das Ergebnis.
5. Architekturprinzipien
Aus der Optimierung eines 10-Projekte-Setups ergeben sich folgende Prinzipien: Prinzip 1: Metadaten-Sparsamkeit — Nur Skills/Agents/MCP-Tools aktivieren, die für die aktuelle Projektgruppe relevant sind. Prinzip 2: Progressive Disclosure konsequent nutzen — Skills sollten nie mehr als ~2.000 Wörter in der SKILL.md haben. Alles darüber gehört in references/. Prinzip 3: Agent-Delegation für Context-Isolation — Aufwendige Recherchen gehören in Agents, nicht in den Hauptkontext. Wenn eine Aufgabe >5.000 Tokens Arbeitskontext braucht, an einen Agent delegieren. Prinzip 4: MCP für Live-Daten, Skills für statisches Wissen — Anti-Pattern: Einen MCP-Server bauen, der statische Dokumentation zurückgibt. Oder einen Skill schreiben, der Live-Daten enthält, die veralten. Prinzip 5: Skill + Agent Komplementarität — Ein Skill allein kann nicht handeln. Ein Agent allein hat kein domänenspezifisches Wissen. Zusammen sind sie mächtig.
6. Projekt-spezifische Profile
Ein zentraler Hebel ist die Differenzierung nach Projekt: - Desktop App (Electron): electron-best-practices + frontend-design Skills, electron-developer Agent, kein MCP - RAG-DB (Python): qdrant-patterns Skill, rag-specialist Agent, rag-db MCP (12 Tools) - Webapplikation (Migration): neon-migration + frontend-design Skills, migration-advisor Agent - Webapp (Vercel): vercel-edge-patterns Skill, clerk-auth + neon-database Agents - RAG-Desktop App: electron-best-practices + qdrant-patterns Skills, electron-developer + rag-specialist Agents, rag-db MCP
Diese Profile werden in den jeweiligen Projekt-CLAUDE.md Dateien hinterlegt. Claude priorisiert Skills und Agents gemäss Profil und vermeidet irrelevante Erweiterungen.
7. Fazit & Context Engineering
Skills, Agents und MCP-Server sind keine austauschbaren Werkzeuge — sie sind komplementäre Schichten einer Erweiterungsarchitektur: - Skills = Wissen (deterministisch, günstig, passiv) - Agents = Handlungsfähigkeit (autonom, kontextisoliert, teuer) - MCP = Systemzugang (live, bidirektional, infrastrukturintensiv)
Die entscheidende Erkenntnis aus der Praxis: Nicht die einzelne Erweiterung bestimmt die Qualität, sondern ihre Orchestrierung. Ein gut abgestimmtes Setup mit 20 gezielten Erweiterungen übertrifft ein Setup mit 74 ungezielten — sowohl in Qualität (weniger Fehlzündungen) als auch in Effizienz (40% weniger Fixkosten).
Der Context Window ist die knappste Ressource im System. Jede Erweiterung, die Token verbraucht ohne Wert zu liefern, reduziert den Platz für die eigentliche Arbeit. Architekturelle Sparsamkeit bei den Metadaten und Progressive Disclosure bei den Inhalten sind die beiden wichtigsten Hebel. Das ganze nennt man im Übrigen Context Engineering — man soll sich auf Context Pipelines: Retrieval, Memory, Tool-Schemas und Kontext-Kompression konzentrieren. Das bringt mehr Leistungsgewinn als weitere Prompt-Optimierung.
Stand: März 2026