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 quantity or state in the system. Stock values change over time based on incoming causal links.

node <id>: Stock "<label>"

Edges

  • same — Positive causal link — both stocks change in the same direction. If the source increases, the target increases too. Marked with '+'.

  • opposite — Negative causal link — the stocks change in opposite directions. If the source increases, the target decreases. Marked with '−'.

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

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "vgl": "<vgl>"
    },
    "name": "create_cld"
  }
}

Input 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.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 add real behavioral context: it states the output is a rendered PNG, and flags a critical failure mode ('omitting it will cause an error') for edge types. It does not disclose what the tool returns (image path/URL) or any size/permission constraints, leaving a modest gap.

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

Conciseness3/5

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

It is well-structured with headers and front-loads the purpose, but it is very long for a one-parameter tool; much of the CLD tutorial (loop classification, systems-thinking background) overlaps conceptually with the sibling describe_notation and dilutes the essential invocation guidance.

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

Completeness4/5

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

With no annotations and no output schema, the description must cover invocation, and it does so thoroughly (syntax, mandatory edge types, labeling rules, a complete example). The only notable omission is the return value — where the PNG goes or how it is referenced — which the absent output schema does not cover.

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

Parameters4/5

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

Schema coverage is 100% for the single 'vgl' parameter, so the baseline is 3, but the description goes further by spelling out the required VGL grammar ('vgraph <id>: CLD "<title>" { ... }'), node/edge syntax, and a full worked example — genuinely additive semantics beyond the schema line.

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 first sentence states a specific verb+resource+output ('Create a CLD diagram as PNG image'), and the body defines CLD so an agent can distinguish it from siblings like create_concept_map or create_timeline. The scope is unambiguous.

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

Usage Guidelines3/5

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

The description gives extensive guidance on how to build a CLD (polarity, loops, rules), but never states when to choose this tool over the sibling diagram tools (create_concept_map, create_ibis, create_timeline) or when it is inappropriate. Usage is implied by domain rather than explicitly routed.

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.