Concept Maps, IBIS, Causal Loop Diagrams and Timelines as images. Runs locally via WebAssembly.
Glama couldn't complete the latest health check. If this server requires authentication, missing or expired test credentials may be the cause. A test profile lets Glama authenticate for health checks and discover tools; it is separate from your personal connections.
If you are the author, claim ownership, then add or update a test profile under Admin → Test Profile.
Scored across 5 tools
Each of the four create_* tools targets a distinct diagram notation (CLD, ConceptMap, IBIS, Timeline), and describe_notation is clearly a documentation tool rather than a diagram creator. There is no realistic ambiguity between any two tools.
Tool names follow a consistent verb_noun pattern: create_* for the four diagram types and describe_notation for the supporting documentation operation. The naming is uniform, lowercase, and predictable.
Five tools is a well-scoped size for a diagram-rendering server: four creation tools for distinct notation types plus one documentation tool. Each tool has a clear purpose and the set does not feel bloated or thin.
The tool surface covers the core workflow of creating four major diagram types and retrieving notation documentation. A minor gap is the lack of a way to list or discover available notations without already knowing their names.
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.
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.
Identify the key variables (stocks) in the system — things whose value can increase or decrease.
For each pair of causally related variables, determine the polarity: does an increase in A cause B to increase (same) or decrease (opposite)?
Trace closed loops and classify them as reinforcing or balancing using the counting rule.
Give the diagram a title that frames the system boundary.
vgraph <id>: CLD "<title>" {
<nodes and edges>
}Stock — a variable whose value changes over time (blue circle). Examples: Population, Revenue, Stress, Trust.
node <id>: Stock "<label>"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>: oppositeTo 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.
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.
ALWAYS specify the edge type (: same or : opposite) — it cannot be inferred
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")
Every Stock MUST connect to at least one other Stock — no isolated variables
Think in terms of "if A increases, what happens to B?" to determine same vs opposite polarity
Use meaningful IDs (population, revenue, stress — not n1, n2, n3)
Keep the diagram focused on one system — the title should frame the boundary
Aim for closed loops — a CLD without any feedback loop is just a causal chain and misses the point of systems thinking
Prefer 3–6 variables per loop for clarity — larger loops are hard to trace and verify
| Name | Required | Description | Default |
|---|---|---|---|
| vgl | Yes | Valid VGL code using the CLD notation. Must start with: vgraph <id>: CLD "<title>" { ... } |
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.
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.
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.
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.
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.
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.
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.
Start with a Guiding Question (used as the graph title) — it determines what belongs on the map.
List all relevant concepts.
Connect every concept through relations. ALWAYS form readable propositions.
NEVER leave a concept unconnected. Every concept MUST connect to at least one relation.
Reuse relations when multiple concepts share the same relationship.
vgraph <id>: ConceptMap "<Guiding Question>" {
<nodes and edges>
}Concept — a concept or term
EmphasizedConcept — a concept to highlight as especially important
Relation — a linking verb or phrase that connects concepts
node <id>: Concept "<label>"
node <id>: EmphasizedConcept "<label>"
node <id>: Relation "<label>"edge <from_id> -> <to_id>ALWAYS form the pattern: Concept -> Relation -> Concept. This creates a readable proposition.
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" ✓
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.
ALWAYS form readable propositions — every Concept -> Relation -> Concept chain MUST read as a natural, falsifiable sentence
NEVER leave a concept unconnected
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"
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.
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.
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.
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).
Use meaningful IDs (student, practice — not n1, n2)
Keep relation labels short (verbs or short phrases)
Use EmphasizedConcept sparingly
Introduce abbreviations — if a concept label uses an abbreviation, spell out the full term first: e.g. "Gross National Product (GNP)", not just "GNP"
| Name | Required | Description | Default |
|---|---|---|---|
| vgl | Yes | Valid VGL code using the ConceptMap notation. Must start with: vgraph <id>: ConceptMap "<title>" { ... } |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral disclosure burden. It transparently documents the rendering behavior, the required Concept -> Relation -> Concept pattern, the constraint that every concept must connect, and the critical n×m proposition semantics for reused relations. It does not specify error handling or validation behavior, but the core behavior is thoroughly described.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but exceptionally well-structured with headings, code blocks, examples, and numbered rules. It front-loads the core purpose and then systematically covers syntax and pitfalls. Every section contributes to enabling correct VGL generation, so the length is justified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with no output schema, the description is remarkably complete. It covers the full VGL syntax, node and edge types, relation reuse, proposition validity, style rules, and a complete example. An agent has all necessary information to produce a valid ConceptMap VGL code.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although the schema already describes the `vgl` parameter at 100% coverage, the description massively expands its semantics with full VGL syntax, node types, edge syntax, reusable relation patterns, invalid examples, and fixes. It provides far more than the schema alone, making parameter usage unambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The opening sentence states a specific action and resource: 'Create a ConceptMap diagram as PNG image' and explains what a ConceptMap is. It clearly identifies the tool's purpose, though it does not explicitly distinguish itself from sibling tools like create_cld or create_ibis beyond the name and unique notation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when a ConceptMap is appropriate, e.g., 'It helps people align on exact wordings and shared understanding' and explains the guiding question as a filter. It does not explicitly state when to use this tool versus its siblings, but the use case is well defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a IBIS diagram as PNG image. IBIS (Issue-Based Information System) maps out any decision, discussion, or thought process using just four node types: Questions, Answers (Ideas), Pros, and Cons. Attaching Questions to any node lets you drill into any aspect at any depth.
You provide VGL (Vithanco Graph Language) code using the IBIS notation and the tool renders it to an PNG image.
Start with a root Question (used as the graph title).
Add Answers (Ideas) that respond to the question.
Add Pro and Con arguments for each answer.
Attach further Questions to any node to drill deeper.
Keep going until the topic is explored to the depth you need.
vgraph <id>: IBIS "<title>" {
<nodes and edges>
}Question — a question or issue to explore (purple, question mark icon)
Answer — an idea or proposed answer (amber, lightbulb icon)
Pro — an argument in favour of an answer (green, thumbs up icon)
Con — an argument against an answer (red, thumbs down icon)
node <id>: Question "<label>"
node <id>: Answer "<label>"
node <id>: Pro "<label>"
node <id>: Con "<label>"Edge types are inferred from node types — just write edge <from> -> <to>.
Valid connections:
Question -> Answer (answering the question)
Answer -> Pro (supporting argument)
Answer -> Con (opposing argument)
Question -> Question (sub-question of a question)
Answer -> Question (answer raises new question)
Pro -> Question (pro raises new question)
Con -> Question (con raises new question)
edge <from_id> -> <to_id>The power of IBIS is that you can attach a Question to any node type:
Question a Question: "Shouldn't we rather discuss X?"
Question an Answer: "What would we need to implement this?"
Question a Pro: "Is this advantage really significant?"
Question a Con: "Can we mitigate this disadvantage?"
Each sub-question starts its own Answer/Pro/Con branch, allowing unlimited depth.
vgraph techChoice: IBIS "Which database should we use?" {
node q1: Question "Which database should we use?"
node a1: Answer "PostgreSQL"
node a2: Answer "MongoDB"
edge q1 -> a1
edge q1 -> a2
node pro1: Pro "ACID compliance"
node pro2: Pro "Mature ecosystem"
node con1: Con "Schema migrations can be complex"
edge a1 -> pro1
edge a1 -> pro2
edge a1 -> con1
node pro3: Pro "Flexible schema"
node con2: Con "Weaker transaction support"
edge a2 -> pro3
edge a2 -> con2
node q2: Question "How to handle schema migrations?"
edge con1 -> q2
node a3: Answer "Use Flyway or Liquibase"
edge q2 -> a3
node pro4: Pro "Industry-standard tooling"
edge a3 -> pro4
}ALWAYS start with a root Question — it frames the entire diagram
Follow the structure: Question -> Answer -> Pro/Con
Use Questions to drill down — attach them to any node that needs exploration
Keep labels concise — Questions as questions, Answers as noun phrases, Pros/Cons as short statements
Use meaningful IDs (q1, mainIdea, costCon — not n1, n2, n3)
Each Answer should have at least one Pro or Con to be useful
Avoid orphan nodes — every node must connect to the tree
| Name | Required | Description | Default |
|---|---|---|---|
| vgl | Yes | Valid VGL code using the IBIS notation. Must start with: vgraph <id>: IBIS "<title>" { ... } |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It discloses important constraints: edge types are inferred from node types, only certain connections are valid, a root Question is required, and orphan nodes should be avoided. It does not mention error handling for invalid VGL, but overall behavior is well specified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long, but the length is warranted because it documents a custom mini-language. It is well structured with headings, syntax blocks, an example, and rules. Some redundancy exists between the intro and drill-down sections, but the organization earns the length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with no output schema, the description is unusually complete. It covers how to structure the input, valid nodes and edges, drill-down behavior, a full example, and best-practice rules. An agent has everything needed to construct a valid call.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although the schema already describes the vgl parameter at 100% coverage, the description adds substantial meaning: full VGL syntax, node types, edge rules, a complete example, and construction rules. This goes far beyond the schema and makes the expected input concrete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Create a IBIS diagram as PNG image.' It clearly distinguishes this tool from siblings by centering on the IBIS notation and VGL input, not generic diagrams. The scope is immediately understandable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when IBIS is appropriate: 'any decision, discussion, or thought process.' It does not explicitly exclude alternatives like concept maps or timelines, but the IBIS-specific guidance makes the intended use apparent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a Timeline diagram as PNG image. A Timeline visualises events over time, optionally across multiple parallel tracks (groups). The default layout is left-to-right but can be changed to any direction. The base notation provides generic TimePoint and Event types — use vnotation extends Timeline to define domain-specific event types (e.g. Battle, Treaty, Release, Incident) with custom colours and categories.
You provide VGL (Vithanco Graph Language) code using the Timeline notation and the tool renders it to an PNG image.
The key mechanism is the alignGroup attribute. Nodes sharing the same alignGroup value are placed at the same position in the layout — pinned to the same column (left-to-right) or the same row (top-to-bottom). This is what creates time alignment.
node t1800: TimePoint "1800" [alignGroup: "1800"]
node e1: Event "Something happened" [alignGroup: "1800"]These two nodes will appear at the same horizontal position because they share alignGroup "1800".
Choose a title that describes the scope of the timeline.
Decide whether you need TimePoints (axis markers) or whether alignGroup alone suffices.
Add Events for things that happened, each with an alignGroup matching its time.
Use sequence edges between TimePoints to form the visible time axis.
Use influence edges between Events to show causal or contextual links.
Optionally use groups to create named parallel tracks (countries, teams, systems).
vgraph <id>: Timeline "<title>" {
<nodes, edges, and groups>
}TimePoint — an axis marker (date, phase, milestone label). Small gray box. Optional.
Event — something that happened. Steel-blue rounded box.
node <id>: TimePoint "<label>" [alignGroup: "<time_value>"]
node <id>: Event "<label>" [alignGroup: "<time_value>"]ALWAYS include alignGroup on every node to ensure correct time alignment.
sequence — connects TimePoint to TimePoint, forming the time axis (solid gray arrow).
influence — connects Event to Event, showing causal or contextual links (dashed arrow, does not distort layout). Can have an optional label.
edge <from_id> -> <to_id>: sequence
edge <from_id> -> <to_id>: influence
edge <from_id> -> <to_id>: influence "<label>"Groups create named parallel tracks rendered as labelled cluster boxes. Groups are optional.
group <id> "<label>" {
node <id>: Event "<label>" [alignGroup: "<value>"]
}The default is left-to-right. Use vnotation extends Timeline to change direction. All four directions are supported: topToBottom, bottomToTop, leftToRight, rightToLeft.
vnotation VerticalTimeline extends Timeline {
layout: topToBottom
}
vgraph myTimeline: VerticalTimeline "My Timeline" {
...
}For domain-specific timelines, use vnotation extends Timeline to add custom node types, edge types, and change the layout — all in one block. The base TimePoint and Event types plus sequence and influence edges remain available.
vnotation WarTimeline extends Timeline {
layout: topToBottom
node type: Battle [nodeStyle: withCategory, color: "#883333", category: "Battle"]
node type: Treaty [nodeStyle: withCategory, color: "#339933", category: "Treaty"]
edge type: resolved_by from: Battle to: Treaty
edge type: influenced from: Battle to: Battle
}
vgraph napoleonicWars: WarTimeline "Napoleonic Wars" {
node t1805: TimePoint "1805" [alignGroup: "1805"]
node t1812: TimePoint "1812" [alignGroup: "1812"]
node t1815: TimePoint "1815" [alignGroup: "1815"]
edge t1805 -> t1812: sequence
edge t1812 -> t1815: sequence
node f1: Battle "Battle of Austerlitz" [alignGroup: "1805"]
node f2: Battle "Invasion of Russia" [alignGroup: "1812"]
node f3: Battle "Battle of Waterloo" [alignGroup: "1815"]
node e1: Treaty "Treaty of Pressburg" [alignGroup: "1805"]
node e2: Treaty "Congress of Vienna" [alignGroup: "1815"]
edge f1 -> e1: resolved_by
edge f3 -> e2: resolved_by
edge f1 -> f2: influenced "overconfidence"
edge f2 -> f3: influenced "weakened army"
}vgraph europe: Timeline "19th Century Europe" {
node t1800: TimePoint "1800" [alignGroup: "1800"]
node t1850: TimePoint "1850" [alignGroup: "1850"]
node t1871: TimePoint "1871" [alignGroup: "1871"]
edge t1800 -> t1850: sequence
edge t1850 -> t1871: sequence
group germany "Germany" {
node g1: Event "Napoleon defeats Prussia" [alignGroup: "1800"]
node g2: Event "German Unification" [alignGroup: "1871"]
}
group england "England" {
node e1: Event "Industrial Revolution peaks" [alignGroup: "1850"]
node e2: Event "Franco-Prussian War impact" [alignGroup: "1871"]
}
edge g1 -> g2: influence "led to"
edge e1 -> e2: influence
edge e1 -> g2: influence "industrialization enabled"
}ALWAYS use alignGroup on every node to ensure correct time alignment.
TimePoints are optional — alignGroup alone suffices for alignment.
Keep TimePoint labels short (dates, phase names).
Use influence edges sparingly — only for meaningful causal or contextual links.
Use meaningful IDs (t1800, battleOfWaterloo — not n1, n2).
Groups are optional — use them when you have distinct parallel tracks.
When you need domain-specific event types, use vnotation extends Timeline — don't overload the generic Event type.
When changing layout direction, always use vnotation extends Timeline with a layout: directive — the base Timeline is always left-to-right.
| Name | Required | Description | Default |
|---|---|---|---|
| vgl | Yes | Valid VGL code using the Timeline notation. Either `vgraph <id>: Timeline "<title>" { ... }` directly, or a `vnotation <Name> extends Timeline { ... }` block followed by `vgraph <id>: <Name> "<title>" { ... }`. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Given no annotations, the description takes on the burden and covers behavior thoroughly: it explains the rendering process, output is PNG, core mechanisms like alignGroup, and constraints like 'ALWAYS include alignGroup on every node'. It also discloses extensibility (vnotation) and layout options. Minor gap: it doesn't explicitly state read-only or side effects, but since it's a create/render tool, that's implied.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very long (over 1000 words) with extensive code examples and detailed syntax. While it's well-structured with headers and examples, it goes beyond what's needed for an agent to understand the tool's purpose and usage. It could be more concise, for example, by linking to full documentation instead of restating all syntax. The 'should be front-loaded' principle is violated since the core concept comes after a fairly long introduction.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of VGL and the absence of an output schema, the description is remarkably complete. It covers all aspects needed to successfully call the tool: syntax, node types, edges, groups, layout customization, custom types, and rules. It even provides multiple examples. For a tool that requires specialized domain language, this level of detail is necessary for correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a single parameter (vgl). The description adds substantial value by explaining VGL syntax, node types, edges, and examples, going far beyond the schema's one-line description. However, since there's only one parameter and the schema already describes it, the baseline is 3, and the description's extensive syntax guidance adds value but isn't necessary for basic use.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: creating a Timeline diagram as a PNG from VGL code. It specifies the resource (Timeline diagram) and the output format, and differentiates from siblings by focusing on the Timeline notation and time-based visualization, which is distinct from concept maps or IBIS diagrams.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool: when creating a timeline to visualize events over time. It also gives detailed instructions on how to construct timelines, including step-by-step guidance and rules, which indirectly tells users when not to use it (e.g., for non-time-based relationships, use other diagram tools).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the self-describing Markdown document for a built-in VGraph notation. The document includes the notation's purpose, when to use it, node types, edge types, history, and references.
| Name | Required | Description | Default |
|---|---|---|---|
| notation | Yes | Name of the built-in notation |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It describes the return value (a Markdown document with specific sections) but does not explicitly state that the operation is read-only and side-effect-free. The verb 'Return' implies a read operation, but for a tool without annotations, a more explicit statement (e.g., 'This does not modify any data') would be more transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the primary action and resource, then lists the document's contents. Every word contributes to understanding the tool's output, with no redundancy or irrelevant details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has one parameter with an enum and a clear description, and the description fully explains what the returned document contains. No output schema is present, but the description adequately covers the return format and content. For a simple getter, nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides a description for the single parameter ('Name of the built-in notation') and an enum listing valid values (['IBIS']). The tool description adds no further semantic detail beyond what the schema provides. With 100% schema coverage, the description's minimal parameter info is acceptable, but it does not enrich the parameter's meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Return') and resource ('self-describing Markdown document for a built-in VGraph notation'), and enumerates the document's contents (purpose, usage, node types, edge types, history, references). This clearly distinguishes it from sibling create_* tools, which focus on creation rather than documentation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool (when you need the documentation for a notation) by listing the document's contents, including 'when to use it.' However, it does not explicitly contrast with the sibling create_* tools or state when not to use it. Given that siblings are all creation tools, the usage context is clear but not explicitly exclusionary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
create_cldcreate_concept_mapcreate_ibiscreate_timelinedescribe_notationFlowcharts that people and agents edit together on one live canvas, exported as Mermaid.
AI-powered diagrams, mind maps, flowcharts on a free unlimited collaborative whiteboard
Visual AI for strategic thinking — SWOT, flowcharts, mindmaps, Gantt diagrams as polished SVG.
Turn AI conversations into visual knowledge maps. Create, connect, search, and organize thoughts.
Add one secure layer between your agents and this server.
