Transforme Código, Terraform e Diagramas em um Modelo C4 com MCP - Archyl Blog

O canvas em branco é uma mentira: sua arquitetura já está escrita em arquivos Structurizr, módulos Terraform, diagramas Mermaid e READMEs. Conecte um agente de IA ao servidor MCP do Archyl e transforme tudo isso em um modelo C4 vivo — sem redesenhar uma única caixa.

Transforme Código, Terraform e Diagramas em um Modelo C4 com MCP

A parte mais difícil da documentação de arquitetura não é desenhar caixas. É que, quando você abre a ferramenta, sua arquitetura já existe — espalhada por cinco lugares que não conversam entre si.

Um arquivo Structurizr DSL que alguém manteve por oito meses. Diagramas Mermaid em uma dúzia de READMEs. Módulos Terraform que descrevem sua infraestrutura real melhor do que qualquer diagrama jamais descreveu. Um export PlantUML da ferramenta que você usava antes. E o próprio código-fonte, a única fonte que nunca mente.

No sábado eu mostrei como migrar um space do Confluence para o Archyl com dois servidores MCP e um prompt. Hoje, o mesmo truque com um prêmio maior: importar a arquitetura em si.

Dois caminhos, escolha por fonte

Primeiro, os caminhos nativos: se o seu repositório está conectado ao Archyl, o AI Discovery analisa o código e propõe um modelo C4 completo — sistemas, containers, componentes, relacionamentos — que você revisa e aprova. E se você está vindo de outra ferramenta C4, os exports de Structurizr DSL, LikeC4 e IcePanel já têm um importador de um clique. Quando um dos dois servir, comece por aí.

O caminho via MCP é para todo o resto: as fontes que o Discovery não consegue ver. Arquivos de diagrams-as-code, definições de infraestrutura, aquela página de arquitetura no wiki de alguém, ou um repositório em um servidor privado. O servidor MCP do Archyl expõe toda a superfície de escrita do modelo C4 — create_system, create_container, create_component, create_relationship, set_element_technologies, create_adr — então qualquer agente que consiga ler sua fonte consegue escrever seu modelo.

O setup é o mesmo comando único de sábado:

claude mcp add --transport http archyl https://api.archyl.com/mcp \
  --header "X-API-Key: your_api_key"

Receita 1 — Structurizr, Mermaid, PlantUML

Diagrams-as-code é a vitória mais fácil, porque a semântica já é explícita. Para um workspace.dsl padrão, o importador de um clique acima é mais rápido — o agente ganha o seu lugar com Mermaid e PlantUML (não existe importador), com variantes do DSL que o importador não consegue interpretar, ou quando você quer mesclar seletivamente em um projeto que já tem um modelo. Abra o repositório no Claude Code e:

Leia o workspace.dsl na raiz deste repositório. Recrie o modelo no
meu projeto "Aurora Commerce" no Archyl:

- softwareSystem → create_system (marque os externos como
  external_system)
- container → create_container sob o sistema certo, mantenha o
  campo technology
- cada relacionamento → create_relationship com sua descrição
- não invente nada que não esteja no DSL; liste qualquer coisa que
  você não conseguiu mapear

Depois releia o modelo com list_systems e list_containers e me
mostre um resumo para eu conferir que nada foi perdido.

O passo de releitura no final é o hábito que vale manter: o agente verifica a própria importação contra o modelo vivo em vez de assumir que funcionou.

Receita 2 — Terraform

Seu código de infraestrutura sabe coisas que seus diagramas esqueceram. Aponte o agente para o seu Terraform e deixe-o trabalhar na altitude certa:

Leia infra/ neste repositório. Modele a arquitetura no nível de
deployment no Archyl: serviços gerenciados (RDS, SQS, S3,
CloudFront...) viram containers ou sistemas externos, um por
serviço real — não um por recurso. Trace os relacionamentos a
partir das políticas IAM, security groups e variáveis de ambiente.
Marque tudo o que você criar com a tag "terraform" para eu poder
filtrar a camada importada depois.

A linha "não um por recurso" está fazendo um trabalho de verdade. Um importador ingênuo transforma 400 recursos Terraform em 400 caixas. Um agente entende que uma instância de banco de dados, seu subnet group e seu parameter group são um único container chamado Orders Database.

Receita 3 — o próprio código-fonte

Sem DSL, sem diagramas, repositório não conectado ao Archyl? O agente já está sentado dentro do seu código. Peça a ele para propor o modelo de baixo para cima — serviços a partir dos manifestos de deploy, componentes a partir da estrutura de pacotes, relacionamentos a partir dos clientes HTTP e produtores de fila que ele encontrar. É o trabalho do AI Discovery feito à mão, e é o fallback certo quando o Discovery não alcança a fonte.

Receita 4 — diagramas presos no seu wiki

Combine os dois servidores MCP do post de sexta: o agente lê as páginas de arquitetura através do servidor MCP da Atlassian, extrai os sistemas e fluxos descritos e os escreve no Archyl. A página de wiki que descreve seu pipeline de eventos vira um modelo real e navegável dele — e a própria página vem junto como documentação vinculada.

Importar é a parte chata — aqui está o ponto

O dia seguinte à importação é o motivo pelo qual você a fez. Como o modelo entrou via MCP, ele continua alcançável via MCP:

  • Seus agentes o consultam enquanto codificam — "quais containers falam com o banco de pagamentos?" está a uma chamada de ferramenta de distância.
  • Serviços novos são adicionados pelos mesmos agentes que os constroem, então o modelo acompanha a realidade em vez de apodrecer.
  • Drift scoring e regras de conformidade rodam contra um modelo que realmente corresponde aos seus sistemas.

Uma regra honesta para fechar: o agente propõe, você revisa. Importe um sistema por vez, leia os resumos e corte o que não pertence — a mesma disciplina de qualquer code review. O modelo com que você termina é tão bom quanto as fontes que você deu a ele, e você é quem sabe qual das cinco fontes estava dizendo a verdade.

Sua arquitetura já existe. Pare de redesenhá-la — importe-a. A lista completa de ferramentas está na documentação do servidor MCP.