Skip to main content
Glama

Generate a Class Diagram from Code

diagrams_generate
Read-onlyIdempotent

Draft PlantUML or Mermaid class diagrams from a codebase slice, returning source text to review and save with diagrams_create.

Instructions

Draft a PlantUML or Mermaid class diagram from a slice of the codebase, returning source text to review and then save with diagrams_create.

This is the generative flip side of diagrams_check_consistency: the same code-reading machinery that detects drift can seed the diagram in the first place. It reads class/interface/enum/type/function declarations under the requested scope and emits one box per declared name, plus extends/implements edges when the TypeScript AST can evidence them. It never writes: nothing lands in the diagrams directory without an explicit diagrams_create call.

It is a heuristic (name extraction, not full type modeling) and says so in every result: member lists, generics, package nesting, and cross-file inheritance through re-exports are out of scope, and a scope without TypeScript-family files yields entities with no relations.

Args:

  • scope (string, default "."): Relative path under the project root pointing at a file or a directory. Absolute paths and anything resolving outside the project root are refused

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

  • max_entities (integer 1-60, default 30): Hard cap on emitted declarations

  • include_relations (boolean, default true): Emit extends/implements edges when evidence is available

Returns: JSON with schema: { "scope": string, // POSIX path as resolved, "." for the project root "format": "puml" | "mermaid", "source": string, // the generated diagram; identical to the text block "entities": string[], // declared names in emission order, capped "entities_included": number, // length of "entities" "entities_available": number, // distinct names found, may exceed the cap "entities_capped": boolean, // true when names were dropped by the cap "entity_limit": number, // the applied cap (max_entities, at most 60) "relations": [ // evidenced edges only; empty when evidence is unavailable { "from": string, "to": string, "kind": "extends" | "implements" } ], "relations_included": number, "relations_available": number, "relations_capped": boolean, // true when edges were dropped by the cap or by an entity the cap removed "relation_limit": number, // 60 "files_scanned": number, "truncated": boolean, // true when the 5,000-file scan cap was reached "scan_limit": number, // 5,000 "scan_warning": string | null, // human-readable warning when truncated, otherwise null "dialect_note": string | null, // non-null when relations are unavailable or the scope has no code files "confidence": "heuristic", "heuristic_warning": string, // what name extraction can and cannot tell you "written": false // always false; save with diagrams_create }

Every cap reports itself in-band, so a truncated or capped result is never silent.

Examples:

  • Use when: "Draft a class diagram for the services layer" -> scope="src/services"

  • Use when: "Give me a Mermaid starter for this module" -> scope="src/models", format="mermaid"

  • Don't use when: You want a hand-written skeleton instead of one read from code (write the source directly, or use diagrams_create)

  • Don't use when: You expect semantic accuracy (member types, generics, or resolved cross-file inheritance); this is a heuristic draft

Error Handling:

  • Returns "Error: Refused to resolve scope outside the project root: ''" when scope is absolute or resolves outside the project root; no file is read

  • A scope with no code files is not an error: entities is empty with a dialect_note explaining why

  • Emitted source always passes the same syntax gate diagrams_create enforces; an emission that cannot is reported as an unexpected internal 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
scopeNoRelative path under the project root pointing at a file or a directory to read (default: '.', the whole project root). Absolute paths and anything that resolves outside the project root are refused..
formatNoOutput dialect for the generated class diagram (default: 'puml').puml
max_entitiesNoHard cap on emitted class/interface declarations, an integer between 1 and 60 (default: 30). The applied cap is reported as entity_limit; anything past it is counted in entities_available and flagged by entities_capped.
include_relationsNoEmit 'A <|-- B' / 'A <|.. B' extends/implements edges when relation evidence is available (default: true). Relations are read from TypeScript heritage clauses only, so a scope without TypeScript-family files emits an empty relations list with a dialect_note.

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 cover readOnly/idempotent/non-destructive, but the description adds substantial beyond them: it never writes ('written: false'), it is a name-extraction heuristic with stated blind spots (members, generics, re-exports), all caps report in-band, and error/refusal behavior is spelled out including out-of-root scope refusal.

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, then evidence, limits, args, returns and errors in a scannable order. It is long and the Args section substantially duplicates the schema, which costs a point, but no sentence is filler.

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?

There is no output schema, yet the description inlines the full JSON return shape with per-field comments, so an agent knows exactly what comes back, including truncation flags and confidence. Error cases and the no-code-files non-error path are also covered.

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%, so the baseline is 3, but the description adds operational meaning: scope refusal semantics, the TypeScript-only source of relations, and the cap/entity_limit reporting relationship. It largely mirrors the schema in the Args section, so it adds context rather than new parameter detail.

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 (generate/draft) and resource (PlantUML/Mermaid class diagram from a codebase slice), and explicitly positions itself against two siblings: diagrams_create (saving) and diagrams_check_consistency (drift detection). An agent can pick it 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 concrete 'Use when' and 'Don't use when' entries with examples, names the sibling alternative (diagrams_create) for hand-written skeletons, and sets expectations against the heuristic limitation. Routing is fully determined.

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