Skip to main content
Glama
dave1362

UML Forge

by dave1362
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

umlforge_legacy_migration

Read-only

Visualise legacy code structure and generate a migration roadmap to modern languages like Python or Go. Produces diagrams, risk flags, and a phased plan.

Instructions

Visualise a legacy codebase and produce a migration roadmap to a modern language.

USE THIS WHEN:

  • You have COBOL, Fortran, ABAP, RPG, PL/I, Pascal, BASIC, Assembly, Ada, or ALGOL code

  • You want to understand the structure of a legacy program before migrating it

  • You need diagrams showing what the system does NOW and what it would look like rebuilt in Python, Go, Rust, Java, TypeScript, C#, or Kotlin

  • You are planning or pitching a modernisation project and need a migration roadmap

NOT FOR:

  • Analysing modern codebases → use umlforge_reverse_engineer

  • Generating translated source code (Option B — future feature)

  • Database schema design → use umlforge_erd_schema

Produces:

  • Legacy structure diagram: program divisions, sections, modules, data stores, file I/O, external interfaces (as the system exists today)

  • Modern equivalent diagram: proposed clean-architecture rebuild in the target language with idiomatic layer names and structure

  • Migration roadmap: 6-phase plan (Understand → Extract → Data → Logic → Test Parity → Cutover) with duration estimates and exit criteria

  • Complexity & risk flags: global state, file I/O coupling, implicit typing, unstructured control flow, vendor extensions, interface contracts

  • (report_mode=True) Legacy Migration Assessment: complexity scores, recommended strategy, tooling recommendations, risk assessment (A–F per dimension)

Provide EITHER github_url OR legacy_code — not both.

Args: legacy_code: Paste the legacy source code directly. github_url: Public GitHub URL containing legacy source files. Accepted formats: github.com/owner/repo, github.com/owner/repo/tree/branch/path, github.com/owner/repo/blob/branch/file.cbl source_language: Language of the legacy code (default: COBOL). Supported: COBOL, Fortran, ABAP, RPG, PL/I, Pascal, BASIC, Assembly, Ada, ALGOL. target_language: Modern language to migrate toward (default: Python). Supported: Python, Go, Rust, Java, TypeScript, C#, Kotlin. system_purpose: Brief description of what the program does in production (e.g. "monthly payroll batch", "order entry OLTP"). Optional but improves diagram labels and migration advice. github_token: GitHub personal access token (repo scope) — only needed for private repositories. Never stored or logged. report_mode: True → also produce a Legacy Migration Assessment with complexity scores and tooling recommendations. Pro/Team/Enterprise only. Omit to use your saved account preference (dashboard toggle); False forces diagrams only.

Input Schema

NameRequiredDescriptionDefault
github_urlNo
legacy_codeNo
report_modeNo
github_tokenNo
system_purposeNo
source_languageNoCOBOL
target_languageNoPython

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. Addedv0.2.1

TDQS

A4.9/5.0
Behavior5/5

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

Annotations cover the safety profile (readOnlyHint, destructiveHint=false), and the description adds genuinely non-obvious behavior: report_mode is gated to Pro/Team/Enterprise, github_token is only needed for private repos and is never stored or logged, and exactly one of github_url/legacy_code must be supplied. The tier restriction and credential-handling disclosure are the kind of context annotations cannot express.

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 one-line summary followed by clearly labeled USE THIS WHEN / NOT FOR / Produces / Args sections. It is long, and the 'Produces' list partially duplicates the output schema, but the structure is scannable and nothing is filler.

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 7-parameter, zero-required tool with an output schema, the description supplies the missing pieces an agent needs: mutually exclusive input rule, credential scope, tier gating, and default language pair. Nothing required to invoke it correctly is absent.

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: every argument is explained with defaults, supported values, the accepted GitHub URL formats, and the either/or exclusivity rule for github_url vs legacy_code. This fully compensates for the empty 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?

States a concrete verb+resource ('Visualise a legacy codebase and produce a migration roadmap') and immediately distinguishes itself from siblings by naming umlforge_reverse_engineer and umlforge_erd_schema as the wrong tools for adjacent tasks. An agent can route to it without opening the 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 enumerates the source languages and intents, and the 'NOT FOR' block names each alternative tool and the condition that selects it. The only unimplemented case (source-code generation) is flagged as a future feature rather than left ambiguous.

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