Sub-Agent oder Skill oder MCP-Tool, was waehlst Du wann

Drei Wege Claude Code zu erweitern, die alle in der Doku stehen und alle nuetzlich klingen. Sub-Agent, Skill, MCP-Tool. Ich hab am Anfang vom Build-Out unserer Fleet alle drei in der falschen Reihenfolge gebaut. Erst ein MCP-Tool für etwas das eine Skill sein müsste, dann einen Sub-Agent für etwas das ein MCP-Tool gehört hätte. Zwei Tage Migration später war klar, dass das Entscheidungs-Problem größer ist als das Build-Problem. Hier ist der Guide den ich damals gebraucht hätte.

1. Verstehen was die drei eigentlich sind

Eine Skill ist eine Markdown-Datei mit Frontmatter. Du legst sie unter ~/.claude/skills/<name>/SKILL.md ab. Claude scannt bei jedem Prompt alle Skill-Beschreibungen und entscheidet selbst ob er eine lädt. Wenn ja, kommt der Body als Kontext rein. Kein Code, keine API, nur Text der Claude sagt wie er etwas tun soll.

Ein Sub-Agent ist auch eine Markdown-Datei, aber Du rufst ihn explizit auf. Per Task-Aufruf, per Slash-Command oder weil Du im Prompt sagst "delegier das an den Reviewer-Agent". Er kriegt einen eigenen Context, eine eigene Mini-Konversation, und gibt Dir am Ende ein Ergebnis zurück.

Ein MCP-Tool ist Code. Echter Code, in TypeScript oder Python, der als Server läuft. Claude ruft das Tool über JSON-RPC auf, kriegt strukturierte Daten zurück, kann das Ergebnis weiterverarbeiten. Tools können DB-Queries machen, HTTP-Calls absetzen, Files schreiben, alles was Code halt kann.

Drei verschiedene Layer. Skill ist Wissen. Sub-Agent ist Workflow. MCP-Tool ist Fähigkeit. Das vermischt sich in der Praxis aber dauernd, deshalb der Rest vom Playbook.

2. Entscheidungsfrage Nummer eins, brauchst Du Daten von ausserhalb

Das ist die wichtigste Frage und sie kommt zuerst. Wenn die Lösung von extern was lesen oder schreiben muss, ist es ein MCP-Tool. Nicht verhandelbar. Skills können das nicht, Sub-Agents auch nicht direkt. Beide haben nur Zugriff auf das was Claude Code selbst kann (Read, Write, Bash, WebFetch und so weiter).

Konkretes Beispiel aus unserer Fleet. Wir wollten dass Claude unsere Postgres-DB lesen kann für Memory-Lookups. Erster Versuch war eine Skill die sagte "wenn nach Memory gefragt wird, führe psql-Bash-Command aus". Das hat funktioniert aber war fragil. Bash-Escape-Hoelle, kein Schema-Wissen, nichts strukturiert. Nach einer Woche umgebaut zu einem MCP-Tool das echte SQL macht und typisierte Resultate zurückgibt. Die Skill ist geloescht.

Faustregel: wenn die Aktion eine API, eine DB, einen Service oder einen Filesystem-Pfad braucht den Claude allein nicht zuverlaessig findet, MCP-Tool.

3. Entscheidungsfrage Nummer zwei, ist es Wissen oder Workflow

Wenn keine externe Daten nötig sind, geht es weiter. Wissen oder Workflow.

Wissen heißt: "wenn das Thema X kommt, denk auch an Y und Z". Beispiel: "wenn der User Postgres-Migrations schreiben will, erinnere ihn an Backups vorher und an prisma migrate dev --create-only statt direkt apply". Das ist eine Skill. Markdown-Text, Trigger über Beschreibung, Claude entscheidet selbst.

Workflow heißt: "führe Schritt 1, dann 2, dann 3 aus, am Ende gib mir Y zurück". Das ist ein Sub-Agent. Definierter Input, definierter Output, in der Mitte ein klarer Ablauf.

Wenn Du Dich fragst was Du grad bauen willst und Du es als "wenn X dann erinnere an Y" formulieren kannst, ist es eine Skill. Wenn Du es als "macht das, dann das, am Ende kommt das raus" formulierst, ist es ein Sub-Agent. Wenn Du es ueberhaupt nicht in Worten ausdrücken kannst weil Du nur Daten brauchst, MCP-Tool.

4. Entscheidungsfrage Nummer drei, wie oft passiert das

Skills triggern bei jedem Prompt, der zur Frontmatter passt. Das ist gut wenn Du das oft brauchst. Schlecht wenn es zwei Mal im Monat passiert, dann sitzt der Skill-Body als Latent-Kontext rum und kostet Tokens für nichts.

Sub-Agents triggern nur wenn explizit aufgerufen. Das ist perfekt für "ich mach das jeden Dienstag" oder "ich rufe das bei jedem PR auf". Du tippst den Namen und es läuft.

MCP-Tools werden registriert in der Tool-Liste und Claude sucht sich raus was er braucht. Skaliert gut bis viele Tools, aber bei kleiner Liste merkt man wenig Unterschied.

Konkrete Zahl aus unserer Praxis. Eine "Memory-Query"-Skill triggerte bei ungefähr 40 Prozent unserer Prompts (wir reden viel über Memory). Das war zuviel, der Kontext wurde voll. Migration zu einem MCP-Tool das nur bei expliziter Suche aufgerufen wird. Heute ist es vier mal die Stunde statt 40 mal. Tokens halbiert.

