Skip to main content
Glama
EricSeokgon

egovframe-scaffold-mcp

by EricSeokgon

취약 의존성 자동 조치

fix_egovframe_dependencies
Destructive

Fixes eGovFrame Maven pom.xml dependency issues: upgrade parent versions, unpin managed versions, replace changed coordinates, and bump vulnerable versions with dry-run and compile-checked rollback.

Instructions

check_egovframe_dependencies 가 찾기만 하던 의존성 문제를 규칙으로 정할 수 있는 만큼 pom.xml(멀티 모듈 포함)에서 고칩니다. 순서: (1) parent 상향 — 공식 parent 5.x 를 target(기본 권장 버전)으로(migrate_egovframe_project target 의 자동 항목), (2) 고정 해제 — parent(또는 Boot BOM)가 관리하는 좌표에 그보다 낮게 적은 을 지워 parent 에 맡김(major 가 다르면 수동), (3) 좌표 교체 — 좌표만 바뀌고 패키지가 같은 것(mysql-connector-java→mysql-connector-j, ojdbc→ojdbc11, xbean→xmlbeans), (4) 취약 버전 상향 — 직접 적은 버전(리터럴 또는 같은 계열 좌표만 쓰는 버전 속성)이 OSV 에 걸리면 모든 권고를 피하는 가장 낮은 같은 major 정식 릴리스로(저장소 maven-metadata 로 실제 배포 버전 확인, major 가 바뀌거나 수정 버전이 없으면 수동). parent 가 관리하는 버전·전이 의존성의 취약점은 고치지 않고 보고합니다. 결과에 선언 좌표 기준 전·후 취약점 수를 적습니다. 기본 dryRun(계획·변경 미리보기), 적용은 파일 트랜잭션(원본은 migration-backup/<시각>-deps-fix-…/)이며 compile 로 확인해 실패하면 모두 되돌립니다. Gradle 은 리터럴 'g:a:v' 의 고정 해제·취약 버전 상향만. 오프라인 번들(EGOVFRAME_OFFLINE_BUNDLE)이 있으면 OSV 를 번들로 판정합니다.

Input Schema

NameRequiredDescriptionDefault
topNNoMarkdown 에 보일 조치·수동 항목 수
kindsNo적용할 조치(기본 전부: parent·unpin·coordinate·cve-bump)
dryRunNotrue(기본)면 파일을 쓰지 않고 계획만
formatNo응답 형식markdown
targetNoparent 상향 목표 5.x 버전(기본: 권장 버전)
verifyNodryRun=false 일 때 compile 로 확인하고 실패하면 되돌림
offlineNotrue 면 OSV 를 조회하지 않음(취약 버전 상향·전후 집계 생략)
timeoutMsNocompile 제한 시간(기본 600000)
projectDirYes프로젝트 디렉터리(절대경로 권장)

Output Schema

NameRequiredDescriptionDefault
buildNo
filesYes
kindsYes
notesYes
dryRunYes
manualYes
targetYes
actionsYes
summaryYes
osvErrorNo
planPathNo
backupDirNo
projectDirYes
rolledBackNo
buildSystemYes
vulnerabilitiesNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.9.0

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare destructive=true, openWorld=true, and idempotent=false, and the description adds substantial beyond-annotation context: default dryRun behavior, file-transaction application with backups under migration-backup/<timestamp>-deps-fix-…, compile verification with full rollback on failure, and offline bundle behavior. It also discloses what is intentionally not fixed and how vulnerability counts are reported.

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?

The description is front-loaded with the purpose and the contrast against check_egovframe_dependencies, then structured as a numbered remediation sequence. It is dense and long, but the length is justified by the tool's complexity; minor readability loss comes from packing extensive caveats into a single paragraph.

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?

Given the mutation/destructive nature, nine parameters, full schema coverage, and an output schema, the description is complete enough for an agent to invoke the tool correctly. It covers the remediation workflow, backup and rollback semantics, Gradle limits, manual fallbacks, offline behavior, and what the result reports, without needing to explain return values that the output schema already defines.

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 description coverage is 100%, so the schema already documents all nine parameters and the baseline is 3. The description still adds workflow meaning for several parameters: target as the parent upgrade goal, dryRun as plan-only by default, verify as compile-and-rollback, offline as OSV-skipping, and the four kinds as the ordered remediation categories.

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 description states a specific verb and resource: it fixes dependency problems in pom.xml, including multi-module projects, and explicitly contrasts this with check_egovframe_dependencies, which only finds them. An agent can distinguish this tool from the diagnostic sibling 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?

It names the alternative check_egovframe_dependencies and defines the selection condition: use that tool to find issues, this tool to fix them. It also states important exclusions and limitations: parent-managed and transitive vulnerabilities are reported but not fixed, Gradle support is limited to literal g:a:v unpin and cve-bump, and major-version changes or missing fix versions are manual.

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