Skip to main content
Glama
dave1362

UML Forge

by dave1362
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

umlforge_reverse_engineer

Read-only

Reverse engineer existing code or a GitHub repo into UML class, sequence, and state diagrams, with optional architectural report and smell flags.

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
codebaseNo
max_nodesNo
github_urlNo
report_modeNo
github_tokenNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.2.2
    • addedInput schema / properties / github_token
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Github Token"
+}
  2. First observedv0.1.9

TDQS

A5/5.0
Behavior5/5

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

Annotations already declare readOnlyHint, destructiveHint=false, and openWorldHint, so the safety profile is covered. The description adds genuinely non-structured context: the github_token requires repo scope and is 'never stored or logged', report_mode is gated to Pro/Team/Enterprise, and the exact artifact set produced (including optional state diagram and A–F health scores) is spelled out.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Well front-loaded with headed sections (USE THIS WHEN / NOT FOR / Produces / Args) so an agent can scan to the relevant part. Long but every block earns its place; the only blemish is mojibake in the em-dashes and ranges ('A?F', '5?50'), which does not obscure meaning.

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?

Despite an output schema existing, the description still fully describes the deliverable set, so an agent understands both invocation and result. Combined with the parameter detail and sibling routing, nothing an agent needs to call this 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 carries the full burden and does so thoroughly: accepted github_url formats, the intended use of codebase for pasted/private code, max_nodes default 20 with range 5–50, token scope, and report_mode semantics. It also states the mutual-exclusion rule ('Provide EITHER github_url OR codebase — not both') that appears nowhere in the schema.

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+resource ('Analyse an existing codebase and produce UML class, sequence, and state diagrams') and immediately enumerates the concrete outputs. It distinguishes itself from every relevant sibling by naming umlforge_stakeholder_arch, umlforge_living_docs, umlforge_erd_schema, and umlforge_api_sequence as the tools to use instead for adjacent jobs.

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?

The description contains explicit USE THIS WHEN and NOT FOR sections, with each exclusion routed to a named alternative tool and the selecting condition. An agent can decide between this and all four adjacent siblings without opening another schema.

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