Skip to main content
Glama

List Available Diagram Templates

diagrams_list_templates
Read-onlyIdempotent

Lists built-in and custom diagram template names available to instantiate, so you can pick a skeleton before generating PlantUML or Mermaid diagrams.

Instructions

Discover the diagram templates diagrams_template can instantiate, without reading any template contents.

Lists the built-in skeleton kinds (each supports 'puml' and 'mermaid') plus the custom-template candidate names found as *.json entries directly under PROJECT_ROOT/.diagrams-templates. A candidate name is an identifier to pass as custom_template to diagrams_template with template='custom'; the definition, the selected dialect, and the emitted source are validated there, not here. Discovery reads directory entries only — file contents are never read, so a malformed JSON file can still appear as a candidate — and it never writes or creates a missing template directory.

The scan is bounded: at most 1000 directory entries are examined (MAX_TEMPLATE_SCAN_ENTRIES), counting non-template entries too, plus one lookahead to detect the cap. There is no pagination, no full directory total, and no global subset ordering promised when capped: custom_count describes only the returned candidates, and the returned names are sorted only within the capped subset, which depends on filesystem iteration order.

Args: (none): Call with {} — discovery takes no arguments.

Returns: JSON with schema: { "built_in": [ // one entry per built-in kind, in documented order { "template": "class" | "sequence" | "c4_context", "formats": ["puml", "mermaid"] } ], "custom": [ // candidate names, sorted within the scanned subset { "template": "custom", "custom_template": string, "relative_path": string } ], "custom_count": number, // length of "custom": returned candidates only, not a full total when capped "entries_scanned": number, // directory entries examined, including non-template entries "scan_limit": number, // 1000 "truncated": boolean, // true when the entry cap was reached "scan_warning": string | null,// human-readable warning when truncated, otherwise null "written": false // always false; discovery never writes }

Each custom relative_path identifies the project-relative file '.diagrams-templates/.json'. Pass the custom_template identifier, not this path, to diagrams_template.

Examples:

  • Use when: "What templates are available?" -> call with {}

  • Use when: "Do we have a team skeleton?" -> call with {}, then look for its name in "custom"

  • Use when: "Which built-in starter should I use?" -> call with {}, then pass one of the built_in names to diagrams_template

  • Don't use when: You want the skeleton source itself (use diagrams_template with a name from this listing)

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

Error Handling:

  • Unknown argument fields are rejected: discovery accepts only {}

  • A missing .diagrams-templates directory is not an error: "custom" is empty with truncated=false and scan_warning=null

  • Subdirectories, symlink files/directories, invalid identifiers, and extensions other than .json are excluded, not errors

  • A .diagrams-templates path that is not a regular directory is rejected without exposing absolute paths

  • Expected filesystem access failures return CustomTemplateError without absolute paths

  • 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

No arguments

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?

Annotations already establish read-only, idempotent, non-destructive, closed-world behavior, and the description adds substantial context beyond them: the bounded 1000-entry scan, absence of pagination or global ordering, the fact that malformed JSON still surfaces as a candidate, that the directory is never created, and that paths are never exposed in errors. This is far richer than the annotations.

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?

Front-loaded with purpose before details, and each section is labeled (Args, Returns, Examples, Error Handling). It is longer than average, but the length is largely justified because no output schema exists and the return shape must be documented inline; the density is high but not padded.

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?

With no output schema, the description carries the full burden of describing the return payload and does so completely, including field-by-field semantics (custom_count vs entries_scanned, truncated, scan_warning, written). Error behavior and edge cases (missing directory, non-directory path, symlinks) are covered, so an agent needs nothing else.

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?

Zero parameters, so the baseline is 4. The description reinforces this with 'Call with {}' and notes that unknown argument fields are rejected, which is a small value-add over the empty schema with additionalProperties:false.

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?

States a specific verb and resource ('Discover the diagram templates diagrams_template can instantiate') and immediately distinguishes itself from the instantiating sibling by noting it reads no template contents. An agent can tell it apart from diagrams_template, diagrams_generate and diagrams_scaffold without opening any schema.

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?

Provides explicit 'Use when' scenarios and, more importantly, 'Don't use when' exclusions that route to alternatives (diagrams_template for source, diagrams_generate/diagrams_generate_sequence for generated content). When-to-use and when-not-to-use are both spelled out.

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