Claude Code mit MCP: Architektur eines kontrollierten Development Workflows

Die meisten Enttäuschungen mit Coding Agents haben dieselbe Ursache: Der Agent weiß zu wenig über das Projekt und darf gleichzeitig zu viel im System. Dieser Deep Dive beschreibt einen Entwicklungsplatz, bei dem beides umgekehrt ist – viel Kontext, eng geschnittene Rechte – und wie die Übergabe an Review und Pipeline sauber bleibt.

1. Was der Aufbau leisten soll

Drei Ziele, die sich gegenseitig stützen: Der Agent soll die Projektrealität kennen, statt plausibel zu raten. Er soll nur das ändern dürfen, was für die Aufgabe nötig ist. Und alles, was er produziert, soll denselben Weg gehen wie handgeschriebener Code – über Review, Gates und Pipeline.

Was hier am Beispiel von Claude Code beschrieben wird, gilt sinngemäß für andere MCP-fähige Clients. Die Grundlagen des Protokolls behandelt der Pillar MCP in der Softwareentwicklung.

2. Kontext: das unterschätzte Fundament

Bevor irgendein Server angebunden wird, lohnt sich der billigste Schritt: das Projektwissen in das Repository schreiben. Ein Agent liest, was da ist – nicht, was im Wiki oder im Kopf steht.

• Projektanweisungen im Repository: Aufbau, Konventionen, erlaubte und verbotene Abhängigkeiten, Teststrategie, Definition of Done.
• Architekturentscheidungen als kurze, datierte Notizen – warum etwas so ist, nicht nur dass es so ist.
• Schnittstellenverträge als Dateien, nicht als Beschreibung: OpenAPI, Schemas, Beispielnachrichten.
• Beispiele für erwünschten Stil: ein sauber umgesetzter Anwendungsfall sagt mehr als eine Seite Prosa.

3. Serverzuschnitt

Statt möglichst vieler Server empfiehlt sich ein bewusst kleiner Satz mit klar getrennten Rollen:

Auffällig ist, was fehlt: kein Produktionszugriff, keine Rechteverwaltung, kein Deployment. Diese Aktionen laufen über die Pipeline mit eigenen Freigaben.

4. Konfiguration im Projekt

Die Serverkonfiguration gehört ins Repository, nicht in die persönliche Umgebung – dann arbeitet das ganze Team gegen denselben Zuschnitt, und Änderungen daran durchlaufen das Review:

{
  "mcpServers": {
    "project-platform": {
      "command": "<server-binary>",
      "args": ["--project", "erp-2026", "--env", "staging"],
      "env": { "PLATFORM_TOKEN": "${PLATFORM_TOKEN}" }
    },
    "project-context": {
      "command": "<server-binary>",
      "args": ["--repo", "erp-2026", "--read-only"]
    }
  }
}

Aufbau und verfügbare Optionen unterscheiden sich je nach Client und Server; die aktuelle Form dokumentiert der jeweilige Anbieter. Entscheidend sind hier zwei Prinzipien: begrenzter Geltungsbereich und Zugangsdaten aus der Umgebung statt aus der Datei.

5. Freigaben sinnvoll stufen

Ein Client, der bei jedem Lesezugriff nachfragt, erzieht innerhalb eines Vormittags zum reflexhaften Bestätigen. Bewährt hat sich:

• Lesen im freigegebenen Ausschnitt: ohne Rückfrage.
• Schreiben in Arbeitszweig und Staging: Freigabe pro Werkzeug und Sitzung.
• Alles Außenwirksame – Push in fremde Repositories, Nachrichten, Netzwerkzugriffe – einzeln, mit sichtbaren Parametern.
• Irreversibles gar nicht anbieten.

6. Arbeitsweise im Alltag

Der praktische Unterschied zwischen frustrierender und produktiver Arbeit liegt weniger im Werkzeug als in der Aufgabenzuschneidung:

1. Aufgabe klein halten. Ein fachlicher Schnitt pro Lauf, nicht „bau das Modul“.
2. Anforderung mitgeben, inklusive Kennung – so landet sie später im Commit-Trailer.
3. Erst planen lassen, dann umsetzen. Ein kurzer Plan vor der Änderung deckt Missverständnisse auf, solange sie billig sind.
4. Tests aus der Anforderung ableiten, nicht aus der frisch erzeugten Implementierung.
5. Selbst lesen. Der Diff ist das Ergebnis – nicht die Zusammenfassung des Agents.

7. Übergabe an Review und CI/CD

Hier entscheidet sich, ob der Aufbau trägt. Alles, was der Agent produziert, durchläuft denselben Weg wie jede andere Änderung: Branch, Commit mit Anforderungsbezug, Merge Request, Review durch eine zweite Person, blockierende Quality Gates, Merge, Pipeline.

Sinnvoll ist eine Kennzeichnung wesentlichen KI-Einsatzes im Änderungssatz – nicht als Misstrauensvotum, sondern damit sich die Prüftiefe später bewerten lässt.

8. Protokollierung

Der Sitzungsverlauf des Clients ist kein Protokoll: Er liegt lokal, ist flüchtig und lässt sich nicht auswerten. Belastbar ist serverseitige Protokollierung – wer hat wann welches Werkzeug mit welchen Parametern aufgerufen. Für regulierte Umgebungen ist das die Grundlage jeder späteren Auskunft.

9. Grenzen

• Kontextkosten. Zu viele Werkzeuge und Ressourcen verschlechtern die Auswahl. Weniger, dafür präzise.
• Wartung. Jeder Server ist Software mit Updates, Abhängigkeiten und Ausfallverhalten.
• Clientunterschiede. Nicht jeder Client unterstützt jede Protokollfähigkeit gleich weit – vor der Einführung testen.
• Kein Ersatz für Architektur. Ein gut angebundener Agent beschleunigt Umsetzung, nicht Entscheidung.

Checkliste: Entwicklungsplatz aufsetzen

Fazit

Ein produktiver Agent-Arbeitsplatz entsteht nicht durch mehr Rechte, sondern durch besseren Kontext und klare Übergaben. Der Aufwand liegt überwiegend in Arbeit, die ohnehin lohnt: Konventionen aufschreiben, Verträge pflegen, Entscheidungen dokumentieren.

Wer diesen Aufbau einmal hat, kann Werkzeuge wechseln, ohne alles neu zu konfigurieren – weil das Wesentliche im Projekt liegt und nicht im Client.