Skills, Agents und MCP — Die drei Erweiterungsschichten von Claude Code

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: Der 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:
 

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  (Metadaten, immer geladen)
56 Commands × ~50 Wörter  = ~2.800 Tokens
24 Agents  × ~100 Wörter  = ~2.400 Tokens
3 MCP-Server × ~8 Tools   = ~1.900 Tokens  (Tool Descriptions)
                             ──────────────
                    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

Was sie sind: Markdown-Dokumente (SKILL.md) mit optionalen Referenz-Dateien, die Claude domänenspezifisches Prozesswissen vermitteln.
 
Wann sie laden:
1. Metadaten (name + description): Immer im Context — das ist der Trigger-Mechanismus (~100 Wörter pro Skill)
2. SKILL.md Body: Nur wenn die Description matcht (~1.500-2.000 Wörter)
3. References: Nur wenn Claude sie explizit braucht (unbegrenzt)
 
Architekturmuster: Progressive Disclosure — drei Ebenen mit steigender Tiefe.
 

Ebene 1: Immer geladen     → "electron-best-practices: Use when user asks to fix IPC..."
Ebene 2: Bei Trigger        → SKILL.md mit IPC-Patterns, Security, Auto-Update
Ebene 3: Bei Bedarf         → references/project-configs.md, references/security-patterns.md

 
Token-Profil eines typischen Skills:
 

 
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 (Markdown-Dateien)
 
Schwächen:
- Können nicht selbst handeln — nur informieren
- Kein Zugang zu externen Systemen
- Trigger-Matching basiert auf Textähnlichkeit (kann fehlzünden oder nicht zünden)

 
Praktisches Beispiel: `neon-migration` Skill
 
Wenn ein Entwickler bei in einem Projekt fragt "wie ersetze ich auth.uid() für die Neon-Migration", triggt die Description ("replace auth.uid()") den Skill. Der SKILL.md Body liefert das Pattern:
 
```sql
CREATE OR REPLACE FUNCTION app_uid() RETURNS uuid AS $$
  SELECT current_setting('app.current_user_id', true)::uuid;
$$ LANGUAGE sql STABLE;
```
 
Erst wenn der Entwickler die Supabase-to-Drizzle Konvertierung braucht, wird `references/supabase-to-drizzle.md` nachgeladen — eine ~1.200-Wörter-Tabelle mit Query-Äquivalenten.
 

 
2.2 Agents — Autonome Spezialisten

Was sie sind: Markdown-Dateien mit Frontmatter, die eine Agent-Persona definieren — inklusive Tool-Beschränkungen, Systemanweisungen und Kontext.
 
Wann sie laden:
1. Agent-Beschreibung: Immer im Context als Teil der Agent-Tool-Konfiguration (~50-100 Wörter)
2. Agent-Body: Nur wenn der Agent spawnt (volle Datei, ~500-2.000 Wörter)
 
Architekturmuster: Delegation — ein Agent wird in einem Sub-Prozess gestartet und arbeitet autonom.

Token-Profil:
 

Stärken:
- Eigener Context Window — belastet nicht den Hauptkontext
- Kann parallel laufen (mehrere Agents gleichzeitig)
- Hat Zugang zu allen Tools (Read, Write, Bash, Grep etc.)
- Kann komplexe Multi-Step-Tasks autonom erledigen
 
Schwächen:
- Latenz: Jeder Spawn dauert 5-30 Sekunden
- API-Kosten: Eigener Context = eigene Token-Berechnung
- Kein Gedächtnis zwischen Spawns (ausser via Dateien)
- Können über-engineered sein für einfache Aufgaben
 
Praktisches Beispiel: `electron-developer` Agent + `electron-best-practices` Skill
 
Das Zusammenspiel ist komplementär:
 

User: "Fix den IPC-Bug in App XY"
 
1. Agent-Beschreibung triggert electron-developer
2. Agent spawnt mit eigener Kontext-Isolation
3. Im Agent-Context triggert electron-best-practices Skill
4. Agent hat sowohl seine Persona (Architektur-Expertise)
   als auch den Skill (konkrete Patterns: invoke/handle, Cleanup)
