Skip to main content
Glama

create_concept_map

Create a ConceptMap diagram as PNG image. A Concept Map defines the vocabulary of a domain through falsifiable propositions. It helps people align on exact wordings and shared understanding by stating facts as simple, readable sentences.

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

How to Build a Concept Map

  1. Start with a Guiding Question (used as the graph title) — it determines what belongs on the map.

  2. List all relevant concepts.

  3. Connect every concept through relations. ALWAYS form readable propositions.

  4. NEVER leave a concept unconnected. Every concept MUST connect to at least one relation.

  5. Reuse relations when multiple concepts share the same relationship.

VGL Syntax

vgraph <id>: ConceptMap "<Guiding Question>" {
    <nodes and edges>
}

Node Types

  • Concept — A noun or term placed in relation to others. Concepts are connected through Relations to form falsifiable propositions.

  • EmphasizedConcept — A highlighted concept to draw attention to key terms. Use sparingly for maximum impact.

  • Relation — A verb or linking phrase connecting two concepts. Together with source and target, forms a falsifiable proposition.

node <id>: Concept "<label>"
node <id>: EmphasizedConcept "<label>"
node <id>: Relation "<label>"

Edges

Valid connections:

  • Concept → Relation — A Concept connects to a Relation, forming the source of a proposition.

  • Relation → Concept — A Relation points to a Concept, completing the proposition.

  • EmphasizedConcept → Relation — An Emphasized Concept connects to a Relation, forming the source of a proposition.

  • Relation → EmphasizedConcept — A Relation points to an Emphasized Concept, completing the proposition.

edge <from_id> -> <to_id>

ALWAYS form the pattern: Concept -> Relation -> Concept. This creates a readable proposition.

Reusing Relations

When multiple concepts share the same relationship, reuse a single Relation node. No duplicate edges when reusing — create edges only where needed:

Multiple sources, one target:

vgraph animals: ConceptMap "What are common pets?" {
    node dog: Concept "Dog"
    node cat: Concept "Cat"
    node isa: Relation "is a"
    node mammal: Concept "Mammal"

    edge dog -> isa
    edge cat -> isa
    edge isa -> mammal  // Only ONE edge from relation to target
}

Both "Dog is a Mammal" and "Cat is a Mammal" share one Relation node — only 4 nodes total.

One source, multiple targets:

vgraph typography: ConceptMap "What defines a font?" {
    node font: Concept "Font"
    node has: Relation "has"
    node weight: Concept "Weight"
    node style: Concept "Style"

    edge font -> has  // Only ONE edge from source to relation
    edge has -> weight
    edge has -> style
}

Both "Font has Weight" and "Font has Style" share one Relation node — only 4 nodes total.

CRITICAL — Multiple inbound AND multiple outbound edges:

When a relation has BOTH multiple inbound edges (concepts pointing TO the relation) AND multiple outbound edges (relation pointing TO concepts), ALL inbound concepts must make sense as propositions with ALL outbound concepts. With n inbound and m outbound edges, you get n × m propositions — all must be valid.

Invalid example:

vgraph learning: ConceptMap "What enables growth?" {
    node learning: Concept "Learning"
    node accountability: Concept "Accountability"
    node enables: Relation "enables"

    edge learning -> enables
    edge accountability -> enables
    edge enables -> learning
    edge enables -> accountability
}

This creates 4 propositions (2 × 2):

  • Learning enables Learning ❌ (circular)

  • Learning enables Accountability ✓

  • Accountability enables Learning ✓

  • Accountability enables Accountability ❌ (circular)

Fix — Use specific relations:

vgraph learning: ConceptMap "What enables growth?" {
    node learning: Concept "Learning"
    node accountability: Concept "Accountability"
    node facilitates: Relation "facilitates"
    node requires: Relation "requires"

    edge accountability -> facilitates
    edge facilitates -> learning

    edge learning -> requires
    edge requires -> accountability
}

Now: "Accountability facilitates Learning" ✓ and "Learning requires Accountability" ✓

Fix — Restructure:

vgraph learning: ConceptMap "What enables growth?" {
    node learning: Concept "Learning"
    node accountability: Concept "Accountability"
    node environment: Concept "Environment"
    node creates: Relation "creates"

    edge learning -> creates
    edge accountability -> creates
    edge creates -> environment
}

