egovframe-scaffold-mcp

공통컴포넌트 재조립 (5.x)

reassemble_egovframe_components

Destructive

Rebuild eGovFrame common components in a project to a pinned catalog version by matching git blob IDs, classifying files, then applying changes with backups and patches.

Instructions

3.x/4.x(또는 이전 5.x) 프로젝트에 복사돼 있는 공통컴포넌트 소스를 카탈로그 고정 버전(현재 v5.0.7)으로 다시 조립합니다. (1) 프로젝트 파일의 git blob id 를 공식 egovframe-common-components 후보 태그(좌표 세대별)와 대조해 원본 태그를 식별하고(파일 내용을 내려받지 않음, sourceTag 로 지정 가능) (2) 원본·현재·목표로 파일마다 목표와 같음/원본 그대로(교체)/사용자 수정/5.x 신규/5.x 에서 제거/원본 미확인/사용자 추가를 판정한 뒤 (3) dryRun=false 면 하나의 transaction 으로 목표 파일을 쓰고(아카이브 sha256 검증), 5.x 에 없는 원본 파일은 백업 후 지우고, 사용자 수정 소스는 교체하되 원본 대비 변경을 unified diff 패치로 보존하며(설정·자산 파일은 사용자본을 유지하고 목표본을 참고로 저장) 매니페스트를 기록해 이후 upgrade·validate·remove 도구가 적용되게 합니다. 백업·패치·reassemble-plan.json 은 migration-backup/<시각>-reassemble-*/ 에 남고, 작업 목록(패치 다시 반영·5.x 제거 파일·설정 비교)을 돌려줍니다. verify=true 면 적용 뒤 compile 을 실행해 오류를 작업 목록 파일에 붙입니다. 원본 태그 비교에 git 이 필요하며 캐시는 EGOVFRAME_CACHE_DIR(기본 ~/.cache/egovframe-scaffold-mcp)에 둡니다. 패치를 자동으로 다시 적용하지는 않습니다.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`dryRun`	No	true(기본)면 분류·계획만, false 면 적용(transaction)
`format`	No	출력 형식	markdown
`verify`	No	적용 뒤 compile 실행해 오류를 작업 목록에 연결
`database`	No	지정 시 컴포넌트별 DDL·DML 을 scripts/egovframe-components/<db>/ 에 함께 생성
`sourceTag`	No	원본 태그(예: v3.10.0). auto(기본)면 파일 대조로 식별	auto
`timeoutMs`	No	verify 컴파일 타임아웃(ms)
`components`	No	재조립할 컴포넌트 id(그룹 id 는 하위 컴포넌트로 펼침). 미지정 시 감지된 컴포넌트 전부
`projectDir`	Yes	대상 프로젝트 디렉터리(절대경로 권장)

Output Schema

TableJSON Schema

Name	Required	Description	Default
`sql`	Yes
`files`	Yes
`notes`	Yes
`dryRun`	Yes
`origin`	Yes
`target`	Yes
`verify`	No
`actions`	Yes
`summary`	Yes
`planPath`	No
`worklist`	Yes
`backupDir`	No
`sourceEra`	Yes
`components`	Yes
`projectDir`	Yes
`manifestUpdated`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.40.0Oct 7, 2026

TDQS

A3.8/5.0

Behavior5/5

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

Annotations only give the coarse profile (destructive, non-idempotent, open-world). The description adds substantially: single-transaction writes, sha256 archive verification, deletion of 5.x-removed originals only after backup, preservation of user edits as unified diff patches, config/asset user-version retention, manifest recording for downstream tools, dryRun default, EGOVFRAME_CACHE_DIR location, a hard git dependency, and the explicit caveat that patches are not auto-reapplied.

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?

Purpose is front-loaded, but the body is a single dense, heavily parenthesized run-on covering three numbered phases plus side effects in one block. Most content is relevant for such a complex tool, yet formatting and sentence length hurt scannability and there is redundancy (backup/patch locations restated).

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, transactional migration tool this is close to complete: it discloses prerequisites (git), side effects (deletes, backups, patches, manifest), artifact locations, the dryRun gate, and future-tool coupling. An output schema exists, so return-value detail is appropriately not duplicated.

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?

Schema coverage is 100%, so the schema is the baseline (3). The description adds meaning beyond the schema: it clarifies sourceTag identifies the original tag without downloading file contents, that verify attaches compile errors to the workflow-list file, and that database triggers DDL/DML generation into scripts/egovframe-components/<db>/. This is useful enrichment rather than pure restatement.

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?

States a specific verb and resource ('공통컴포넌트 소스를 ... 다시 조립합니다') with a clear target ('카탈로그 고정 버전, 현재 v5.0.7') and backward scope (3.x/4.x/이전 5.x). An agent can tell this is a re-assembly/migration of copied component sources, but the description never explicitly distinguishes it from overlapping siblings like upgrade_egovframe_project or migrate_egovframe_project.

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

Usage Guidelines2/5

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

There is no explicit 'when to use this vs an alternative' or exclusion. The only relational hint is downstream ('이후 upgrade·validate·remove 도구가 적용되게 합니다'), which describes consequences rather than when to select this tool. Usage must be inferred from the process narrative.

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