UML Forge

Overview Schema Source Related Servers Discussions Admin

umlforge_legacy_migration

Read-only

Visualise legacy COBOL, Fortran, or ABAP code and generate a 6-phase migration roadmap to modern languages, with structure diagrams and complexity risk flags.

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.

Input Schema

TableJSON Schema

Name	Required	Default
`github_url`	No
`legacy_code`	No
`report_mode`	No
`github_token`	No
`system_purpose`	No
`source_language`	No	COBOL
`target_language`	No	Python

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv0.2.2Sep 11, 2026

addedInput schema / properties / github_token

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Github Token"
+}

Addedv0.2.1Sep 4, 2026

TDQS

A5/5.0

Behavior5/5

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

Annotations already cover readOnly/openWorld/idempotent/destructive, and the description adds meaningful context beyond them: report_mode is gated to Pro/Team/Enterprise, github_token is 'never stored or logged', and inputs are mutually exclusive ('Provide EITHER github_url OR legacy_code — not both'). It also enumerates the concrete artifacts produced (diagrams, 6-phase roadmap, risk flags), which is the kind of behavioral disclosure an agent needs.

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?

Despite its length, the description is front-loaded with a one-sentence purpose and then cleanly sectioned (USE THIS WHEN / NOT FOR / Produces / Args). Every bullet earns its place by disambiguating scope, output, or parameters; there is no filler prose.

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, multi-artifact tool, the definition is complete: inputs, mutual-exclusivity constraint, deliverable list, tier gating, and auth handling are all present. Since an output schema exists, return values needn't be re-explained, and the description's output summary is a useful complement rather than redundant padding.

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 it does. Every one of the 7 parameters is documented: accepted github_url URL formats, the full supported list for source_language and target_language (with defaults), system_purpose's effect on labels/advice, github_token's scope requirement, and report_mode's semantics and tier restriction.

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 opening sentence states a specific verb+resource: 'Visualise a legacy codebase and produce a migration roadmap to a modern language.' The NOT FOR section explicitly differentiates from siblings by name (umlforge_reverse_engineer for modern code, umlforge_erd_schema for DB schema), so an agent can select this tool without opening any 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?

The 'USE THIS WHEN' block enumerates concrete triggers (specific legacy languages, pre-migration structural understanding, modernisation pitching) and the 'NOT FOR' block names the alternative tools to route to instead. This is exactly the when/when-not/alternatives pattern, with nothing 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