egovframe-scaffold-mcp

5.x 전환 진단·적용

migrate_egovframe_project

Destructive

Diagnose eGovFrame 3.x/4.x projects for 5.x upgrade (Jakarta EE 9+, Spring 6, Java 17) at file/line level, then optionally apply safe auto-replacements with backups.

Instructions

표준프레임워크 3.x/4.x 프로젝트를 5.x(Jakarta EE 9+, Spring 6, Java 17) 로 옮기기 위해 바꿔야 할 것을 파일·라인 단위로 진단하고(1단계), apply=true 이면 auto 항목을 실제로 치환합니다(2단계). 진단: RTE Maven 좌표(egovframework.rte → org.egovframe.rte:egovframe-rte-)·패키지(egovframework.rte. → org.egovframe.rte.)·5.x 에서 이름이 바뀌거나 제거된 클래스·javax→jakarta 패키지와 의존성·web.xml 스키마·제거된 egov- XML 네임스페이스·교체 필요 라이브러리, 항목마다 auto(기계 치환 가능)/manual(코드 수정 필요). 적용: apply=true 는 dryRun=true(기본)면 파일별 변경 미리보기만 돌려주고, dryRun=false 면 auto 항목을 하나의 transaction 으로 치환하며 원본을 migration-backup/<시각>/ 에 보관하고 migration-plan.json 을 남깁니다(중간 실패 시 작업 전 상태로 복구). manual 항목은 건드리지 않고 결과에 남깁니다. verify=true 는 3단계(검증): 적용 뒤 compile 을 실행해 컴파일 오류를 수동 항목과 연결하고 "이 항목을 처리하면 해결될 오류 수" 순으로 작업 목록을 만듭니다. 3.x 공통컴포넌트 소스가 섞여 있으면 컴포넌트 단위 재조립 권고를 내고 skipComponents 로 치환에서 뺄 수 있습니다. 규칙은 egovframe-runtime·egovframe-common-components 태그 비교로 만든 동봉 카탈로그(catalog/migration-rules.json)에서 읽습니다.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`apply`	No	true 면 2단계(적용). false(기본)면 진단만
`dryRun`	No	apply=true 일 때만 의미. true(기본)면 파일별 변경 미리보기만, false 면 실제로 치환(백업 생성)
`format`	No	출력 형식. markdown=사람이 읽는 요약, json=항목 배열 그대로	markdown
`target`	No	전환 목표 (현재 5.x 만 지원)	5.x
`verify`	No	true 면 3단계(검증): 진단 후 compile 을 실행해 컴파일 오류를 수동 항목과 연결한 작업 목록을 반환(apply 와 함께 쓰지 않음, 빌드 도구 필요)
`projectDir`	Yes	대상 프로젝트 디렉터리(절대경로 권장)
`skipComponents`	No	true 면 3.x 공통컴포넌트 디렉터리(재조립 권고 대상)의 자동 항목을 치환하지 않고 수동으로 남김

Output Schema

TableJSON Schema

Name	Required	Description	Default
`mode`	No
`build`	No
`files`	No
`items`	Yes
`links`	No
`notes`	Yes
`rules`	Yes
`dryRun`	No
`target`	Yes
`applied`	No
`summary`	Yes
`planPath`	No
`unlinked`	No
`worklist`	No
`backupDir`	No
`conflicts`	No
`remaining`	No
`sourceEra`	Yes
`projectDir`	Yes
`rteVersion`	Yes
`buildSystem`	Yes
`filesScanned`	Yes
`skippedManual`	No

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.36.1Oct 4, 2026

TDQS

A4.2/5.0

Behavior5/5

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

Goes well beyond the annotations by disclosing the safety mechanics: dryRun defaults to preview, actual replacement runs in a single transaction, originals are archived to migration-backup/<time>/, a migration-plan.json is written, and a mid-run failure rolls back to the pre-operation state. It also notes manual items are left untouched and that rules come from a bundled catalog, which annotations alone cannot convey.

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

Conciseness3/5

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

The content is dense and largely earns its place, but it is delivered as one long run-on paragraph with stacked parentheticals and no structural breaks, making it hard to scan for the apply/dryRun/verify distinctions that matter most.

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 destructive, multi-phase migration tool with 7 parameters and an output schema, the description covers the full lifecycle (diagnose → apply → verify), the backup/rollback guarantee, the rule-catalog source, and the build-tool prerequisite for verification. Nothing essential to invoking it correctly appears to be missing.

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

Parameters4/5

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

With 100% schema description coverage the schema already documents each parameter, so the baseline is 3; the description earns extra credit by explaining cross-parameter interactions (apply+dryRun staging, verify mutually exclusive with apply, skipComponents excluding component dirs) that the flat schema fields do not express.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Names a specific verb (migrate) with the exact source/target versions (3.x/4.x → 5.x, Jakarta EE 9+, Spring 6, Java 17) and enumerates the concrete artifacts it rewrites (Maven coordinates, packages, javax→jakarta, web.xml schema, XML namespaces). However, it never distinguishes itself from close siblings like upgrade_egovframe_project or diagnose_egovframe_project, which an agent could easily confuse with this one.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives clear mode-selection guidance tied to flags: apply=true triggers stage 2, dryRun=true (default) only previews, verify=true runs stage 3, and verify is explicitly stated as not used together with apply. This is strong internal routing, but it offers no guidance on when to pick this tool over the sibling upgrade_/diagnose_ tools.

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