Skip to main content
Glama

Generate a Sequence Diagram from Code

diagrams_generate_sequence
Read-onlyIdempotent

Draft a PlantUML or Mermaid sequence diagram from codebase call sites, returning source to review before saving; deferred callback calls are counted, not sequenced.

Instructions

Draft a PlantUML or Mermaid sequence diagram from the message-call patterns in a slice of the codebase, returning source text to review and then save with diagrams_create.

Static call-site order is not runtime order. This tool reads call sites in the order a reader meets them and says so in every result: a call inside a callback, promise, or listener is counted in deferred_count and excluded from the messages, because its real position in the conversation is unknowable from source.

It is the generative flip side of the consistency checker's ordered call graph: the same caller-to-callee evidence, turned into a starter diagram instead of a verdict. It never writes: nothing lands in the diagrams directory without an explicit diagrams_create call.

Each sender is the file containing the call site even when another file declares the same caller name. Callee mapping uses case-insensitive declared-identifier equality and the first declaring participant in file order. A callee that no file in the scope declares is reported in unresolved_callees, never attached to an invented participant. Which class owns a method is a type question, and out of scope.

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_participants (integer 1-20, default 8): Hard cap on declared participants

  • max_messages (integer 1-50, default 20): Hard cap on emitted messages

  • include_call_parentheses (boolean, default false): When true, emitted message labels append '()' in both dialects; structured messages.message values stay bare

Returns: JSON with schema: { "scope": string, // POSIX path as resolved, "." for the project root "format": "puml" | "mermaid", "source": string, // the generated sequence; identical to the text block (message labels carry '()' when include_call_parentheses is true) "participants": string[], // participant names as emitted, in first-conversation order, capped "participants_included": number, // length of "participants" "participants_available": number,// distinct participants in candidate messages, may exceed the cap "participants_capped": boolean, // true when participants were dropped by the cap "participant_limit": number, // the applied cap (max_participants, at most 20) "messages": [ // ordered call sites, one per sequenced call (message stays bare when include_call_parentheses is true) { "from": string, "to": string, "message": string, "line": number, "via_callback": false } ], "messages_included": number, "messages_available": number, // candidate messages, may exceed the cap "messages_capped": boolean, // true when messages were dropped by either cap "message_limit": number, // the applied cap (max_messages, at most 50) "deferred_count": number, // call sites inside callbacks/promises: counted, never sequenced "unresolved_callees": string[], // callees no participant in the scope declares "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 "confidence": "heuristic", "heuristic_warning": string, // what static call order 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: "Show the call flow between the checkout and payment modules" -> scope="src/checkout"

  • Use when: "Draft a Mermaid sequence for this service layer" -> scope="src/services", format="mermaid"

  • Don't use when: You need runtime ordering, async semantics, or which class a method belongs to (out of scope; deferred and unresolved calls are reported instead)

  • Don't use when: You want a class diagram (use diagrams_generate) or a hand-written skeleton (write the source directly)

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: participants and messages are empty, and the emitted source is a valid empty diagram

  • 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 sequence diagram (default: 'puml').puml
max_messagesNoHard cap on emitted messages, an integer between 1 and 50 (default: 20). The applied cap is reported as message_limit; messages past it, or to a participant the participant cap removed, are counted in messages_available and flagged by messages_capped.
max_participantsNoHard cap on declared participants, an integer between 1 and 20 (default: 8). The applied cap is reported as participant_limit; anything past it is counted in participants_available and flagged by participants_capped.
include_call_parenthesesNoWhen true, emitted message labels append '()' in both dialects (default: false). Structured messages.message values stay bare.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.10.0

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description is free to add what they cannot: it never writes, static call order is not runtime order, deferred callback calls are counted but never sequenced, undeclared callees go to unresolved_callees rather than an invented participant, every cap reports itself in-band, and a 5,000-file scan cap exists. Error behavior (scope refusal, empty-scope non-error, syntax gate) is disclosed in detail.

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, scope constraint, and hand-off are front-loaded in the first three sentences, and the Returns/Error Handling sections genuinely earn their space because there is no output schema. The Args block, however, duplicates schema descriptions that are already at 100% coverage, which is the only real padding.

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?

For a no-output-schema tool with five parameters and a complex heuristic result, the description supplies the full return shape (participants/messages caps, deferred_count, unresolved_callees, confidence, written), worked examples, and error semantics. Nothing an agent needs to invoke or interpret it is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and the schema already documents defaults, ranges, and the meaning of include_call_parentheses' bare structured messages. The description's Args block largely restates those entries verbatim, so it adds only cross-references to the return fields (message_limit, participants_capped) rather than new parameter meaning. Baseline 3 is correct when the schema does the heavy lifting.

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 — 'Draft a PlantUML or Mermaid sequence diagram from the message-call patterns in a slice of the codebase' — and immediately names the sibling it hands off to (diagrams_create) and the sibling it contrasts with (diagrams_generate, class diagrams). An agent can distinguish it from the other 14 diagrams_* tools without opening a 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' / 'Don't use when' blocks with worked examples (scope="src/checkout", format="mermaid"), names the alternative for class diagrams, and states the exclusion for runtime ordering, async semantics, and class ownership. Routing is unambiguous.

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