Skip to main content
Glama

umlforge_living_docs

Read-only

Update existing Mermaid diagrams with sprint or PR changes, adding changelog headers and architecture evolution notes.

Instructions

Update diagrams you already have to reflect what changed in a sprint or PR.

USE THIS WHEN:

  • You ALREADY HAVE Mermaid diagrams (from a previous generation or your own)

  • Code has changed in a sprint or PR and your diagrams are now out of date

  • You want a changelog-annotated diff of your diagrams

NOT FOR:

  • Generating diagrams for the first time → use umlforge_reverse_engineer (for existing codebases) or umlforge_stakeholder_arch (for new designs)

  • Analysing a GitHub URL → use umlforge_reverse_engineer instead

  • Generating diagrams without existing ones to update → use any other tool

IMPORTANT: current_diagrams is REQUIRED — paste your existing Mermaid diagrams (including the ```mermaid fences). This tool cannot generate from scratch.

Produces:

  • Updated diagrams for affected sections only (with %% changelog headers)

  • New diagrams for newly introduced patterns

  • Architecture evolution note for pasting into a wiki

  • (report_mode=True) Documentation Analysis Notes: change impact, drift risks, coverage quick wins

Args: current_diagrams: Your existing Mermaid diagram(s) — paste the full content including ```mermaid fences. REQUIRED. sprint_changes: What changed this sprint: new components, removed flows, renamed services, modified behaviour. affected_files: Files or modules touched in this sprint/PR (optional). report_mode: True → also produce Documentation Analysis Notes. Pro/Team/Enterprise only.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
report_modeNo
affected_filesNo
sprint_changesYes
current_diagramsYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes
Behavior4/5

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

Annotations (readOnlyHint=true, openWorldHint=true) are complemented by description stating it requires existing diagrams and produces updated output. Adds context on report_mode limitations (Pro/Team/Enterprise only) and format of output (%% changelog headers). No contradictions observed.

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?

Well-structured with labeled sections and front-loaded purpose. Every sentence adds value, though slightly verbose with repeated emphasis on NOT FOR cases. Still efficient for the amount of information conveyed.

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?

Covers all aspects: purpose, when to use/not use, prerequisites, parameter details, output description, and licensing note. Given the tool's complexity (4 params, 2 required) and presence of output schema, the description leaves no critical gaps.

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

Parameters5/5

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

Despite 0% schema description coverage, the description explains each parameter in detail: current_diagrams required with format and fencing, sprint_changes as changes summary, affected_files as optional, report_mode effect and licensing. This fully compensates for lack of schema descriptions.

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?

Clearly states verb+resource: 'Update diagrams you already have' with specific scope (sprint/PR changes). Distinguishes from siblings by explicitly listing what it is NOT for and suggesting alternative tools (umlforge_reverse_engineer, umlforge_stakeholder_arch).

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 THIS WHEN' and 'NOT FOR' sections with concrete conditions (e.g., already have Mermaid diagrams, code changed in sprint/PR). Also gives specific alternatives for non-use cases, making guidance actionable.

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

Install Server

Other Tools

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/dave1362/umlforge-connector'

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