Skip to main content
Glama

Instantiate a Diagram Skeleton

diagrams_template
Read-onlyIdempotent

Emit a class, sequence, or C4-context PlantUML/Mermaid skeleton or custom project template, returning validated source text to fill in and save with diagrams_create.

Instructions

Emit a built-in starter skeleton (class, sequence, or C4-context) or a custom project template in PlantUML or Mermaid, returning validated source text to fill in and then save with diagrams_create.

Built-in skeletons are pure and require no filesystem or code scan. Custom templates read one named JSON file under PROJECT_ROOT/.diagrams-templates; identical inputs and file contents yield identical source. No template evaluates code or fetches remote resources.

It never writes: nothing lands in the diagrams directory without an explicit diagrams_create call, and the emitted source clears the exact syntax gate that tool enforces, so the output can be saved as-is.

The three built-in kinds are 'class', 'sequence', and 'c4_context'. Use 'custom' with custom_template to load .json. The selected 'puml' or 'mermaid' object must contain 'source' and 'entity' strings. Source placeholders are {{title}} and {{entities}}; entity patterns support {{name}}. Reads are limited to 65536 bytes and expansion to 1000000 JavaScript string characters. Files must be regular files inside the template directory; symlinks, unknown fields, and unsupported placeholders are rejected.

Args:

  • template ('class' | 'sequence' | 'c4_context' | 'custom', required): Which starter skeleton to emit

  • custom_template (string, required only for custom): Identifier without path or extension, 1-64 letters, digits, underscores or hyphens

  • format ('puml' | 'mermaid', default 'puml'): Output dialect

  • title (string, optional, at most 200 chars): Diagram title; whitespace-only is rejected, never an empty title line

  • entities (string[], 1-20 items): Entity names, each an identifier matching /^[A-Za-z_][A-Za-z0-9_]*$/ at most 60 chars, no duplicates

Returns: JSON with schema: { "template": "class" | "sequence" | "c4_context" | "custom", "custom_template": string, // present only for custom templates "format": "puml" | "mermaid", "title": string | null, // the normalized one-line title, or null when none was given "source": string, // the skeleton; identical to the text block "entities": string[], // the names as accepted, in input order "entities_included": number, // length of "entities" "deterministic": true, // same inputs and template contents yield the same source "written": false // always false; save with diagrams_create }

Examples:

  • Use when: "Start a class diagram for the order model" -> template="class", entities=["User","Order"]

  • Use when: "Give me a Mermaid sequence skeleton for these services" -> template="sequence", format="mermaid", entities=["Checkout","Payment"]

  • Use when: "Sketch the C4 context for this system" -> template="c4_context", entities=["Web","Billing"]

  • Don't use when: You want generated content from code (use diagrams_generate or diagrams_generate_sequence)

  • Use when: "Use our team skeleton" -> template="custom", custom_template="team-model", entities=["User"]

Error Handling:

  • Input validation rejects unknown kinds/formats/keys, invalid custom identifiers, over-limit or whitespace-only titles, and invalid/duplicate/over-limit entity names

  • CustomTemplateError messages explain missing custom_template, invalid built-in/custom combinations, unreadable or invalid JSON files, unsupported dialects/placeholders, and read/expansion limits without exposing absolute paths

  • Emitted source passes the same syntax gate diagrams_create enforces; invalid template output returns a diagram validation error

  • Unexpected internal failures return a generic "Error: Unexpected internal error ..." with isError:true and are logged to stderr without source, paths, or secrets

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
titleNoOptional diagram title, at most 200 characters. Whitespace-only is rejected rather than emitting an empty title line. Internal whitespace runs are collapsed so the title stays one line, and the normalized value is what the source and the structured output report.
formatNoOutput dialect for the skeleton (default: 'puml').puml
entitiesYesEntity names to instantiate, 1 to 20 of them, each an identifier matching /^[A-Za-z_][A-Za-z0-9_]*$/ at most 60 characters long, with no duplicates. Names are emitted in the given order, one declaration each.
templateYesWhich starter skeleton to emit: 'class' (a box per entity), 'sequence' (a participant per entity), 'c4_context' (one context-level system per entity), or 'custom' (a named JSON template in the project's .diagrams-templates directory).
custom_templateNoCustom template identifier without extension or path; required only when template is 'custom'.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.10.0

TDQS

A4.8/5.0
Behavior5/5

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

Beyond the readOnly/idempotent/non-destructive annotations, the description discloses determinism, that built-in kinds perform no filesystem or code scan, that custom templates read exactly one JSON file under PROJECT_ROOT/.diagrams-templates, hard read/expansion limits (65536 bytes, 1,000,000 characters), symlink/unknown-field/unsupported-placeholder rejection, and the guarantee that it never writes. It also states the emitted source clears the same syntax gate diagrams_create enforces, and describes the generic-error fallback.

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?

Purpose, purity guarantees, and the never-writes contract are front-loaded, and the Examples plus Error Handling sections are well-structured and earn their space. The verbatim Args restatement is redundant at 100% schema coverage, and the Returns block partially repeats the 'written: false; save with diagrams_create' point made earlier, so it is slightly longer than necessary.

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?

Since no output schema is declared, the explicit Returns JSON with field-by-field comments is exactly the missing piece and is supplied. Error taxonomy, limits, and the save-via-diagrams_create handoff are all covered, leaving no meaningful gap for an agent to call this tool correctly.

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 description coverage is 100%, so the baseline is 3; the description goes beyond it by documenting template-placeholder semantics ({{title}}, {{entities}}, entity-level {{name}}), the conditional nature of custom_template, and the cross-field rule that the selected dialect object must contain 'source' and 'entity' strings. The Args block largely restates the schema, so it does not lift this to a 5.

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 gives a specific verb (emit) and resource (built-in starter skeleton or custom template) plus the output form (validated PlantUML/Mermaid source). It explicitly distinguishes itself from siblings by naming diagrams_create as the follow-up write step and diagrams_generate / diagrams_generate_sequence as the code-derived alternatives.

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

Usage Guidelines5/5

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

Usage is spelled out both in prose ('Built-in skeletons are pure and require no filesystem or code scan') and in a Use when / Don't use when example list that maps concrete intents to parameter combinations. The 'Don't use when you want generated content from code' line routes the agent to the correct sibling without inference.

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