5. Agent recherchiert in src/main/, src/preload/, findet den Bug
6. Agent liefert Fix + Erklärung zurück

 
Der Agent stellt das WER bereit (Electron-Spezialist mit Main/Renderer-Verständnis), der Skill das WIE (konkrete IPC-Patterns, Anti-Patterns, Code-Referenzen).
 

 
2.3 MCP-Server — Brücke zu externen Systemen

 
Was sie sind: Model Context Protocol Server — eigenständige Prozesse, die Claude mit externen Datenquellen und Aktions-Fähigkeiten verbinden.
 
Wann sie laden:
1. Tool Descriptions: Immer im Context — jedes MCP-Tool hat eine Beschreibung (~80 Wörter pro Tool)
2. Tool Execution: Nur bei Aufruf — der MCP-Server führt die Operation aus
3. Ergebnis: Kommt als Tool-Result in den Context
 
Architekturmuster: Tool Extension — Claude erhält neue Fähigkeiten, die über Text hinausgehen.

 
Token-Profil des RAG-MCP-Servers:
 

Stärken:
- Zugang zu externen Systemen (Datenbanken, APIs, Dateisysteme)
- Eigener Prozess — Abstürze betreffen nicht Claude
- Unbegrenzte Daten — nur Ergebnisse kommen in den Context
- Standard-Protokoll (JSON-RPC) — universell einsetzbar
 
Schwächen:
- Tool Descriptions sind IMMER im Context (nicht abschaltbar pro Session)
- Jedes Tool-Result vergrössert den Context
- Prozess-Overhead (muss laufen, Speicher, Ports)
- Debugging komplex (separater Prozess, eigene Logs)
 

3. Architektur-Vergleich

 
3.1 Wann welche Schicht einsetzen

3.2 Entscheidungsbaum

Braucht Claude Zugang zu externen Daten/Systemen?
├── Ja → MCP-Server
│   ├── Datenbank (Qdrant, Neon, Redis) → MCP-Server
│   ├── API (Vercel, GitHub, Slack) → MCP-Server
│   └── Dateisystem (Obsidian, Google Drive) → MCP-Server
│
└── Nein → Skill oder Agent?
    ├── Ist es prozedurales Wissen (How-To, Patterns, Checklisten)?
    │   └── Ja → Skill
    │       ├── Einfaches Pattern → Nur SKILL.md
    │       └── Komplexes Thema → SKILL.md + References
    │
    └── Braucht es autonome Multi-Step-Arbeit?
        ├── Ja → Agent
        │   ├── Code-Exploration → Explore Agent
        │   ├── Code-Review → Code-Reviewer Agent
        │   └── Domain-Expertise → Custom Agent
        │
        └── Nein → Skill (Default-Wahl)

 
3.3 Kombinationsmuster in der Praxis

 
Muster 1: Agent + Skill (Synergie)

electron-developer Agent spawnt
→ Liest electron-best-practices Skill
→ Hat sowohl Architektur-Verständnis als auch konkrete Patterns
→ Findet und fixt den Bug mit präzisen Code-Referenzen

 
Muster 2: Skill + MCP (Datengestütztes Wissen)

qdrant-patterns Skill ist geladen (How-To für Collection-Design)
→ User fragt "wie sieht meine aktuelle Collection aus?"
→ MCP-Tool `list_materials` liefert Live-Daten aus Qdrant
→ Skill-Wissen + MCP-Daten = präzise Empfehlung

 
Muster 3: Agent + MCP (Autonome Recherche)

rag-specialist Agent spawnt
→ Nutzt MCP-Tools (hybrid_search, get_context) für Quellensuche
→ Analysiert Ergebnisse mit Fachwissen
→ Liefert strukturierte Antwort mit Quellenverweisen

 
Muster 4: Alle drei (Vollausbau)

