Skip to main content
Glama

create_cld

Create a CLD diagram as PNG image. A Causal Loop Diagram (CLD) is a Systems Thinking tool that maps feedback loops between variables, showing how a change in one variable causes changes in others. It reveals reinforcing dynamics (exponential growth or decline) and balancing dynamics (stabilisation toward equilibrium).

You provide VGL (Vithanco Graph Language) code using the CLD notation and the tool renders it to an PNG image.

Core Concepts

A CLD consists of variables (called Stocks) connected by causal links with polarity:

  • same (s): when A increases, B increases; when A decreases, B decreases. Drawn as a solid arrow.

  • opposite (o): when A increases, B decreases; when A decreases, B increases. Drawn as a dashed arrow.

A feedback loop is a closed chain of causal links returning to the starting variable:

  • Reinforcing loop (R): even number of opposite edges (including zero). Drives exponential growth or decline — a snowball effect.

  • Balancing loop (B): odd number of opposite edges. Drives the system toward equilibrium — a thermostat effect.

How to Build a CLD

  1. Identify the key variables (stocks) in the system — things whose value can increase or decrease.

  2. For each pair of causally related variables, determine the polarity: does an increase in A cause B to increase (same) or decrease (opposite)?

  3. Trace closed loops and classify them as reinforcing or balancing using the counting rule.

  4. Give the diagram a title that frames the system boundary.

VGL Syntax

vgraph <id>: CLD "<title>" {
    <nodes and edges>
}

Node Types

  • Stock — a variable whose value changes over time (blue circle). Examples: Population, Revenue, Stress, Trust.

node <id>: Stock "<label>"

Edges

CRITICAL: You MUST specify the edge type (: same or : opposite) on every edge. Both edge types connect Stock to Stock, so the type CANNOT be inferred — omitting it will cause an error.

edge <from_id> -> <to_id>: same
edge <from_id> -> <to_id>: opposite

Identifying Feedback Loops

To classify a loop, trace a closed path back to the starting variable and count the opposite edges:

  • 0 opposite edges → Reinforcing (R): Population → Birth Rate → Population (more people → more births → even more people)

  • 1 opposite edge → Balancing (B): Population → Death Rate → Population (more people → more deaths → fewer people)

Rule: even count = reinforcing, odd count = balancing.

Complete Example

vgraph populationCLD: CLD "Population Dynamics" {
    node population: Stock "Population"
    node births: Stock "Birth Rate"
    node deaths: Stock "Death Rate"
    node resources: Stock "Available Resources"

    edge population -> births: same
    edge births -> population: same
    edge population -> deaths: same
    edge deaths -> population: opposite
    edge population -> resources: opposite
    edge resources -> births: same
}

Loop analysis:

  • R1 (Reinforcing): Population → Birth Rate → Population — 0 opposite edges. More people produce more births, which increases population. Growth spiral.

  • B1 (Balancing): Population → Death Rate → Population — 1 opposite edge. More people means more deaths, which reduces population. Death regulation.

  • B2 (Balancing): Population → Available Resources → Birth Rate → Population — 1 opposite edge (population → resources). More people deplete resources, reducing birth rate. Resource constraint.

Rules

  1. ALWAYS specify the edge type (: same or : opposite) — it cannot be inferred

  2. Stock labels should be nouns or noun phrases representing measurable quantities that can increase or decrease (e.g. "Population", "Revenue", "Stress Level" — not "People are born" or "Increasing")

  3. Every Stock MUST connect to at least one other Stock — no isolated variables

  4. Think in terms of "if A increases, what happens to B?" to determine same vs opposite polarity

  5. Use meaningful IDs (population, revenue, stress — not n1, n2, n3)

  6. Keep the diagram focused on one system — the title should frame the boundary

  7. Aim for closed loops — a CLD without any feedback loop is just a causal chain and misses the point of systems thinking

  8. Prefer 3–6 variables per loop for clarity — larger loops are hard to trace and verify

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
vglYesValid VGL code using the CLD notation. Must start with: vgraph <id>: CLD "<title>" { ... }

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.5/5.0
Behavior4/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool renders VGL code to a PNG, explains the exact syntax required, and explicitly warns that omitting edge type causes an error. It does not describe the output delivery format, but the core behavior is clearly and accurately disclosed.

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

Conciseness4/5

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

The description is long, but it is well-structured with clear sections (Core Concepts, How to Build, VGL Syntax, Example, Rules) and front-loaded with the tool's purpose. Every section serves the goal of producing valid VGL, though some educational content could be trimmed without losing correctness.

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?

For a complex, DSL-driven tool with a single parameter and no output schema, this description is essentially complete. It covers syntax, node types, edge polarity, loop classification, rules, and a full working example, leaving an agent with everything needed to construct a valid CLD.

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

Parameters5/5

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

The schema only provides a generic description of the vgl parameter, but the tool description compensates comprehensively: it specifies the VGL grammar, node syntax, edge syntax with required polarity, a complete example, and validation rules. This adds substantial meaning beyond the input schema.

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

Purpose5/5

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

The description opens with a precise verb-resource-output statement: 'Create a CLD diagram as PNG image.' It clearly defines what a CLD is and distinguishes it from the sibling diagram tools (concept map, IBIS, timeline) by focusing on causal feedback loops and VGL syntax.

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?

The description gives clear context: this tool is for systems thinking diagrams that map feedback loops. It explains the domain and how to construct a CLD. It does not explicitly name alternatives or state when not to use this tool, but the context is strong enough for an agent to select it appropriately.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources