Claude Code für Engineering-Teams: MCP-Einrichtung und Workflow-Integration
Claude Code stieg von 4 % Nutzung unter Entwicklern im Mai 2025 auf 63 % im Februar 2026. Der größte Teil dieses Wachstums geschah organisch: Ein Entwickler probiert es aus, findet es gut, und es spricht sich herum. Was sich nicht herumspricht, ist die Konfiguration.
So entsteht Konfigurationsdrift. Unterschiedliche CLAUDE.md-Dateien (oder gar keine). Unterschiedliche MCP-Server oder gar keine. Unterschiedliche Tool-Berechtigungen. Kein gemeinsamer Codebase-Kontext. Alle nutzen technisch gesehen Claude Code, und die Ergebnisse variieren enorm.
Dieser Leitfaden behandelt die Konfigurationsebene: Wie Sie aus einer Ansammlung individueller Installationen ein konsistentes Setup machen, von dem das gesamte Team profitiert.
Was ein verwaltetes Team-Setup tatsächlich bedeutet#
Die Lücke zwischen Einzelnutzer und Team: Warum Konfigurationsdrift die Produktivität ruiniert#
Ein Entwickler, der Claude Code richtig eingerichtet hat — mit einer soliden CLAUDE.md, ein paar MCP-Servern, die an die tatsächlich genutzten Tools angebunden sind, und einigen eigenen Skills für wiederkehrende Aufgaben — erzielt wirklich gute Ergebnisse. Ein Entwickler im selben Team, der die Standardinstallation ausgeführt und nie etwas angepasst hat, bekommt inkonsistente, kontextarme Ausgaben.
Beide werden Ihnen sagen, dass sie Claude Code nutzen. Der Unterschied zwischen ihnen ist groß — und er potenziert sich schnell in einem zehnköpfigen Team.
73 % der Engineering-Teams nutzen mittlerweile täglich KI-Coding-Tools, gegenüber 41 % im Jahr 2025 (Developer Survey 2026, 15.000 Entwickler). Die Teams mit konsistenten Ergebnissen behandeln Konfiguration als gemeinsame Aufgabe, nicht als individuelle Vorliebe.
Die drei Ebenen, die standardisiert werden müssen: Kontext, Tools und Verhalten#
Ein korrekt standardisiertes Claude Code Team-Setup umfasst drei Ebenen:
- Kontext -- Was weiß Claude über Ihre Codebase? (CLAUDE.md)
- Tools -- Womit kann Claude sich verbinden? (MCP-Server über .mcp.json und managed-mcp.json)
- Verhalten -- Was darf Claude tun und wie tut es das? (Berechtigungen, Skills, Enterprise-Richtlinien)
Die meisten Teams, die sagen „Wir nutzen Claude Code", haben Ebene eins teilweise konfiguriert und die Ebenen zwei und drei gar nicht angefasst. Dieser Leitfaden behandelt alle drei.
Worauf Sie hinarbeiten#
Zielzustand: Jeder Entwickler startet eine Claude-Code-Sitzung mit demselben Projektkontext, denselben angebundenen internen Tools, denselben eigenen Skills und derselben Berechtigungsrichtlinie. Die Konfiguration liegt im Repository und in Ihrem MDM-System — nicht verstreut in Home-Verzeichnissen.
Schritt 1: Ihre CLAUDE.md verfassen#
Was CLAUDE.md bewirkt und wo sie liegt#
CLAUDE.md ist eine Markdown-Datei, die Claude Code beim Sitzungsstart liest. Sie gibt Claude dauerhaftes Wissen über Ihr Projekt, ohne es in jeder Sitzung wiederholen zu müssen.
Sie kann an mehreren Stellen liegen, und Claude lädt sie hierarchisch:
- Root-CLAUDE.md (
/your-repo/CLAUDE.md) -- wird für alle Sitzungen in diesem Repository geladen - Unterverzeichnis-CLAUDE.md -- wird geladen, wenn Claude Code in diesem Verzeichnis arbeitet
- Systemweite CLAUDE.md (
~/.claude/CLAUDE.md) -- wird für alle Sitzungen geladen, unabhängig vom Projekt
Die Root-CLAUDE.md, die in Ihr Repository eingecheckt ist, ist das, was jeder Entwickler automatisch erbt. Diese sollten Sie richtig gestalten.
Was in eine Team-CLAUDE.md gehört#
Stellen Sie sich den Inhalt als den Kontext vor, den ein erfahrener Entwickler am ersten Tag im Kopf hat. Nicht alles, was er weiß — nur das, was ein neues Teammitglied braucht, um vermeidbare Fehler zu vermeiden.
Architekturüberblick. Wie ist das System aufgebaut? Was sind die Hauptkomponenten und Service-Grenzen? Zwei bis vier Absätze reichen in der Regel.
Verzeichnisstruktur. Wo liegen API-Routen? Tests? Konfiguration? Claude findet es durch Erkunden des Dateisystems heraus, aber eine Übersicht spart Zeit und liefert beim ersten Durchlauf genauere Ergebnisse.
Coding-Konventionen. Welche Namenskonventionen nutzt Ihr Team? Welche Patterns sind bevorzugt oder verboten? Welche Linting-Regeln sind nicht verhandelbar?
Testanforderungen. Erwartete Abdeckung. Wo Unit-Tests und wo Integrationstests liegen. Welche Test-Utilities existieren.
Tabu-Bereiche. Was sollte Claude niemals ohne ausdrückliche Anweisung ändern? Migrationen, CI-Konfiguration, Vendor-Code?
Entwicklungs-Workflow. Wie Tests ausgeführt werden. Wie der Dev-Server gestartet wird. Welche Umgebungsvariablen erforderlich sind.
Wie Claude die CLAUDE.md beim Sitzungsstart lädt#
Der Inhalt der CLAUDE.md wird beim Initialisieren in den Kontext des Modells geladen — nicht als Tool-Aufruf oder Datei-Lesevorgang. Er ist in der Sitzung immer präsent, ohne dass der Entwickler darauf verweisen muss.
Die Konsequenz: Halten Sie die Datei fokussiert. Alles in der CLAUDE.md belegt bei jeder Sitzung Platz im Kontextfenster. Eine aufgeblähte Datei, die jeden Sonderfall abzudecken versucht, verwässert das Signal für alles andere. Zielen Sie auf 500-1.500 Wörter mit wirklich nützlichem Kontext.
Praktische CLAUDE.md-Struktur für ein Engineering-Team im Produktivbetrieb#
# [Project Name] -- CLAUDE.md
## What This Is
[2-3 sentences: what the system does, primary stack, who operates it]
## Architecture
[3-4 paragraphs: key components, service boundaries, data flow]
## Directory Structure
[Annotated directory listing of the important paths]
## Development Standards
- Language/framework conventions
- Naming rules
- Patterns to use / patterns to avoid
## Testing
- How to run tests
- Where unit vs integration tests live
- Required coverage for new code
## Do Not Touch Without Explicit Instruction
- [List specific files, directories, or systems]
## Running Locally
[Commands to start dev server, required env vars, dependencies]Schritt 2: Projektbezogene MCP-Server konfigurieren#
MCP-Server-Bereiche: Lokal, Projekt und Enterprise#
Claude Code kennt drei Konfigurationsbereiche für MCP-Server:
- Lokal (benutzerbezogen): Liegt in
~/.claude.json. Betrifft nur diesen Entwickler. Wird nicht ins Repository eingecheckt. - Projektbezogen: Liegt in
.mcp.jsonim Projektstamm. Wird ins Repository eingecheckt. Gilt für alle, die an diesem Projekt arbeiten. - Enterprise (verwaltet): Liegt in einer systemweiten
managed-mcp.json, die per MDM verteilt wird. Gilt für alle Claude-Code-Instanzen auf verwalteten Rechnern.
Für die Standardisierung im Team ist die projektbezogene .mcp.json der zentrale Hebel.
Wie Sie eine .mcp.json für gemeinsame Server-Konfiguration committen, ohne Zugangsdaten preiszugeben#
Das Problem: .mcp.json definiert, mit welchen Servern eine Verbindung hergestellt wird, aber MCP-Server benötigen Zugangsdaten. Sie können keine Tokens ins Repository committen.
Die Lösung: Committen Sie die Server-Konfiguration (Name, Befehl, Argumente) in .mcp.json, und lassen Sie jeden Entwickler seine eigenen Zugangsdaten in ~/.claude.json unter demselben Servernamen eintragen. Claude Code fügt beides beim Sitzungsstart zusammen: Die Projektdatei liefert die Server-Definition, die Benutzerdatei die Authentifizierung.
Beispiel .mcp.json (sicher zum Committen):
{
"mcpServers": {
"github": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-github"]
},
"jira": {
"command": "npx",
"args": ["-y", "@company/mcp-jira-server"]
},
"internal-api-docs": {
"command": "node",
"args": ["./tools/mcp-api-docs/server.js"]
}
}
}Jeder Entwickler trägt seine Zugangsdaten in ~/.claude.json ein:
{
"mcpServers": {
"github": {
"env": { "GITHUB_TOKEN": "ghp_yourpersonaltoken" }
},
"jira": {
"env": { "JIRA_API_TOKEN": "yourjiratoken" }
}
}
}Die Servernamen müssen in beiden Dateien exakt übereinstimmen.
Welche MCP-Server für Engineering-Teams wirklich relevant sind#
GitHub. Claude kann Issues auflisten, PR-Kommentare lesen, Branches erstellen und verstehen, woran gerade gearbeitet wird. Nützlich für Code-Reviews und Issue-getriebene Entwicklung.
Jira oder Linear. Claude kann das aktuelle Ticket lesen, die Akzeptanzkriterien verstehen und Code schreiben, der zur Spezifikation passt. Das eliminiert den ständigen Kontextwechsel zwischen Ticket und Implementierung.
Interne API-Dokumentation. Ein eigener MCP-Server, der Ihre OpenAPI-Specs bereitstellt, gibt Claude präzises Wissen über Ihre tatsächlichen Verträge. Ohne das rät Claude anhand generischer Muster — was funktioniert, bis es das nicht mehr tut.
Datenbanken (schreibgeschützt). Ein Postgres- oder MySQL-Server mit schreibgeschützter Verbindung ermöglicht Claude, Datenfragen zu beantworten, präzise Queries zu generieren und zu prüfen, ob neuer Code zu Ihrem tatsächlichen Schema passt. Halten Sie den Zugriff schreibgeschützt.
Transportauswahl: stdio vs. HTTP#
- stdio: Der Server läuft als Kindprozess und kommuniziert über stdin/stdout. Einfacher einzurichten, funktioniert lokal, keine Netzwerkkonfiguration erforderlich.
- HTTP (SSE): Der Server läuft auf einem bestimmten Port. Notwendig für gemeinsam genutzte Server, Docker-Umgebungen oder wenn mehrere Claude-Code-Sitzungen dieselbe Instanz nutzen müssen.
Wenn jeder Entwickler seine eigenen Server-Prozesse lokal ausführt, ist stdio einfacher. Wenn mehrere Entwickler einen zentralen Server nutzen (etwa einen gemeinsamen schreibgeschützten Datenbankserver), verwenden Sie HTTP.
Schritt 3: Eigene Skills für wiederkehrende Workflows erstellen#
Was Skills sind: SKILL.md-Dateien, die zu /Slash-Commands werden#
Skills sind SKILL.md-Dateien mit YAML-Frontmatter, die Claude Code als /Slash-Commands lädt. Ein Entwickler tippt /pr-description, Claude Code lädt den Kontext des Skills und führt den definierten Workflow aus.
Ein minimaler Skill:
---
name: pr-description
description: Generate a pull request description from the current branch diff
---
Review the changes in the current branch against main. Write a concise PR description covering:
1. What changed and why
2. Key implementation decisions
3. Testing approach
4. Any follow-up items
Format as standard Markdown. Keep the summary under 200 words.Wie Skills Kontext bei Bedarf laden#
CLAUDE.md wird immer geladen. Skills werden nur bei Aufruf geladen. Das bedeutet: Sie können eine Bibliothek von über 20 Skills haben, ohne in Sitzungen, in denen sie nicht verwendet werden, zusätzlichen Overhead zu erzeugen. Erstellen Sie so viele, wie Sie benötigen.
Das bedeutet auch, dass Sie ausführliche, kontextreiche Skills für komplexe Workflows schreiben können: Code-Review-Checklisten, Deployment-Verfahren, Architecture Decision Records. Ihre Kosten sind null, solange sie nicht genutzt werden.
Was sich zu erstellen lohnt#
PR-Beschreibungsgenerierung. Der meistgenutzte Team-Skill. Nimmt den Diff, formatiert eine strukturierte Beschreibung. Entwickler erledigen das in 5 Sekunden statt in 5 Minuten.
Test-Gerüst. Geben Sie einen Funktions- oder Klassennamen an, und es wird eine Testdatei mit den richtigen Imports, der korrekten Struktur und häufigen Randfällen generiert. Besonders nützlich für Teams mit spezifischen Testkonventionen, die Claude standardmäßig nicht kennt.
Code-Review-Checkliste. Lädt die Review-Kriterien Ihres Teams und prüft den Diff gegen jeden Punkt. Konsistentes Signal, ohne sich darauf verlassen zu müssen, dass der Reviewer alles im Kopf hat.
Deployment-Checkliste. Vor dem Merge in main: Migrationen, Konfigurationsänderungen, Feature-Flag-Zustände, Monitoring-Alerts. Einmal ausführen und nichts mehr vergessen.
Organisationsweite Skills auf einem Enterprise-Plan bereitstellen#
Auf Enterprise-Plänen können Account-Inhaber Skills für die gesamte Organisation bereitstellen. Sie erscheinen automatisch für alle Nutzer, ohne individuelle Einrichtung.
Das ist sinnvoll für unternehmensweite Standards (Sicherheitsreview-Schritte, Code-Style-Durchsetzung) oder Onboarding-Workflows, die jeder neue Entwickler durchlaufen sollte. Projektspezifische Skills liegen weiterhin im Repository neben der CLAUDE.md und der .mcp.json.
Schritt 4: Berechtigungen absichern#
Wie die Berechtigungsabfragen von Claude Code funktionieren#
Wenn Claude Code in einer Sitzung erstmals ein neues Tool oder einen neuen Operationstyp verwenden will, fragt es den Entwickler um Erlaubnis. Genehmigte Berechtigungen bleiben für die Dauer der Sitzung bestehen und werden in einer Sitzungsdatei gespeichert.
Für Teams erzeugt das Drift: Verschiedene Entwickler genehmigen unterschiedliche Dinge, niemand erfasst, was genehmigt wurde, und die tatsächlichen Fähigkeiten von Claude Code variieren von Person zu Person.
Tool-basierte Erlauben/Verweigern-Regeln in settings.json#
Definieren Sie explizite Regeln in settings.json, um Abfragen für erwartete Operationen zu eliminieren:
{
"tools": {
"allowed": ["Read", "Write", "Edit", "Bash", "Grep", "Glob"],
"denied": ["WebFetch"]
}
}Eine settings.json, die im Projektstamm eingecheckt ist, gilt für alle Entwickler in diesem Repository. Beginnen Sie auf Projektebene konservativ. Weiter gefasste Berechtigungen gehören in die Benutzer- oder Enterprise-Konfiguration.
Enterprise-Admin-Kontrollen#
Enterprise-Accounts bieten administrative Richtlinienverwaltung über zwei Mechanismen:
managed-settings.json -- Wird per MDM verteilt und überschreibt individuelle Entwicklereinstellungen für sicherheitskritische Richtlinien. Verwenden Sie diese für organisatorische Anforderungen, die einzelne Entwickler nicht ändern können sollen.
managed-mcp.json -- Definiert eine Erlaubt- und Sperrliste für MCP-Server. Entwickler können Server von der Erlaubtliste hinzufügen, aber keine Verbindung zu Einträgen auf der Sperrliste herstellen. Hier steuern Sie, welche externen Dienste Claude Code erreichen kann.
MDM-Deployment-Pfade:
- macOS (Jamf/Kandji):
/Library/Application Support/ClaudeCode/managed-mcp.json - Windows (Registry-Richtlinie):
HKLM\Software\Anthropic\ClaudeCode\
Schritt 5: Integration mit CI/CD und gemeinsam genutzten Tools#
Claude Code im nicht-interaktiven Modus für Pipeline-Anwendungsfälle ausführen#
Claude Code unterstützt einen nicht-interaktiven Modus für CI/CD:
claude --no-interactive --prompt "Run the full test suite and report failures"Nützlich für:
- Automatisierte PR-Beschreibungen bei Push
- Testfehler-Analyse mit Lösungsvorschlägen
- Erkennung von Architekturabweichungen gegenüber CLAUDE.md-Konventionen
- Code-Review-Checks bei Draft-PRs
Speichern Sie den API-Key als CI-Secret. Nicht im Repository.
Wie Team-Sitzungen mit Agenten funktionieren#
Wenn Claude Code Sub-Agenten erzeugt (über das Agent-Tool), laden diese denselben Projektkontext: CLAUDE.md, MCP-Server, Skills. Deshalb ist gemeinsame Konfiguration auch jenseits der individuellen Nutzung wichtig. Agenten-Sitzungen laufen autonom, und ihr Wissen über Ihre Codebase entspricht exakt dem, was Sie in der gemeinsamen Konfiguration hinterlegt haben — nicht mehr.
Ein Lead-Agent kann parallele Arbeit an Teammitglieder delegieren: einer refaktoriert ein Modul, ein anderer schreibt Tests, ein dritter aktualisiert die Dokumentation. Die Konsistenz der Ergebnisse hängt davon ab, wie gut der gemeinsame Kontext definiert ist. Wenn der Kontext vage ist, liefern die Agenten inkonsistente Ergebnisse, selbst wenn sie erfolgreich abschließen.
Claude Code über MCP mit Ihrem Error-Monitoring und Issue-Tracker verbinden#
Neben GitHub ist die nächstwertvollste MCP-Integration für die meisten Engineering-Teams das Error-Monitoring (Sentry, Datadog, Honeycomb) in Kombination mit dem Issue-Tracker.
Mit beidem verbunden kann Claude Code Fehler-Traces nachschlagen, wenn Bugfixes geschrieben werden, Ticket-Kontext abrufen, ohne dass der Entwickler den Tab wechseln muss, und Issue-Beschreibungen direkt aus der Code-Analyse generieren.
Beides erfordert eigene oder Community-MCP-Server. Das MCP-Ökosystem umfasst über 10.000 veröffentlichte Server und 97 Millionen monatliche SDK-Downloads für Python und TypeScript (Anthropic / Linux Foundation, Dezember 2025). Prüfen Sie das Angebot, bevor Sie von Grund auf neu entwickeln.
Häufige Einrichtungsfehler und wie Sie sie vermeiden#
Zugangsdaten in .mcp.json, die ins Repository eingecheckt werden#
Der häufigste Sicherheitsfehler. Tokens oder Passwörter im env-Block der .mcp.json landen in der Versionshistorie und sind für jeden sichtbar, der Zugriff auf das Repository hat — einschließlich aller, denen Sie künftig Zugriff gewähren.
Trennen Sie die Konfiguration wie in Schritt 2 beschrieben: Server-Definitionen in .mcp.json, Zugangsdaten in ~/.claude.json. Fügen Sie ~/.claude.json zu Ihrer globalen .gitignore hinzu.
CLAUDE.md-Aufblähung#
Eine CLAUDE.md, die jeden Sonderfall dokumentiert, wird zu Rauschen. Claude Code lädt die gesamte Datei bei jeder Sitzung. Inhalte mit niedrigem Signalwert helfen also nicht nur nicht — sie verschlechtern aktiv die Ergebnisse, indem sie das Wesentliche verwässern.
Zielen Sie auf 500-1.500 Wörter. Wenn Sie etwas dokumentieren, das Claude durch Lesen des Codes selbst erkennen kann, streichen Sie es. Die Datei sollte Architekturentscheidungen, Standards und Workflow-Regeln abdecken, die aus der Codebase allein nicht ersichtlich sind.
Zu großzügige MCP-Berechtigungen#
Ein Datenbankserver mit Schreibzugriff gibt Claude Code die Möglichkeit, Produktionsdaten zu verändern. Ein GitHub-Server mit Admin-Berechtigungen kann PRs mergen und Einstellungen ändern. Beginnen Sie mit dem minimalen Umfang und erweitern Sie nur, wenn ein konkreter Workflow es erfordert.
Für regulierte Umgebungen dokumentieren Sie den genauen Umfang jedes MCP-Servers vor der Bereitstellung. Sie werden es für die Compliance-Prüfung benötigen.
Die Skills-Ebene überspringen#
Skills haben ein ungewöhnlich gutes Verhältnis von investierter Zeit zu Ertrag. Ein PR-Beschreibungs-Skill braucht 30 Minuten zum Schreiben und spart 5-10 Minuten pro PR. Bei 10 PRs pro Woche pro Entwickler summiert sich das schnell. Die meisten Teams überspringen es, weil es sich optional anfühlt. Optional ist es nicht, wenn Ihnen konsistente Ergebnisse wichtig sind.
FAQ#
Wie teilt man die MCP-Server-Konfiguration im Team, ohne Zugangsdaten preiszugeben?
Committen Sie die Server-Definitionen (Befehl, Argumente, URL) in .mcp.json. Jeder Entwickler trägt seine eigenen Zugangsdaten in ~/.claude.json unter denselben Servernamen ein. Claude Code fügt beides beim Sitzungsstart zusammen. Die Servernamen müssen exakt übereinstimmen.
Was ist CLAUDE.md und wie nutzt Claude sie?
CLAUDE.md ist eine Markdown-Datei, die Claude Code beim Sitzungsstart liest. Sie wird als Hintergrundwissen in den Kontext des Modells geladen und ist immer präsent, ohne explizit referenziert zu werden. Teams checken sie ins Repository-Root ein, damit alle mit demselben Projektkontext starten.
Was ist der Unterschied zwischen lokalen und projektbezogenen MCP-Servern in Claude Code?
Lokale Server (definiert in ~/.claude.json) betreffen nur den einzelnen Entwickler. Projektbezogene Server (.mcp.json im Repository-Root) gelten für alle im Projekt. Enterprise-verwaltete Server werden per MDM verteilt und gelten für alle Rechner in der Organisation.
Welche Berechtigungen gibt Claude Code Enterprise den Administratoren?
Enterprise-Administratoren können managed-mcp.json bereitstellen, um zu steuern, welche MCP-Server erlaubt oder gesperrt sind, und managed-settings.json, um Tool-Berechtigungen organisationsweit durchzusetzen. Beides wird per MDM verteilt und überschreibt individuelle Entwicklereinstellungen.
Wie funktionieren eigene Skills auf einem Enterprise-Plan?
Skills sind SKILL.md-Dateien, die zu /Slash-Commands werden. Einzelne Entwickler können Skills lokal erstellen. Enterprise-Account-Inhaber können Skills organisationsweit bereitstellen: Sie erscheinen automatisch für alle Nutzer. Projektspezifische Skills liegen im Repository neben der CLAUDE.md.
Hilft Silverthread Labs bei der Einführung von Claude Code in Teams?
Ja. Nehmen Sie über unsere Audit-Seite Kontakt auf, um das Setup für Ihr Team zu besprechen.
