Ein Berliner DevOps-Team migriert 43 Microservices auf Kubernetes. Mitten im Refactoring fragt ein Entwickler Claude Code nach dem Status eines Sentry-Alerts, der seit zehn Minuten feuert. Ohne den Tab zu wechseln oder einen Link zu kopieren, greift das Tool direkt auf die Sentry-API zu, liest die Stacktraces, korreliert sie mit dem geänderten Code und schlägt einen Fix vor.
Ermöglicht wird das durch das Model Context Protocol (MCP), eine offene Schnittstelle, die Claude Code mit externen Systemen verbindet und es statt isoliert in der Kommandozeile zu arbeiten zu einem Knotenpunkt macht, der Datenbanken abfragt, Tickets aktualisiert und Monitoring-Daten ausliest. MCP ist eine der Technologien, die Claude Code von einem cleveren Textgenerator zu einem arbeitenden Agenten machen.
Dieser Teil behandelt drei fortgeschrittene Themen: das Model Context Protocol und seine praktische Integration, die Delegation an Subagenten für parallele Aufgabenbearbeitung sowie Prompt Engineering, das über einfache Anweisungen hinausgeht. Dazu kommen Skills, Plugins und Hooks, also die Werkzeuge, mit denen Teams Claude Code an ihre Workflows anpassen.
Model Context Protocol: Claude Code mit der Welt verbinden
Anthropic veröffentlichte das Model Context Protocol im November 2024 als offenen Standard [1]. Kernidee: ein einheitliches Protokoll, über das AI-Modelle mit beliebigen Datenquellen und Werkzeugen kommunizieren können. MCP folgt einer Client-Server-Architektur. Claude Code fungiert als Client, in der MCP-Terminologie Host genannt, der sich beim Start automatisch mit den konfigurierten MCP-Servern verbindet und deren Tools dem Modell bereitstellt. Jeder Server stellt definierte „Tools“ bereit, also Funktionen, die das Modell aufrufen kann.
Vergleichbar mit USB, wo vor der Standardisierung jedes Gerät seinen eigenen Anschluss und seinen eigenen Treiber brauchte, vereinheitlicht MCP die Verbindung zwischen AI-Tool und externem System. Ein MCP-Server für PostgreSQL stellt Tabellen und Queries bereit, einer für GitHub bietet Repositories, Issues und Pull Requests an, und welche API dahintersteht, spielt für Claude Code keine Rolle.
Konfiguriert wird über eine JSON-Datei im Projektverzeichnis oder global unter ~/.claude/, wobei ein typischer Eintrag den Namen des Servers, den Startbefehl (meist ein npx- oder uvx-Kommando) und optionale Umgebungsvariablen für Authentifizierung enthält. Beim Sessionstart lädt Claude Code die konfigurierten Server automatisch und beendet sie beim Schließen der Session wieder.
Mittlerweile existieren über 10.000 MCP-Server-Implementierungen [2], deren Qualität erheblich variiert, von produktionsreifen Lösungen bis zu experimentellen Projekten. Sorgfalt bei der Auswahl ist Pflicht, denn ein instabiler MCP-Server kann eine gesamte Session zum Absturz bringen.
Am besten zeigt sich der Nutzen anhand eines Beispiels. Ohne MCP muss ein Entwickler, der einen Datenbankfehler untersucht, manuell zwischen Terminal, pgAdmin und Sentry hin und her wechseln, Stacktraces kopieren und in Claude Code einfügen. Mit konfigurierten MCP-Servern für PostgreSQL und Sentry tippt er: „Analysiere den letzten Sentry-Alert und prüfe, ob die betroffene Query noch zum aktuellen Schema passt.“ Claude Code erledigt den Rest.
Welche MCP-Server lohnen sich wirklich?
Aus den Tausenden verfügbaren Servern haben sich in der Praxis zehn als besonders nützlich für Entwicklerteams erwiesen. Geordnet nach Use-Case:
Offizielle Server von Anthropic, erkennbar am Präfix modelcontextprotocol/, sind in der Regel stabiler und besser gewartet als Community-Projekte. In einem Berliner Fintech-Projekt berichten Entwickler, dass die Kombination aus GitHub- und Linear-Server die tägliche Triage-Arbeit von 45 Minuten auf unter zehn Minuten reduzierte. Claude Code las offene Issues, verglich sie mit aktuellen PRs und schlug Priorisierungen vor.
Ehrlich gesagt halte ich den Hype um MCP-Server für berechtigt, die Erwartung aber, dass jedes Team sofort zehn Server konfigurieren sollte, für überzogen. Zwei oder drei reichen für den Anfang, und selbst die sollten erst gelesen werden, bevor man Schreibzugriffe freigibt.
Hier zeigt sich allerdings ein Muster, das sich durch die gesamte MCP-Landschaft zieht: Lesende Zugriffe funktionieren gut, aber schreibende Operationen wie Tickets erstellen oder PRs mergen erfordern deutlich mehr Vorsicht und Absicherung, was viele Teams unterschätzen. Ein falsch konfigurierter Slack-Server, der im Namen des Entwicklers Nachrichten versendet, kann schnell peinlich werden.
Wann lohnt sich ein eigener MCP-Server?
Gängige Tools sind durch Standardserver abgedeckt. Aber was ist mit dem internen Wiki, der proprietären API oder der Legacy-Datenbank, die seit 2011 im Einsatz ist? Hier lohnt sich ein eigener MCP-Server.
Für über zehn Sprachen existiert mittlerweile ein MCP-SDK, darunter Python, TypeScript, Java, Go und C# [3]. Ein minimaler Server besteht aus drei Komponenten: einem Transport-Layer (stdio oder Streamable HTTP, das seit 2025 den älteren SSE-Transport ablöst [4]), einer Liste verfügbarer Tools mit JSON-Schema-Beschreibungen und den Handler-Funktionen, die bei Aufruf ausgeführt werden. In Python lassen sich mit dem mcp-SDK in etwa 50 Zeilen Code ein Server aufsetzen, der eine REST-API wrappen und Claude Code deren Endpunkte zur Verfügung stellen kann.
Ein eigener Server macht Sinn bei drei Szenarien: wenn das Team mit einem internen System arbeitet, für das kein öffentlicher Server existiert, wenn die vorhandenen Server nicht die benötigte Granularität bieten (etwa Schreib-Zugriff auf bestimmte Tabellen, aber nicht auf andere), oder wenn Compliance-Anforderungen verlangen, dass Daten den eigenen Server nicht verlassen.
Für die meisten internen APIs bleibt der Aufwand bei ein bis zwei Tagen Entwicklungszeit überschaubar. Weniger im Code als im Tool-Design liegt die eigentliche Herausforderung: Welche Funktionen soll das Modell aufrufen können? Wie granular sollen die Parameter sein? Klare, präzise Tool-Beschreibungen entscheiden darüber, ob Claude Code den Server effektiv nutzt oder daran vorbeiredet.
Was bringen Subagenten und parallele Aufgabenbearbeitung?
In einem Dresdner E-Commerce-Projekt wollte das Team die Stripe-SDK-Version von v2 auf v3 aktualisieren. Claude Code zerlegte die Aufgabe in vier parallele Subagenten: einer analysierte die bestehenden Stripe-Webhooks, einer passte die Checkout-Session-Logik an, einer aktualisierte die Fehlerbehandlung und ein vierter schrieb die fehlenden Integrationstests. Statt der geschätzten drei Tage dauerte die Migration vier Stunden, wobei das Review der generierten Änderungen weitere zwei Stunden beanspruchte, weil die Subagenten an zwei Stellen widersprüchliche Error-Codes verwendet hatten.
Möglich wird das durch zwei eingebaute Mechanismen, das Task-Tool und das Agent-Tool, mit denen Claude Code bei komplexen Aufgaben Teile der Arbeit an eigenständige Subagenten delegieren kann, statt alles sequenziell im Hauptprozess abzuarbeiten.
Mit dem Task-Tool lassen sich eigenständige Unteraufgaben erstellen. Claude Code soll etwa eine API-Migration durchführen und zerlegt die Arbeit in fünf Tasks: Endpunkte analysieren, Datenmodelle anpassen, Tests schreiben, Dokumentation aktualisieren, Deployment-Konfiguration prüfen. Sequenziell arbeitet es jeden Task mit eigenem Kontext und eigenem Ergebnis ab, sodass Fehler in einem Task nicht automatisch auf die übrigen durchschlagen.
Einen Schritt weiter geht das Agent-Tool, das einen eigenständigen Subprozess mit eigenem Kontextfenster startet. Solange wartet der Hauptprozess, bis der Subagent sein Ergebnis liefert. Parallel laufende Subagenten sind möglich: Claude Code kann drei gleichzeitig losschicken, einen für die Frontend-Recherche, einen für das Backend, einen für die Testabdeckung. Vom Hauptagenten erhalten sie eine Aufgabenbeschreibung, aber nicht sein gesamtes Wissen über das Projekt.
Begrenzt wird diese Architektur durch das Token-Budget. Jeder Subagent verbraucht Tokens, und eine komplexe Aufgabe mit fünf Subagenten kann 50.000 bis 80.000 Tokens verbrauchen. Mit Sonnet kostet ein solcher Durchlauf unter einem Dollar, mit Opus zwischen ein und drei Dollar [5]. Das ist kein Spielgeld. Teams, die intensiv Subagenten einsetzen, berichten von monatlichen API-Kosten zwischen 400 und 600 Dollar. Beim Max-Plan (100 oder 200 Dollar monatlich, je nach Stufe) stößt man bei exzessiver Nutzung schnell an das inkludierte Kontingent.
Häufig untergeht in der Euphorie um Multi-Agent-Workflows ein ökonomischer Punkt: Technisch funktioniert die Parallelisierung, aber jedes Team muss die Abwägung selbst treffen. Ein Senior-Entwickler, der 90 Euro pro Stunde kostet, amortisiert die Token-Kosten schnell, wenn der Subagent ihm 20 Minuten Recherche spart. Für Junior-Entwickler mit niedrigerem Stundensatz sieht die Rechnung anders aus.
Was unterscheidet Prompt Engineering für agentic AI?
Prompt Engineering für Claude Code unterscheidet sich grundlegend vom Prompting in ChatGPT oder ähnlichen Chatbots. Bei einem Chatbot formuliert man eine Frage und erhält eine Antwort, während man bei Claude Code einen Arbeitsauftrag formuliert und ausgeführte Änderungen am Code erhält, die sich über mehrere Dateien und Module erstrecken können.
Dieser Unterschied hat Konsequenzen. Vage Prompts in ChatGPT liefern vage Antworten, kein Schaden entstanden. Vage Prompts in Claude Code dagegen können Dutzende Dateien ändern, Tests brechen und Abhängigkeiten zerstören, weshalb Präzision beim Prompting direkt mit der Qualität des Ergebnisses korreliert.
Drei Beispiele verdeutlichen, was einen wirksamen Prompt von einem wirkungslosen unterscheidet.
Wie ein präziser Prompt eine Suchfunktion implementiert
Wer Claude Code auffordert „Füge eine Suchfunktion hinzu“, erhält Rückfragen, Rateversuche oder etwas Unbrauchbares. Wer stattdessen schreibt: „Implementiere eine Volltextsuche für die Blog-Artikel, nutze den bestehenden search-index.json als Datenquelle, clientseitig in Vanilla JS ohne externe Abhängigkeiten, maximal zehn Ergebnisse sortiert nach Relevanz, getestet mit dem bestehenden Jest-Setup“, bekommt in den meisten Fällen eine funktionierende Lösung beim ersten Durchlauf. Dateipfade, Technologie-Stack und Erfolgskriterien machen den Unterschied.
Vom vagen Wunsch zur gezielten Zerlegung
Beim Refactoring lässt sich die Qualitätssteigerung in drei Stufen beobachten. Vage: „Refactore die User-Klasse.“ Besser: „Zerlege die UserService-Klasse in kleinere Module.“ Präzise: „Die UserService-Klasse in src/services/user.ts hat 847 Zeilen und mischt Authentifizierung, Profilmanagement und Benachrichtigungen. Extrahiere drei separate Services: AuthService, ProfileService, NotificationService. Behalte die bestehende API-Signatur bei. Alle 23 bestehenden Tests in tests/user.test.ts müssen weiterhin grün sein.“ Erst die dritte Variante gibt Claude Code genug Kontext, um die Zerlegung korrekt durchzuführen, ohne bestehende Tests zu brechen.
Was unterscheidet nutzlose von wirksamen Test-Prompts?
Beim Bug-Fixing und Code-Review gilt dasselbe Prinzip: konkrete Dateipfade, Commit-Hashes und spezifische Prüffragen statt vager Aufforderungen. „Der Login funktioniert nicht“ liefert Rätselraten, während „Beim Login auf /api/auth/login erhalten Nutzer einen 401-Fehler seit Commit a3f8c2d, prüfe die Auth-Middleware in src/middleware/auth.ts“ sofort in die richtige Richtung lenkt.
Eindeutig ist das Muster. Effektive Prompts benennen konkrete Dateien, definieren Erfolgskriterien und schränken den Handlungsraum ein. Sie lesen sich eher wie ein Ticket in Linear als wie eine Frage an einen Chatbot.
Vier Prinzipien fassen die Unterschiede zusammen.
- Kontext statt Abstraktion: Dateipfade, Funktionsnamen und Commit-Hashes nennen
- Constraints definieren: Was soll Claude Code NICHT tun? Welche Dateien sind tabu?
- Erfolgskriterien formulieren: Testabdeckung, Performance-Ziele, API-Kompatibilität
- Scope begrenzen: Lieber drei präzise Prompts als ein vager Gesamtauftrag [6]
Teams, die interne Prompt-Bibliotheken pflegen und bewährte Formulierungen teilen, erzielen konsistent bessere Ergebnisse. Bei einem Hamburger Logistik-Startup dokumentiert das Team seine Prompts in einem Confluence-Wiki. Neue Teammitglieder starten nicht bei null, sondern mit erprobten Templates. Einarbeitungszeit sinkt, die Varianz in der Code-Qualität ebenso.
Wie passen Teams Claude Code an ihre eigenen Workflows an?
Gute Prompts sind ein Anfang, aber sie bei jedem Aufruf neu zu tippen, ist Zeitverschwendung. Claude Code bietet drei Mechanismen, um wiederkehrende Workflows zu standardisieren: Custom Slash Commands, Skills und Plugins.
Custom Slash Commands
Slash Commands sind Markdown-Dateien im Verzeichnis .claude/commands/ innerhalb eines Projekts, wobei jede Datei einen Befehl definiert, den Teammitglieder mit / aufrufen können. Eine Datei .claude/commands/review-pr.md enthält beispielsweise den Prompt für ein standardisiertes Code Review, das der Entwickler mit /review-pr startet und Claude Code nach dem definierten Workflow abarbeitet [10].
So simpel das klingt, so erheblich ist der Effekt. Ein Münchner SaaS-Unternehmen mit 14 Entwicklern führte fünf Custom Commands ein: /review-pr, /write-tests, /update-docs, /check-security und /explain-code. Nach drei Monaten berichtete das Team von 30 Prozent weniger Rückfragen in Code Reviews und einer Halbierung der Zeit für Dokumentationsaktualisierungen. Nicht die Technologie war der Schlüssel, sondern die Standardisierung. Alle Entwickler nutzten die gleichen Prüfkriterien.
Skills und Plugins
Skills erweitern Custom Commands um ausführbare Logik: Während ein Slash Command nur einen Prompt-Text bereitstellt, kann ein Skill zusätzliche Kontextinformationen laden, Bedingungen prüfen oder Ergebnisse nachbearbeiten, weshalb Anthropic sie als Baustein für organisationsweite Standardisierung positioniert [8].
Plugins gehen noch weiter und erlauben es Unternehmen, Claude Code mit internen Systemen zu verbinden und Verhaltensregeln zentral zu definieren: etwa dass alle generierten SQL-Queries einen bestimmten Präfix verwenden, dass Code-Änderungen an bestimmten Verzeichnissen automatisch ein Review-Flag erhalten oder dass vertrauliche Dateien nie gelesen werden.
Für DACH-Teams mit strengen Compliance-Anforderungen bieten Plugins einen interessanten Hebel, weil sich Regeln damit nicht als Anweisung an Entwickler formulieren lassen, sondern als technische Schranke direkt in der Toolkonfiguration. Große DACH-Versicherer evaluieren laut Branchenberichten genau diesen Ansatz für die Steuerung von AI-Coding-Tools in regulierten Bereichen.
Hooks: Automatische Qualitätssicherung im Hintergrund
Aus Wien schildert ein Fintech-Startup einen Fall, der das Problem greifbar macht. Vor der Einführung von Hooks landeten regelmäßig Claude-Code-Änderungen im Review, die ESLint-Fehler enthielten oder Tests brachen. Konfiguriert wurden drei Hooks: einer für ESLint nach jedem Dateischreiben, einer für pytest nach Änderungen an Python-Dateien und ein dritter, der Schreibzugriffe auf das Verzeichnis /config blockiert. Fehlerhafte PRs sanken um 60 Prozent innerhalb von vier Wochen [7].
Hooks sind der unsichtbare Sicherheitsgurt für AI-generierte Code-Änderungen, vergleichbar mit Git-Hooks, nur dass sie spezifisch auf Claude-Code-Aktionen reagieren. Sie laufen automatisch vor oder nach bestimmten Aktionen und können Änderungen validieren, blockieren oder ergänzen. Hooks sind für mich das am meisten unterschätzte Feature von Claude Code.
Konfiguriert wird in der Datei .claude/settings.json im Projektverzeichnis, wo drei Hook-Typen zur Verfügung stehen: PreToolUse (läuft vor jeder Tool-Ausführung), PostToolUse (läuft danach) und Notification (bei bestimmten Ereignissen), wobei jeder Hook einen Matcher (welches Tool betroffen ist) und ein Kommando (was ausgeführt werden soll) definiert.
Praktische Anwendungen gibt es viele. Nach jedem Dateischreiben kann ein PostToolUse-Hook automatisch den Linter ausführen. Vor dem Ausführen von Bash-Befehlen prüft ein PreToolUse-Hook, ob der Befehl auf der Allowlist steht. Nach jeder Änderung an Testdateien kann ein weiterer Hook die Test-Suite laufen lassen.
Hooks lösen damit ein Problem, das viele Teams mit AI-Code-Generierung haben: die nachträgliche Qualitätssicherung, die normalerweise manuell nach jeder Claude-Code-Session stattfinden müsste, geschieht jetzt automatisch und senkt die Hemmschwelle, Claude Code auch für größere und riskantere Änderungen einzusetzen.
MCP, Subagenten und Hooks zusammen ergeben ein Bild: Claude Code ist konfigurierbar wie ein Build-System. Für einfache Aufgaben reicht die Grundinstallation. Erst die Anpassung an den konkreten Projektkontext schafft den eigentlichen Wert.
Wo liegen die Grenzen dieser Techniken?
So mächtig MCP, Subagenten und Prompt Engineering auch sind, sie haben klare Einschränkungen, von denen die Zuverlässigkeit am schwersten wiegt.
MCP-Server sind Software mit Bugs, Abstürzen und Verbindungsabbrüchen. Ein PostgreSQL-Server, der mitten in einer Query abbricht, hinterlässt Claude Code ohne Kontext. Meistens reagiert das Tool verständig und versucht es erneut. Aber „meistens“ ist keine Garantie. Fehlertoleranz von MCP-Integrationen gilt in der Fachwelt als „noch nicht ausgereift für sicherheitskritische Anwendungen“. Wer MCP in regulierten Umgebungen einsetzt, braucht belastbare Fallback-Mechanismen.
Subagenten teilen ein anderes Problem: Sie operieren mit reduziertem Kontext, und wenn ein Subagent eine Datei ändert, die ein anderer Subagent gerade liest, entstehen Race Conditions. Anthropic kennt dieses Problem und bietet bereits Mechanismen wie sequenzielle Subagenten-Ausführung und isolierte Worktrees an, auch wenn eine vollständige Lösung für parallele Schreibzugriffe noch aussteht.
Prompt Engineering hat eine weniger offensichtliche Grenze: Determinismus. Bei wiederholter Ausführung produziert der gleiche Prompt unterschiedliche Ergebnisse, wie ein Test mit identischem Prompt auf dem gleichen Codebase zeigte, bei dem Claude Code in zehn Durchläufen sieben verschiedene Lösungsansätze lieferte. Für explorative Aufgaben ist das akzeptabel, für reproduzierbare Build-Prozesse dagegen nicht, weshalb Teams, die Claude Code in CI/CD-Pipelines einbinden wollen, diesen Punkt berücksichtigen sollten.
Und dann gibt es die Sicherheitsfrage: MCP-Server mit Schreibzugriff auf Datenbanken oder APIs sind potenzielle Angriffsvektoren. Kompromittierte MCP-Server könnten Claude Code dazu bringen, Daten zu exfiltrieren oder Systeme zu manipulieren. Anthropic empfiehlt deshalb, MCP-Server nur in isolierten Umgebungen zu betreiben und den Zugriff auf das Minimum zu beschränken [9]. Überraschend wenige Teams befolgen diesen Rat. Bekannt ist das Least-Privilege-Prinzip den meisten Entwicklern, aber bei MCP-Servern wenden sie es nicht an, weil der Komfortgewinn zu verlockend ist.
Ausblick
MCP, Subagenten, Prompt Engineering, Skills und Hooks bilden zusammen das fortgeschrittene Werkzeugset für Claude Code, wobei jede dieser Techniken ein spezifisches Defizit adressiert: MCP überbrückt den Informationsgraben zu externen Systemen, Subagenten parallelisieren Arbeit, Prompt Engineering erhöht die Trefferquote, und Hooks sichern die Qualität ab. Zusammen verwandeln sie Claude Code in ein konfigurierbares System, das sich an unterschiedliche Teamsituationen anpassen lässt.
Nicht in der Technologie liegt die größte Herausforderung, sondern im Wissensmanagement: welche MCP-Server konfiguriert das Team, welche Prompt-Patterns funktionieren, welche Hooks sind aktiv, und wie hält man dieses Wissen aktuell, wenn das Team wächst? Dokumentation, Wissenstransfer und Pflege entscheiden darüber, ob ein Unternehmen Claude Code als individuelles Entwicklerwerkzeug nutzt und damit das meiste Potenzial verschenkt, oder ob es eine teamweite Infrastruktur aufbaut.
In meiner Erfahrung trennt sich bei den fortgeschrittenen Techniken die Spreu vom Weizen: Teams, die CLAUDE.md-Dateien pflegen, Slash Commands teilen und Hooks konfigurieren, berichten von signifikanten Produktivitätsgewinnen, während Teams, die nur ad-hoc prompten, hinter ihren Möglichkeiten zurückbleiben.
Wer Claude Code ernsthaft in ein Entwicklerteam integrieren will, kommt an den hier beschriebenen Techniken nicht vorbei. Niedrig ist die Einstiegshürde: Ein erster MCP-Server lässt sich in einer Stunde konfigurieren, ein Satz Slash Commands in einem Nachmittag. Innerhalb von Tagen zeigt sich die Rendite.
All diese Techniken haben aber einen blinden Fleck: die Frage nach Kosten und Sicherheit. Was kostet Claude Code im Team-Einsatz wirklich? Wie sicher ist der generierte Code? Und was bedeutet DSGVO-Konformität für ein Tool, das Code an US-Server sendet? Antworten liefert der nächste Teil.
Weiter mit Teil 4: Was kostet Claude Code und wie sicher ist der generierte Code?
Quellenverzeichnis
[1] Anthropic: „Introducing the Model Context Protocol“, anthropic.com/news/model-context-protocol, November 2024.
[2] MCP Registry, registry.modelcontextprotocol.io, Stand März 2026.
[3] MCP Specification: Transports, modelcontextprotocol.io/specification/2025-03-26/basic/transports, Stand 2025.
[4] Auth0 Blog: „Why MCP’s Move Away from SSE Simplifies Security“, auth0.com/blog/mcp-streamable-http, 2025.
[5] Anthropic: „Claude Code Pricing“, docs.anthropic.com/en/docs/about-claude/pricing, Stand März 2026.
[6] Anthropic: „Claude Code Best Practices“, code.claude.com/docs/en/best-practices, Stand 2026.
[7] Anthropic: „Claude Code Hooks Reference“, code.claude.com/docs/en/hooks, Stand 2026.
[8] Anthropic: „Claude Code Skills/Plugins“, code.claude.com/docs/en/skills, Stand 2026.
[9] MCP Security Best Practices, modelcontextprotocol.io/specification/draft/basic/security_best_practices, Stand 2025.
[10] Anthropic: „Claude Code Slash Commands“, code.claude.com/docs/en/slash-commands, Stand 2026.