Skip to main content
Glama

Generate a Sequence Diagram from Code

diagrams_generate_sequence
Read-onlyIdempotent

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.

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.

ambiguous_callees lists bare names from emitted messages whose case-insensitive declaration occurs in several distinct participants after same-basename merging. Exact spellings are deduplicated in first emitted order after both caps. Deferred and unresolved calls and calls dropped by caps do not contribute. Competing declarations anywhere in the scanned scope count even when their participant is not emitted. The existing first-declaring-participant choice remains unchanged.

callee_evidence carries one entry per distinct emitted message spelling, in first emitted order after both caps, explaining how that choice was made: candidate_participants lists the distinct logical participants declaring the callee case-insensitively, in registry order after same-basename merging and before the participant cap, cut at candidate_limit (20) with the exact count in candidates_available and candidates_capped flagging the cut. selected_participant is the existing first match, every emitted spelling gets an entry even when only one participant declares it, and deferred, unresolved, and capped calls contribute none. Entry names are logical file basenames, never the sanitized identifiers Mermaid renames participants to. This is static declaration evidence only: it never claims which receiver runs at runtime.

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 "ambiguous_callees": string[], // emitted bare names with multiple declaring participants; exact spelling and first emitted order "callee_evidence": [ // one entry per distinct emitted message spelling, first emitted order after both caps { "callee": string, "selected_participant": string, "candidate_participants": string[], "candidates_available": number, "candidates_capped": boolean, "candidate_limit": number, "resolution_basis": "case-insensitive-declaration" } ], "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

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 readOnly/idempotent/non-destructive, and the description still adds substantive behavior: nothing is written without an explicit diagrams_create call, deferred callback/promise call sites are counted but never sequenced, unresolved callees are reported rather than invented, caps report themselves in-band, the 5,000-file scan cap flags truncation, and scope escapes the project root are refused. Error-handling semantics (empty scope is not an error, syntax gate parity with diagrams_create) go well beyond the annotation profile.

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 and the write-safety constraint are front-loaded, and length is partly justified because there is no output schema and the return contract must be explained inline. However, the middle paragraphs on ambiguous_callees and callee_evidence are dense and repeat the phrase 'after both caps' and 'first emitted order' multiple times, costing readability.

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?

No output schema exists, and the description fully compensates: it enumerates the return fields and their invariants (cap reporting, deferred_count, unresolved_callees, truncated/scan_warning, written:false, confidence heuristic). Combined with the error handling and explicit exclusions, an agent has everything needed to call it and interpret the result.

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%, so each parameter is already documented in the schema; the description largely restates scope/format/cap semantics rather than adding new meaning. The one useful addition is the linkage between caps and the in-band messages_capped/participants_capped reporting, plus the note that structured messages.message stays bare under include_call_parentheses. Baseline 3 is appropriate.

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 (draft), specific resource (PlantUML/Mermaid sequence diagram) and its derivation source (message-call patterns in a codebase slice), plus where the output goes (review, then diagrams_create). It also explicitly positions itself against siblings: the 'generative flip side' of the consistency checker and distinct from diagrams_generate (class diagrams).

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 two concrete 'Use when' examples with parameter values and two 'Don't use when' clauses naming the correct alternatives (diagrams_generate for class diagrams, write the source directly for a hand-written skeleton) and calling out runtime ordering/async semantics as out of scope. Nothing is left to inference.

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