User: "Optimiere die Hybrid Search in RAG-DB"
1. qdrant-patterns Skill triggert (Patterns für Hybrid Search)
2. rag-specialist Agent spawnt (autonome Analyse)
3. Agent nutzt MCP-Tools (search_materials, get_context)
4. Agent hat Skill-Wissen (Score-Kombination, RRF, Reranking)
5. Agent liefert konkreten Optimierungsplan mit Benchmarks

 

 
4. Token-Ökonomie — Berechnungen aus der Praxis

 
4.1 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)

 

4.2 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)
 

4.3 Kosten einer typischen Skill-Aktivierung

Trigger:
  electron-best-practices Description:               ~70 Tokens (schon geladen)
  + SKILL.md Body:                                         +2.400 Tokens
                                                                         = 2.470 Tokens
 
Mit einer Reference:
  + references/project-configs.md:                 +2.000 Tokens
                                                                          = 4.470 Tokens
 
Mit beiden References:
  + references/security-patterns.md:           +1.600 Tokens
                                                                       = 6.070 Tokens

 

4.4 Kosten einer Agent-Delegation

Im Hauptkontext:
  Agent-Beschreibung:                                        ~100 Tokens (schon geladen)
  + Spawn-Ergebnis zurück:                    +500-2.000 Tokens
                                                                  = 600-2.100 Tokens Hauptkontext
 
Im Agent-Subprocess:
  System Prompt (reduziert):                            ~3.000 Tokens
  + Agent-Body:                                                 +1.000 Tokens
  + Skill (wenn getriggert):                               +2.400 Tokens
  + Arbeitskontext (File reads, Grep etc.):   +10.000-50.000 Tokens
                                                                        = 16.400-56.400 Tokens (separate Abrechnung)

 
Key Insight: 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.
 

4.5 Kosten eines MCP-Calls

 

Fixkosten (immer geladen):
 12 RAG-Wissen Tools × ~80 Wörter:             ~960 Tokens
 
Pro Aufruf:
  Tool-Call:                                                              ~50 Tokens
  + Ergebnis (3 Chunks):                          +500-1.500 Tokens
  + Ergebnis (10 Chunks):                     +1.500-4.000 Tokens
                                                                   = 550-4.050 Tokens pro Call

 

 
5. Architekturprinzipien

 
Aus der Optimierung eines 10-Projekte-Setups ergeben sich folgende Prinzipien:

 
Prinzip 1: Metadaten-Sparsamkeit

 
Jede Erweiterung hat Fixkosten — ihre Beschreibung im Context. Bei 74 Skills sind das ~7.400 Tokens, unabhängig davon ob sie genutzt werden.
 
Regel: Nur Skills/Agents/MCP-Tools aktivieren, die für die aktuelle Projektgruppe relevant sind. Das `enabledPlugins`-Feld in `settings.json` steuert dies zuverlässig.

 
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/` — und wird nur geladen, wenn Claude es explizit braucht.
 
Faustregel: Wenn ein Entwickler die Information in 80% der Fälle nicht braucht, gehört sie in eine Reference-Datei.

 
Prinzip 3: Agent-Delegation für Context-Isolation

 
Aufwendige Recherchen (Codebase-Exploration, Multi-File-Analyse) gehören in Agents, nicht in den Hauptkontext. Der Agent verbraucht seine eigenen Tokens und liefert nur das Ergebnis zurück.
 
Regel: Wenn eine Aufgabe >5.000 Tokens Arbeitskontext braucht, an einen Agent delegieren.

 
Prinzip 4: MCP für Live-Daten, Skills für statisches Wissen

 
MCP-Server liefern aktuelle Daten (Datenbankabfragen, API-Calls). Skills liefern stabiles Prozesswissen (Patterns, Checklisten, Konfigurationen).
 
Anti-Pattern: Einen MCP-Server bauen, der statische Dokumentation zurückgibt (dafür gibt es Skills). Oder einen Skill schreiben, der Live-Daten enthält, die veralten (dafür gibt es MCP).

 
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. Nicht jedes Projekt braucht jede Erweiterung:

 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

 
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.
 

Stand: März 2026