Skip to main content
Glama

Check Diagram-to-Code Consistency

diagrams_check_consistency
Read-onlyIdempotent

Check a PlantUML or Mermaid diagram against your codebase to find class or component names that no longer exist, revealing outdated architecture docs.

Instructions

Compare class/interface/component names mentioned in a PlantUML or Mermaid diagram against identifiers that actually exist in the codebase, to catch documentation drift.

This is a heuristic, text-based check (not a full semantic/AST analysis): it extracts entity names from class/interface/enum/component declarations in the diagram, then searches source files under the project root for a matching identifier as a whole word. It flags names that appear in the diagram but were not found anywhere in the scanned code — a signal the diagram may be outdated, or the code was renamed/removed/not yet built.

This tool does NOT modify the diagram or the code. It only reports findings; the caller (agent or human) decides what to do about them.

Args:

  • relative_path (string): Path to the diagram to check, relative to the diagrams root

Returns: JSON with schema: { "diagram_path": string, "entities_found": number, // total entity names extracted from the diagram "entities_matched": number, // how many were found somewhere in the code "entities_unmatched": number, // how many were NOT found (potential drift) "files_scanned": number, // how many source files were searched "searched_directory": string, // absolute path of the code root that was scanned "truncated": boolean, // true when the 5,000-file scan cap was reached; unmatched results may be incomplete "scan_limit": number, // maximum source files collected during the scan "scan_warning": string | null, // human-readable warning when truncated, otherwise null "entities": string[], // extracted entity names, in extraction order "matched_entities": string[], // extracted entities found in the code "unmatched_entities": string[],// extracted entities NOT found (potential drift) "analyzers": { // scanned file extensions per analyzer tier "reliable": string[], // per-language declaration patterns (JS/TS, Python, PHP, Java) "experimental": string[], // generic heuristic path (C#, Go, Ruby, Kotlin, Rust) "generic": string[] // other scanned extensions, heuristic path only }, "confidence": "heuristic", // results are evidence, never a definitive verdict "heuristic_warning": string, // human-readable limits of the heuristic "evidence": [ // per-entity evidence, same order as "entities" { "name": string, "matched": boolean, "analyzers": ("reliable" | "experimental" | "generic")[], "matched_files": string[], // POSIX paths relative to searched_directory (capped) "matched_file_count": number } ], "issues": [ { "name": string, // the unmatched entity name "issue": string, // human-readable explanation "severity": "warning" | "info" } ] }

Examples:

  • Use when: "Is this class diagram still accurate compared to the code?" -> relative_path="models/user-class.puml"

  • Use when: Reviewing a PR that touches architecture, to check the UML docs weren't left behind

  • Don't use when: The diagram has no class/interface/component declarations (e.g. a pure sequence diagram) — entities_found will be 0, which is expected, not an error

Error Handling:

  • Returns "Error: No diagram found at ''" if the diagram file doesn't exist

  • An empty "issues" array with entities_found=0 means no checkable entities were found in the diagram, not that everything matched

  • 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
relative_pathYesPath to the diagram to check, relative to the diagrams root.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. First observedv0.1.0

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false; the description reinforces this by stating 'This tool does NOT modify the diagram or the code.' Beyond that, it discloses the heuristic, text-based nature, the 5,000-file scan cap, truncation behavior, confidence level, and the distinction between reliable/experimental/generic analyzers. This exceeds what annotations alone convey.

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?

The description is lengthy, but it is well-structured with clear sections (overview, args, returns, examples, error handling) and front-loads the purpose and key non-modifying constraint. Every section adds value, though the inline return schema is verbose. Slightly overlong but organized enough to earn a 4.

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?

The description is exceptionally complete for a heuristic check tool: it covers the return schema in detail, error handling, edge cases (entities_found=0, truncation), and the confidence level. Despite having no output schema annotation, the description fully specifies the expected JSON structure and all relevant failure modes, leaving no ambiguity for an agent.

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 coverage is 100% and the only parameter (relative_path) is already described as 'Path to the diagram to check, relative to the diagrams root.' The description adds example paths and clarifies the root relative interpretation, but these are marginal additions beyond the schema. The baseline of 3 applies since the schema carries the semantic load.

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?

The description clearly states the tool compares entity names in diagrams against code identifiers to catch documentation drift. It names the specific resource (PlantUML/Mermaid diagrams vs codebase) and distinguishes itself from sibling tools like diagrams_get or diagrams_render by focusing on consistency checking, not creation, retrieval, or rendering.

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 when-to-use scenarios ('Is this class diagram still accurate?', PR review) and a concrete don't-use condition (pure sequence diagram with no declarations, where entities_found=0 is expected). Also clarifies that an empty issues array with entities_found=0 means no checkable entities, not a pass, preventing misinterpretation.

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

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/mohammad-emad-dev/diagrams-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server