Skip to main content
Glama

generate_diagram

Render an architecture diagram from Terraform code to PNG, SVG, PDF, or draw.io, using actual plan data for AWS, Azure, and GCP deployments.

Instructions

Render an architecture diagram from Terraform code to a file.

Uses the official AWS, Azure and GCP icon sets. Because the diagram is derived from terraform plan, it reflects what the code actually deploys rather than an approximation. Runs terraform init and terraform plan (cloud credentials needed) unless planfile and graphfile are given, so a first call can take minutes.

Returns {"path", "format", "provider", "title", "files"}, plus a preview image. "files" holds the PNG, SVG, draw.io file and the graph as .tvg.json, which can be edited and rendered again with render_graph; "path" is the file in the requested format.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
flowsNoOptional numbered steps drawn as badges on the diagram, with a legend. Keyed by flow name: {"order_request": {"description": "A customer places an order", "steps": [{"resource": "tv_aws_users.users", "detail": "Customer opens the app"}, {"resource": "aws_alb.api~1 -> aws_ecs_fargate.app~1", "detail": "Request routed to a task"}]}}. A step names a node, or an arrow as "<node> -> <node>" in either direction; use the numbered copy (aws_alb.api~1), not the bare name. Steps are numbered across flows. Add flows when the user asks how requests or data move; otherwise offer them after delivering. Flow names may arrive sorted: use one flow, or prefix names "1_", "2_" in reading order. Name nodes as they appear in the .tvg.json graph of an earlier render, which can differ from the Terraform addresses.
titleNoHeading shown above the diagram, e.g. "Order Platform - Production". Defaults to "Cloud Architecture Diagram". Overrides a title in the annotation file.
formatNo"png", "svg", "pdf", "dot" or "drawio" (editable in draw.io and Lucidchart). The full set is always saved; use "svg" to embed in Markdown.png
sourceYesTerraform directory, Git URL, or tfdata.json replay file. Add //folder to a Git URL for a folder inside the repository, e.g. "https://github.com/org/repo//examples". A repository whose root is a reusable module plans no resources: draw a folder that uses it instead (examples/, an environment).
outfileNoOutput file name without extension, e.g. "three_tier". Files always go to the server's output folder; from a path, only the last part is used. The cloud provider is appended: "architecture" becomes "architecture-aws".architecture
previewNoInclude a preview image of the diagram in the result.
upgradeNoRun `terraform init -upgrade` to refresh modules.
varfileNoPaths to .tfvars files.
annotateNoPath to a terravision.yml annotation file.
fontsizeNoLabel font size in points.
iconsizeNoIcon size in pixels.
planfileNoPath to an existing plan JSON (terraform show -json). With graphfile, no Terraform run and no cloud credentials are needed.
graphfileNoPath to an existing `terraform graph` DOT file.
workspaceNoTerraform workspace to select.default
simplifiedNoShow only services, omitting networking containers.
edge_labelsNoOptional text on arrows the graph already has, to say what each connection does: {"aws_ecs_fargate.app~1 -> aws_rds_sqlserver.db": "Reads orders"}. Either direction names the arrow; a label never adds one. Keep labels to a few words; offer them with the flows rather than adding them unasked. Name nodes as in the .tvg.json graph of an earlier render.
use_tf_namesNoLabel nodes with full Terraform resource names.
use_resource_namesNoLabel nodes with the deployed resource names from the plan.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.52.0

TDQS

A4.1/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and does well: it discloses the underlying terraform init/plan execution, the credential requirement, the multi-minute latency on first call, and the bypass when planfile+graphfile are given. It omits whether files are overwritten or whether repeated calls are idempotent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Opens with the core action, then layers prerequisites, latency, and return shape in a short, well-ordered block. Given 18 parameters, four tight paragraphs with no filler is proportionate.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists, yet the description enumerates the return keys and explains what 'files' and 'path' contain, plus the preview image. Combined with the schema's 100% coverage, an agent has everything needed to call this correctly despite the missing annotations.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and the per-parameter descriptions are already unusually rich (flows, outfile naming, planfile/graphfile interaction), so the schema does the heavy lifting. The description adds only the usage cue for flows and the .tvg.json node-naming note, which is a marginal gain over structured fields.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Render an architecture diagram from Terraform code to a file') and clarifies the diagram is derived from `terraform plan`, so it reflects real deployments. It nods at render_graph as the re-render path, but never distinguishes itself from generate_architecture_graph or generate_interactive_html, which appear to overlap.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives concrete conditions: cloud credentials are required unless planfile and graphfile are supplied, and a first call can take minutes because it runs `terraform init`/`plan`. It also advises when to add flows ('when the user asks how requests or data move'). It stops short of saying when to pick this tool over the sibling generators.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.