Now: "Learning creates Environment" ✓ and "Accountability creates Environment" ✓

Complete Example

vgraph learningCM: ConceptMap "What is Learning?" {
    node student: Concept "Student"
    node subject: Concept "Subject"
    node practice: EmphasizedConcept "Practice"
    node understanding: Concept "Understanding"
    node resources: Concept "Resources"

    node learns: Relation "learns"
    node requires: Relation "requires"
    node leads_to: Relation "leads to"
    node uses: Relation "uses"

    edge student -> learns
    edge learns -> subject
    edge subject -> requires
    edge requires -> practice
    edge practice -> leads_to
    edge leads_to -> understanding
    edge subject -> uses
    edge uses -> resources
}

Propositions: Student learns Subject, Subject requires Practice, Practice leads to Understanding, Subject uses Resources.

Rules

  1. ALWAYS form readable propositions — every Concept -> Relation -> Concept chain MUST read as a natural, falsifiable sentence

  2. NEVER leave a concept unconnected

  3. Concept labels are nouns — concept labels should be nouns or noun phrases (things, ideas, entities), not actions, sentences, or verb phrases. Use "Understanding" not "How we understand things"

  4. Verb agreement — Relation labels must match the subject's number: singular concepts (e.g., "Student", "Dog") use singular verbs ("requires", "is", "has"); plural concepts (e.g., "LLMs", "Dogs") use plural verbs ("require", "are", "have"). For mixed cases, use infinitive form without "(s)": "enable" not "enables", "prevent" not "prevents". The notation "Dog(s)" in concept labels can indicate the concept works in both forms, then use infinitive verb forms.

  5. Guiding question as filter — the guiding question determines what belongs on the map. Every concept MUST help answer it. If a concept does not contribute to answering the guiding question, it does not belong.

  6. Relationship diversity — use diverse relation types (not all "is a" or "has"). Avoid simple opposite pairs (e.g. "is parent of" / "is child of" are the same relationship stated twice in different directions). Use different verbs that reveal distinct aspects of how concepts relate.

  7. Rich connectivity — every concept should connect to at least 2 others via different relations. Aim for a network structure where multiple paths exist between concepts — not a chain (linear A→B→C) or a spoke (one central concept with everything hanging off it).

  8. Use meaningful IDs (student, practice — not n1, n2)

  9. Keep relation labels short (verbs or short phrases)

  10. Use EmphasizedConcept sparingly

  11. Introduce abbreviations — if a concept label uses an abbreviation, spell out the full term first: e.g. "Gross National Product (GNP)", not just "GNP"

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_concept_map"
  }
}

Input Schema

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

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.5/5.0
Behavior3/5

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

With no annotations, the description carries the full burden; it does disclose the concrete output (PNG render of supplied VGL) and the structural rules the input must satisfy. However it never says what happens on invalid VGL (error vs. partial render), whether anything is persisted, or any permissions/limits, which are meaningful gaps for a zero-annotation mutation-style tool.

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?

Purpose is front-loaded, which is good, but the body is a full DSL tutorial with duplicated examples (two nearly identical reuse snippets, two fix variants for the same pitfall) and 11 numbered rules. Much of this belongs in a referenced doc or resource rather than the selection-surface description.

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?

For a one-parameter tool with no output schema, the description is thorough on the only thing the agent must produce, and no return-value explanation is needed because the output format is stated as PNG. The missing pieces are failure behavior on malformed VGL and any routing hint toward the diagram-notation siblings.

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 well beyond it by specifying the required vgraph header, node/edge grammar, allowed edge patterns, and rules that constrain the value. That is genuine added meaning about how to construct the parameter, not a restatement.

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?

The first sentence gives a specific verb, resource and output format: 'Create a ConceptMap diagram as PNG image', followed by a concise definition of what a concept map is. It is clearly distinguishable from a timeline or IBIS diagram by subject matter, but it never names the siblings (create_cld, create_ibis, create_timeline), so the agent must infer differentiation.

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?

Usage is only implied — the description assumes the caller already knows they want a ConceptMap and instead spends its length teaching VGL syntax. There is no explicit 'use this when…, use create_cld/create_ibis instead when…' routing, and the sibling 'describe_notation' that could clarify notation choice is never mentioned.

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.