5. Entscheidungsfrage Nummer vier, kann es ohne Strukturwissen funktionieren

Skills bekommen Frei-Text rein und geben Frei-Text raus. Sub-Agents auch. Beide sind im Kern Conversational. Wenn die Antwort "ja, lies das, denk drueber nach, formulier ein Ergebnis" ist, reicht das.

Wenn aber die Antwort heißt "lies aus Tabelle X den User mit ID 42, hol seine letzten zehn Bestellungen, summiere und gib JSON zurück", dann ist es klar MCP-Tool. Struktur und Typen.

Faustregel: braucht der Caller (Claude oder ein anderes Tool) das Ergebnis als parsbares JSON, MCP-Tool. Reicht ein Markdown-Block, Skill oder Sub-Agent.

6. Die Falle, eine Skill als verkappten Sub-Agent bauen

Das war mein erster großer Fehler. Ich hatte eine Skill mit einem 200-Zeilen-Body der genau einen Workflow beschrieb. "Wenn der User nach Blog-Post-Ideen fragt, mach Schritt 1, dann Schritt 2, dann Schritt 3". Klassischer Sub-Agent, falsch gebaut.

Das fliegt auf wenn Du es benutzt. Skills triggern automatisch, also kam der Body manchmal auch in unpassenden Kontexten rein. Performance hat gelitten. Sub-Agent hat das gelöst weil er nur dann läuft wenn er explizit gerufen wird.

Symptom dass Du das machst: Deine Skill hat Step-1, Step-2, Step-3 Headlines. Dann ist es ein Sub-Agent. Migrieren.

7. Die Falle, einen Sub-Agent als verkapptes MCP-Tool bauen

Das war Fehler Nummer zwei. Sub-Agent der per Bash-Tool psql aufrief und das Ergebnis parsen sollte. Das ging für einfache Queries und schlug bei allem mit Joins oder Anfuehrungszeichen fehl. Migration zu MCP-Tool mit echtem Prisma-Client. Vier Stunden Migration, danach lief alles.

Symptom dass Du das machst: Dein Sub-Agent benutzt im Body sehr viel Bash, sehr viel Pattern-Match auf String-Ausgaben, und fällt regelmäßig auf Edge-Cases um. Dann gehört der Logik-Kern in ein MCP-Tool.

8. Die seltene Anti-Falle, ein MCP-Tool das eine Skill sein sollte

Selten aber existiert. Du hast einen MCP-Server mit einem Tool das einfach nur einen Markdown-Text zurückgibt mit Anweisungen. "Tool 'review-checklist' returns: 1. Check imports, 2. Check tests, 3. Check types". Das ist eine Skill. Code dafür ist Overhead.

Symptom: Dein Tool macht keinen API-Call, keine DB-Query, kein File-IO. Es returnt nur Konstanten oder Templates. Loeschen, als Skill neu anlegen.

9. Beispiele aus echten Fleet-Setups

Drei konkrete Cases aus den letzten Wochen, damit Du Muster siehst.

Case A. "Wenn User über Pricing redet, erinnere an Stripe-Live-Mode-Falle." Skill. Pure Wissensregel, kein Workflow, keine Daten.

Case B. "Schreib mir aus diesem PR einen Release-Note-Eintrag." Sub-Agent. Klarer Input (PR-URL), klarer Output (Markdown-Block), definierter Workflow in der Mitte.

Case C. "Sag mir wieviele Pageviews die Academy gestern hatte." MCP-Tool. Braucht Umami-API-Call, braucht Auth, gibt strukturierte Zahl zurück.

Case D. "Pruef ob diese Idee mit unserer Strategy uebereinstimmt." Sub-Agent mit MCP-Tools die er aufruft. Multi-Layer. Sub-Agent für den Workflow, MCP-Tools für den Datenzugriff (Strategy-Memory lesen, Decisions checken).

10. Reihenfolge für Solo-Founder, was Du zuerst lernst

Wenn Du jetzt nur das Wochenende Zeit hast, ist die Reihenfolge.

Erst Skills bauen. Cheapest, schnellster Lerneffekt, kein Code. Zwei bis drei Skills die Du oft brauchst (Code-Review-Style, Blog-Post-Style, Postgres-Vorsicht). Du verstehst dann wie Trigger funktionieren und wo die Grenzen sind.

Dann ein Sub-Agent. Nimm einen Workflow den Du jede Woche machst. Ticket-zu-PR-Title oder Voicenote-zu-Tasks. Eine halbe Stunde Build, sofortiger Nutzen.

Dann erst MCP-Tool. Wenn Du jetzt anstößt dass Du echte Daten brauchst, ist die Frage klar. Dann lohnt sich der TypeScript-Setup-Aufwand. Vorher nicht.

Drei Wege, klar verteilt. Wenn Du das im Kopf hast, sparst Du die Migrations-Tage die ich gebraucht habe.

Wenn Du das jetzt direkt bauen willst, fang an mit dem Playbook Erste eigene Skill in 30 Minuten. Wenn Sub-Agent dran ist, schau Dein erster Sub-Agent in 30 Minuten. Für MCP-Tool den Ersten MCP-Server in 90 Minuten.