Skip to main content
Glama

Diff Two Diagrams

diagrams_diff
Read-onlyIdempotent

Compare two diagram sources, stored files or inline text, and report added, removed, and renamed entities plus optional message-call order changes for version review.

Instructions

Compare two diagram sources — two stored files, or a stored file against inline text — and report the added, removed, and renamed entity names in structured form.

This is the review-time companion to diagrams_check_consistency: that tool asks whether a diagram still matches the code, this one asks what changed between two versions of the diagram itself. Give it the previous version as a_relative_path or a_content and the new version as the b side, and it lists what a reviewer needs to confirm. It is pure comparison over sources the store already knows how to read: no writes, no network, no filesystem changes.

Each side supplies exactly one of a path or inline content, so unstaged edits can be diffed without a round trip. Rename detection pairs a removed name with an added one only when they are identical once lowercased and stripped of separators, and every rename carries confidence: "heuristic" — similarity is not semantic identity.

Args:

  • compare_call_order (boolean, default false): Also compare recognized message-call names in order, preserving repetitions. Each side is capped at 10000 calls; over-limit comparison is refused. Plain labels, endpoints, arguments and control flow are excluded.

  • a_relative_path (string, optional): Side a as a path relative to the diagrams root

  • a_content (string, optional): Side a as inline source text (dialect detected from the source)

  • b_relative_path (string, optional): Side b as a path relative to the diagrams root

  • b_content (string, optional): Side b as inline source text (dialect detected from the source)

  • Exactly one path or content per side; both or neither is an error naming the side

Returns: JSON with schema: { "a": { "source": string, "type": "plantuml" | "mermaid" }, // path, or "" "b": { "source": string, "type": "plantuml" | "mermaid" }, "added": [{ "name": string }], // declared on b only "removed": [{ "name": string }], // declared on a only "renamed": [ // paired by the shared name normalizer { "from": string, "to": string, "confidence": "heuristic" } ], "unchanged": string[], // declared on both, in a's order "unchanged_count": number, "participants_added": string[], // sequence diagrams only; [] otherwise "participants_removed": string[], "calls_added": string[], "calls_removed": string[], "is_same": boolean, // entity names unchanged, and call order unchanged when comparison is enabled "call_order": { "a": string[], "b": string[], "changed": boolean }, // present only when compare_call_order=true "confidence": "heuristic", "heuristic_warning": string }

A paired rename leaves the added/removed lists, so no change is reported twice. The two sides may use different dialects; each is read with its own syntax.

Examples:

  • Use when: "Did the order or repetition of message calls change?" -> compare_call_order=true with the two diagram sources

  • Use when: "What changed in this diagram since my last edit?" -> a_relative_path="models/order.puml", b_content=""

  • Use when: "Compare the stored diagram against the version in my buffer" -> a_relative_path="system/flow.mmd", b_content=""

  • Don't use when: You want to know whether the diagram still matches the code (use diagrams_check_consistency)

  • Don't use when: You want member-level, layout, or style differences (out of scope; this tool compares declared names only)

Error Handling:

  • CallOrderLimitError rejects enabled comparisons exceeding 10000 recognized calls on either side, without returning partial arrays or source text

  • Returns "Error: Invalid side 'a'|'b': supply exactly one of ..." when a side supplies both or neither of its path and content

  • Returns "Error: Invalid side 'a'|'b' content: not a recognizable ..." when inline content is neither PlantUML nor Mermaid

  • Returns "Error: No diagram found at ''" when a stored side does not exist

  • Returns "Error: Refused to access path outside the diagrams root" when a stored side attempts to escape the diagrams directory

  • Returns "Error: ... does not have a recognized diagram extension" when a stored path's extension is not .puml/.plantuml/.mmd/.mermaid

  • 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
a_contentNoSide a as inline source text (no file read). Exactly one of a_relative_path or a_content must be given; the dialect is detected from the source itself.
b_contentNoSide b as inline source text. Exactly one of b_relative_path or b_content must be given; the dialect is detected from the source itself.
a_relative_pathNoSide a as a stored diagram: path relative to the diagrams root (e.g. 'system/order-flow.puml'). Exactly one of a_relative_path or a_content must be given.
b_relative_pathNoSide b as a stored diagram: path relative to the diagrams root. Exactly one of b_relative_path or b_content must be given.
compare_call_orderNoCompare recognized message-call names in order, including repetitions (default: false). Plain labels, arguments, endpoints and control flow are not compared.

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 declare the safe-read profile, but the description adds substantial context beyond them: the heuristic rename rule and its 'similarity is not semantic identity' caveat, the 10000-call cap and the refusal to return partial arrays, root-escape and extension refusals, and the fact that a paired rename is removed from added/removed so nothing is reported twice. It also explicitly aligns with the annotations ('no writes, no network, no filesystem changes').

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 purpose, then routing, args, returns, examples, errors in a predictable order. The embedding of the full return schema is justified because no output schema exists, but the Args block largely duplicates the input schema and costs a few lines that don't earn their place.

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 5-parameter comparison tool with no output schema and no annotations gap, the description covers inputs, a full response shape, rename/limit edge behavior, and a complete error catalogue including the root-escape guard. An agent has everything needed to call it correctly and interpret failures.

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, and the description earns above that by adding semantics the schema lacks: the exact rename normalization (lowercased, separators stripped), what compare_call_order excludes (labels, endpoints, arguments, control flow), and the per-side cap. It only restates the path/content descriptions verbatim in the Args block, which is the one redundant piece.

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 ('Compare two diagram sources ... report the added, removed, and renamed entity names') and immediately scopes it against the sibling diagrams_check_consistency. An agent can distinguish this from every other diagrams_* tool 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 triggers with concrete invocations (call-order changes, last-edit diff, buffer vs stored) plus two Don't-use-when exclusions that name the alternative tool and the out-of-scope difference classes. 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.