Skip to main content
Glama
Sign In
dave1362

UML Forge

by dave1362
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

umlforge_reverse_engineer

Read-only

Analyze an existing codebase or GitHub repo to generate UML class, sequence, and state diagrams and flag architectural issues for audits.

Instructions

Analyse an existing codebase and produce UML class, sequence, and state diagrams.

USE THIS WHEN:

  • You have a GitHub URL and want to understand what the code does

  • You want to audit a codebase for architectural problems

  • You need diagrams of code that already exists (your own or a public repo)

  • You want an Architectural Intelligence Report on any codebase

NOT FOR:

  • Designing a new system from scratch → use umlforge_stakeholder_arch

  • Updating diagrams after a sprint → use umlforge_living_docs

  • Documenting database schema → use umlforge_erd_schema

  • Mapping how services call each other → use umlforge_api_sequence

Produces:

  • Class diagram: entities, attributes, relationships, multiplicities

  • Sequence diagram: primary execution flow or dominant use case

  • State diagram: entity lifecycle (if stateful entities are detected)

  • Architectural smell flags: god classes, circular deps, anemic models

  • (report_mode=True) Architectural Intelligence Report: system overview, key findings, modernisation roadmap, health scores (A–F)

Provide EITHER github_url OR codebase — not both.

Args: github_url: Public GitHub URL. Accepted formats: github.com/owner/repo github.com/owner/repo/tree/branch/path/to/dir github.com/owner/repo/blob/branch/path/to/file.py codebase: Paste code directly when you have files in context or the repo is private. max_nodes: Max classes/components per diagram (default 20, range 5–50). github_token: GitHub personal access token (repo scope) — only needed for private repositories. Never stored or logged. report_mode: True → also produce an Architectural Intelligence Report. Pro/Team/Enterprise only. Omit to use your saved account preference (dashboard toggle); False forces diagrams only.

Input Schema

NameRequiredDescriptionDefault
codebaseNo
max_nodesNo
github_urlNo
report_modeNo
github_tokenNo

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv0.3.0
    • addedInput schema / properties / report_mode / anyOf
      Added value: +[
+  {
+    "type": "boolean"
+  },
+  {
+    "type": "null"
+  }
+]
    • changedInput schema / properties / report_mode / default
      Previous value: -falseNew value: +null
    • removedInput schema / properties / report_mode / type
      Removed value: -"boolean"
  2. Changed1 schema field changedv0.2.2
    • addedInput schema / properties / github_token
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Github Token"
+}
  3. First observedv0.1.9

TDQS

A4.7/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false, openWorldHint=true, so the safety profile is covered. The description adds genuinely useful context beyond them: github_token is never stored or logged, report_mode is gated to Pro/Team/Enterprise and falls back to a saved dashboard preference, and github_url/codebase are mutually exclusive. It does not address the non-idempotent hint or cost/latency of scanning a large repo, so it stops short of 5.

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 with the core action, then cleanly sectioned into USE THIS WHEN / NOT FOR / Produces / Args. Every block earns its place, though the per-diagram 'Produces' enumeration partly restates what the output schema already conveys, making it marginally longer than necessary.

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?

A high-complexity, five-parameter tool with 0% schema coverage is fully covered here: purpose, exclusions, parameter formats and defaults, auth/tier constraints, and mode-dependent output. With an output schema present, no return-value detail is owed, and nothing an agent needs to call it correctly is missing.

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?

Schema description coverage is 0%, so the description must carry the full burden - and it does: three accepted github_url URL formats (repo, tree/branch/dir, blob/branch/file), when to use codebase instead (private repo or files in context), max_nodes default 20 and range 5-50, github_token scope (repo), and report_mode's three-state semantics including omission behavior.

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 (analyse/reverse-engineer) and resource (existing codebase) plus the concrete deliverables (class, sequence, state diagrams, smell flags, intelligence report). The NOT FOR section names four sibling tools, so an agent can distinguish it from umlforge_stakeholder_arch, umlforge_living_docs, umlforge_erd_schema, and umlforge_api_sequence 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?

Explicit USE THIS WHEN list (GitHub URL, audit, need diagrams of existing code) and a NOT FOR list that routes to four named alternatives, each with the condition that selects it. Nothing about when-to-use 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.

Deploy Server

Other Tools