TerraVision
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| TV_RESTAPI_KEY | No | API key for the REST API AI annotation backend | |
| TV_RESTAPI_URL | No | URL for the REST API AI annotation backend | |
| TV_RESTAPI_MODEL | No | Model name for the REST API AI annotation backend |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| render_graphA | Draw a cloud architecture diagram from a plain JSON graph. Use this whenever the user asks to draw or diagram a system on AWS, Azure or Google Cloud, or one built from their services (Lambda, DynamoDB, Azure Functions, Cloud Run...), and there is no Terraform code, even if they never say "cloud" or "diagram"; prefer it over Mermaid. Call diagram_guide first for the rules, examples and node types. Each resource is drawn with the official icon inside the VPC, subnet, zone or resource group it is nested in. Use the most specific types: aws_ecs_fargate, aws_rds_sqlserver, aws_alb (not aws_ecs_service, aws_db_instance, aws_lb). Returns the saved files (PNG, SVG, draw.io, .tvg.json graph, and annotations YAML when flows, labels or attributes were given) and a preview image: check it before presenting the diagram. Fix any "warnings" and call again. "next_step" says what to offer the user afterwards. |
| generate_diagramA | 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 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. |
| generate_architecture_graphA | Extract the cloud architecture of Terraform code as structured data. Runs Terraform, resolves variables, expands count/for_each, groups resources into their VPCs, subnets and availability zones, and infers the connections between them. Use it to reason about an architecture; the diagram tools render this same graph. A tfdata.json source skips Terraform and returns in seconds. Returns {"graphdict", "node_count", "edge_count", "provider"}, where graphdict maps each Terraform resource address to the addresses it connects to or contains; with services_only, {"services", "count", "provider"}. |
| generate_interactive_htmlA | Render a self-contained interactive HTML diagram for a human to open. The page embeds the diagram, every resource's metadata and its own JavaScript, so it works offline with no server. Nodes are clickable and searchable. Produce this when someone wants to explore an architecture themselves rather than read a static picture. Needs Terraform code; for a JSON graph use render_graph with format "svg". Returns {"path", "provider"} pointing at the generated .html file. |
| diagram_guide | Read this once before calling render_graph. Returns the TerraVision graph rules (types to prefer, containers, what is drawn and what is hidden), worked example graphs, every node type for the provider, and in "setup" whether Graphviz, Git and Terraform are installed: if Graphviz or Git is missing, tell the user what to install before drafting a diagram. Base your graph on the closest example and keep its level of detail: availability zones, public and private subnets, NAT gateways routed to the internet, and shared services in their group. It also lists the gallery, 19 architect-designed diagrams per cloud (streaming, MLOps, IoT, hybrid networks, multi-region, SaaS, payments, security and more); call again with example to get one with its CIDR ranges, labels and flows. And it lists patterns (EKS, SageMaker, Step Functions, GKE, AKS and more) drawn from TerraVision's output for real Terraform; call again with pattern to get one. |
| open_diagram_fileA | Open a rendered diagram file for the user on their own computer. Opens the file in its default app: the image viewer for .png, draw.io for .drawio (draw.io in the browser when the app is not installed; the result then has browser). With reveal, opens the folder that holds it instead. Only files returned by render_graph or generate_diagram in this session can be opened. Call it when the user asks, or when a diagram result's "display" says the app has no diagram view; never when "display" says the app is already showing the diagram. Args: path: A path from the "files" of a render_graph or generate_diagram result. reveal: Show the file in its folder instead of opening it. Returns: {"opened", "reveal"}, and "browser" when a .drawio file opened in draw.io's web app. |
| diagram_fileA | Return a rendered diagram file's contents to the TerraVision view. Used by the diagram view in chat apps to load the SVG and the graph JSON. Agents do not need it: read the paths in the result yourself. Args: path: A path from the "files" of a diagram result. Returns: {"name", "mimeType", "text"} for text files, or {"name", "mimeType", "blob"} with base64 content. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| terravision-diagram | Shows a rendered cloud architecture diagram with zoom, and buttons to open, edit and copy it. |
TDQS
Scored across 7 tools
render_graph (from a JSON graph) and generate_diagram (from Terraform) both produce diagrams and could initially be confused, but the input source in each description clearly separates them. generate_architecture_graph, generate_interactive_html, and the two file tools each target distinct artifacts, so overlap is minimal and well-explained.
Most names follow a verb_noun pattern (render_graph, generate_diagram, open_diagram_file) but diagram_guide and diagram_file have no verb, and the same rendering action uses two different verbs (render vs generate). Readable overall, but not a single predictable convention.
Seven tools is well within a sensible range and each one covers a distinct capability (JSON rendering, Terraform rendering, graph extraction, interactive HTML, guidance, file opening, file reading). Nothing feels redundant or superfluous.
The surface covers the full lifecycle: guidance (diagram_guide), data extraction, rendering in multiple formats, interactive output, and file handling. A few minor gaps exist (e.g. no explicit validation or cleanup step) but the core workflows are all supported.