Code, Terraform und Diagramme mit MCP in ein C4-Modell verwandeln
Das Schwerste an Architekturdokumentation ist nicht das Zeichnen von Boxen. Es ist, dass deine Architektur längst existiert, wenn du das Tool öffnest — verstreut über fünf Orte, die nicht miteinander reden.
Eine Structurizr-DSL-Datei, die jemand acht Monate lang gepflegt hat. Mermaid-Diagramme in einem Dutzend READMEs. Terraform-Module, die deine echte Infrastruktur besser beschreiben als jedes Diagramm je zuvor. Ein PlantUML-Export aus dem Tool, das du vorher benutzt hast. Und die Codebasis selbst — die einzige Quelle, die nie lügt.
Am Samstag habe ich gezeigt, wie du einen Confluence-Space nach Archyl migrierst — mit zwei MCP-Servern und einem Prompt. Heute derselbe Trick mit größerem Gewinn: der Import der Architektur selbst.
Zwei Wege — wähle pro Quelle
Zuerst die eingebauten Wege: Wenn dein Repository mit Archyl verbunden ist, analysiert AI Discovery den Code und schlägt ein vollständiges C4-Modell vor — Systeme, Container, Komponenten, Beziehungen —, das du reviewst und genehmigst. Und wenn du von einem anderen C4-Tool kommst: Für Structurizr DSL-, LikeC4- und IcePanel-Exporte gibt es bereits einen Ein-Klick-Importer. Wenn einer der beiden Wege passt, fang dort an.
Der MCP-Weg ist für alles andere: die Quellen, die Discovery nicht sieht. Diagrams-as-Code-Dateien, Infrastrukturdefinitionen, die Architekturseite in irgendjemandes Wiki oder ein Repo auf einem privaten Server. Der MCP-Server von Archyl stellt die komplette Schreiboberfläche des C4-Modells bereit — create_system, create_container, create_component, create_relationship, set_element_technologies, create_adr —, sodass jeder Agent, der deine Quelle lesen kann, dein Modell schreiben kann.
Das Setup ist derselbe Einzeiler wie am Samstag:
claude mcp add --transport http archyl https://api.archyl.com/mcp \
--header "X-API-Key: your_api_key"
Rezept 1 — Structurizr, Mermaid, PlantUML
Diagrams-as-Code ist der einfachste Gewinn, weil die Semantik bereits explizit ist. Für ein standardmäßiges workspace.dsl ist der Ein-Klick-Importer oben schneller — der Agent verdient sich seinen Platz bei Mermaid und PlantUML (dafür gibt es keinen Importer), bei DSL-Varianten, die der Importer nicht parsen kann, oder wenn du selektiv in ein Projekt mergen willst, das bereits ein Modell hat. Öffne das Repo in Claude Code und:
Lies workspace.dsl im Root dieses Repos. Bilde das Modell in meinem
Archyl-Projekt "Aurora Commerce" nach:
- softwareSystem → create_system (markiere externe als external_system)
- container → create_container unter dem richtigen System, behalte
das Technology-Feld
- jede Beziehung → create_relationship mit ihrer Beschreibung
- erfinde nichts, was nicht in der DSL steht; liste alles auf, was du
nicht zuordnen konntest
Lies das Modell danach mit list_systems und list_containers zurück
und zeig mir eine Zusammenfassung, damit ich prüfen kann, dass nichts
verloren ging.
Der Read-back-Schritt am Ende ist die Gewohnheit, die du dir merken solltest: Der Agent verifiziert seinen eigenen Import gegen das Live-Modell, statt anzunehmen, dass alles geklappt hat.
Rezept 2 — Terraform
Dein Infrastrukturcode weiß Dinge, die deine Diagramme vergessen haben. Richte den Agenten auf dein Terraform und lass ihn auf der richtigen Flughöhe arbeiten:
Lies infra/ in diesem Repo. Modelliere die Deployment-Architektur in
Archyl: Managed Services (RDS, SQS, S3, CloudFront...) werden zu
Containern oder externen Systemen, einer pro echtem Service — nicht
einer pro Ressource. Verdrahte die Beziehungen aus IAM-Policies,
Security Groups und Umgebungsvariablen. Tagge alles, was du erstellst,
mit "terraform", damit ich die importierte Schicht später filtern kann.
Die Zeile "nicht einer pro Ressource" leistet echte Arbeit. Ein naiver Importer macht aus 400 Terraform-Ressourcen 400 Boxen. Ein Agent versteht, dass eine DB-Instanz, ihre Subnet Group und ihre Parameter Group zusammen ein Container namens Orders Database sind.
Rezept 3 — die Codebasis selbst
Keine DSL, keine Diagramme, Repo nicht mit Archyl verbunden? Der Agent sitzt bereits in deinem Code. Bitte ihn, das Modell bottom-up vorzuschlagen — Services aus den Deploy-Manifesten, Komponenten aus der Paketstruktur, Beziehungen aus den HTTP-Clients und Queue-Producern, die er findet. Das ist der Job von AI Discovery, von Hand erledigt — und der richtige Fallback, wenn Discovery die Quelle nicht erreichen kann.
Rezept 4 — Diagramme, die in deinem Wiki gefangen sind
Kombiniere beide MCP-Server aus dem Post vom Samstag: Der Agent liest die Architekturseiten über den MCP-Server von Atlassian, extrahiert die beschriebenen Systeme und Flows und schreibt sie nach Archyl. Die Wiki-Seite, die deine Event-Pipeline beschreibt, wird zu einem echten, navigierbaren Modell davon — und die Seite selbst kommt als verlinkte Dokumentation gleich mit.
Der Import ist der langweilige Teil — hier ist der Punkt
Der Tag nach dem Import ist der Grund, warum du das Ganze gemacht hast. Weil das Modell über MCP hineingekommen ist, bleibt es über MCP erreichbar:
- Deine Agenten fragen es beim Coden ab — "welche Container sprechen mit der Payments-Datenbank?" ist einen Tool-Aufruf entfernt.
- Neue Services werden von denselben Agenten hinzugefügt, die sie bauen — das Modell folgt der Realität, statt zu verfallen.
- Drift-Scoring und Konformitätsregeln laufen gegen ein Modell, das tatsächlich zu deinen Systemen passt.
Eine ehrliche Regel zum Schluss: Der Agent schlägt vor, du reviewst. Importiere ein System nach dem anderen, lies die Zusammenfassungen und streiche, was nicht dazugehört — dieselbe Disziplin wie bei jedem Code-Review. Das Modell, das am Ende steht, ist nur so gut wie die Quellen, mit denen du es gefüttert hast — und du bist derjenige, der weiß, welche der fünf Quellen die Wahrheit gesagt hat.
Deine Architektur existiert bereits. Hör auf, sie neu zu zeichnen — importiere sie. Die vollständige Tool-Liste steht in den MCP-Server-Docs.