Convierte Código, Terraform y Diagramas en un Modelo C4 con MCP
La parte más difícil de documentar la arquitectura no es dibujar cajas. Es que, para cuando abres la herramienta, tu arquitectura ya existe — dispersa en cinco sitios que no se hablan entre sí.
Un fichero Structurizr DSL que alguien mantuvo durante ocho meses. Diagramas Mermaid en una docena de READMEs. Módulos Terraform que describen tu infraestructura real mejor que ningún diagrama. Un export de PlantUML de la herramienta que usabas antes. Y el propio código, la única fuente que nunca miente.
El sábado mostré cómo migrar un espacio de Confluence a Archyl con dos servidores MCP y un prompt. Hoy, el mismo truco con un premio mayor: importar la arquitectura misma.
Dos caminos, elige según la fuente
Primero, los caminos integrados: si tu repositorio está conectado a Archyl, AI Discovery analiza el código y propone un modelo C4 completo — sistemas, contenedores, componentes, relaciones — que tú revisas y apruebas. Y si vienes de otra herramienta C4, los exports de Structurizr DSL, LikeC4 e IcePanel ya tienen un importador de un clic. Cuando cualquiera de los dos encaje, empieza por ahí.
El camino MCP es para todo lo demás: las fuentes que Discovery no puede ver. Ficheros de diagrams-as-code, definiciones de infraestructura, esa página de arquitectura en el wiki de alguien, o un repo en un servidor privado. El servidor MCP de Archyl expone toda la superficie de escritura del modelo C4 — create_system, create_container, create_component, create_relationship, set_element_technologies, create_adr — así que cualquier agente que pueda leer tu fuente puede escribir tu modelo.
La configuración es el mismo one-liner del sábado:
claude mcp add --transport http archyl https://api.archyl.com/mcp \
--header "X-API-Key: your_api_key"
Receta 1 — Structurizr, Mermaid, PlantUML
Diagrams-as-code es la victoria más fácil, porque la semántica ya es explícita. Para un workspace.dsl estándar, el importador de un clic de arriba es más rápido — el agente se gana el puesto con Mermaid y PlantUML (no existe importador), con variantes del DSL que el importador no puede parsear, o cuando quieres fusionar selectivamente en un proyecto que ya tiene un modelo. Abre el repo en Claude Code y:
Lee workspace.dsl en la raíz de este repo. Recrea el modelo en
mi proyecto de Archyl "Aurora Commerce":
- softwareSystem → create_system (marca los externos como
external_system)
- container → create_container bajo el sistema correcto, conserva
el campo technology
- cada relationship → create_relationship con su descripción
- no inventes nada que no esté en el DSL; lista todo lo que no
hayas podido mapear
Después relee el modelo con list_systems y list_containers y
muéstrame un resumen para que compruebe que no se ha perdido nada.
El paso de relectura del final es el hábito que merece la pena conservar: el agente verifica su propia importación contra el modelo vivo en lugar de asumir que funcionó.
Receta 2 — Terraform
Tu código de infraestructura sabe cosas que tus diagramas olvidaron. Apunta el agente a tu Terraform y déjalo trabajar a la altitud correcta:
Lee infra/ en este repo. Modela en Archyl la arquitectura a nivel
de despliegue: los servicios gestionados (RDS, SQS, S3, CloudFront...)
se convierten en contenedores o sistemas externos, uno por servicio
real — no uno por recurso. Cablea las relaciones a partir de las
políticas IAM, los security groups y las variables de entorno.
Etiqueta todo lo que crees con "terraform" para que pueda filtrar
la capa importada más adelante.
La línea "no uno por recurso" hace un trabajo real. Un importador ingenuo convierte 400 recursos de Terraform en 400 cajas. Un agente entiende que una instancia de base de datos, su subnet group y su parameter group son un solo contenedor llamado Orders Database.
Receta 3 — el propio código
¿Sin DSL, sin diagramas, repo no conectado a Archyl? El agente ya está sentado en tu código. Pídele que proponga el modelo de abajo hacia arriba — servicios a partir de los manifiestos de despliegue, componentes a partir de la estructura de paquetes, relaciones a partir de los clientes HTTP y productores de colas que encuentre. Es el trabajo de AI Discovery hecho a mano, y es el fallback correcto cuando Discovery no puede llegar a la fuente.
Receta 4 — diagramas atrapados en tu wiki
Combina los dos servidores MCP del post del sábado: el agente lee las páginas de arquitectura a través del servidor MCP de Atlassian, extrae los sistemas y flujos descritos, y los escribe en Archyl. La página del wiki que describe tu pipeline de eventos se convierte en un modelo real y navegable de él — y la propia página viene también como documentación vinculada.
Importar es la parte aburrida — este es el punto
El día después de la importación es la razón por la que lo hiciste. Como el modelo entró por MCP, sigue siendo accesible por MCP:
- Tus agentes lo consultan mientras programan — "¿qué contenedores hablan con la base de datos de pagos?" está a una llamada de herramienta de distancia.
- Los servicios nuevos los añaden los mismos agentes que los construyen, así que el modelo sigue la realidad en lugar de degradarse.
- El drift scoring y las reglas de conformidad se ejecutan contra un modelo que realmente coincide con tus sistemas.
Una regla honesta para cerrar: el agente propone, tú revisas. Importa un sistema cada vez, lee los resúmenes, y poda lo que no encaje — la misma disciplina que cualquier revisión de código. El modelo con el que acabes es tan bueno como las fuentes que le diste, y tú eres quien sabe cuál de las cinco fuentes decía la verdad.
Tu arquitectura ya existe. Deja de redibujarla — impórtala. La lista completa de herramientas está en la documentación del servidor MCP.