Skip to main content
Glama
egovframe-scaffold-mcp

egovframe-scaffold-mcp

by EricSeokgon

설정·비밀값 외부화

externalize_egovframe_config
Destructive

Externalizes database passwords and secrets from eGovFrame configuration files into environment variables or external crypto files, with dry-run planning, backup, and optional startup verification.

Instructions

설정 파일(globals.properties·application.properties/yml·context-.xml)의 DB 비밀번호·비밀 값을 저장소 밖으로 옮깁니다. 판정은 check_egovframe_secure_coding 의 hardcoded-config-password 규칙과 화이트리스트(.egovframe-secure-ignore.json)를 그대로 써서 두 도구의 결과가 같습니다(XML 의 은 주석을 뺀 채 추가로 찾음). 키를 읽는 방식에 따라 — Spring 자리표시자·Boot Environment 로 읽는 키는 값을 지우고 ${EGOV_…_PASSWORD} 자리표시자로(env), 표준프레임워크 암호화 값(Globals..Password)은 그대로 두고 복호화 키가 든 egov-crypto-config.properties 의 algorithmKey·algorithmKeyHash 를 지운 뒤 globals.properties 에 Globals.CryptoConfigPath=${EGOV_CRYPTO_CONFIG:} 를 넣어 외부 파일에서 읽게 하며(crypto-path, runtime 5.x), deploy/secrets/egov-crypto-config.properties.example 을 만듭니다. EgovProperties.getProperty("…") 처럼 파일을 직접 읽는 키(Globals.File.algorithmKey 등)와 4.x context-crypto.xml 의 키는 자리표시자가 풀리지 않으므로 사유와 함께 수동 항목으로 냅니다. generate_egovframe_deploy 산출물(deploy/.env.example·docker-compose.yml·k8s Secret)이 있으면 환경 변수 자리를 추가합니다. 기본 dryRun(바뀔 줄은 가린 값으로), 적용은 파일 트랜잭션(원본은 migration-backup/ — 비밀 값이 들어 있으니 저장소에 넣지 마세요)이고 적용 뒤 보안약점 규칙 전·후 수를 보고합니다. verify=true 면 원래 값을 환경 변수로 주고 verify_egovframe_startup 으로 띄워 설정 해석에 실패하면(config-missing) 되돌립니다. 결과·로그에 원래 값은 적지 않습니다.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "projectDir": "<projectDir>"
    },
    "name": "externalize_egovframe_config"
  }
}

Input Schema

NameRequiredDescriptionDefault
modeNoauto(기본): 읽는 방식대로 env·crypto-path | env: 자리표시자 교체만 | crypto: 암호화 키 파일 외부화만auto
pathsNo프로젝트 상대 경로 접두어로 좁히기
dryRunNotrue(기본)면 파일을 쓰지 않고 계획만
formatNo응답 형식markdown
verifyNo적용 뒤 원래 값을 환경 변수로 주고 기동 검증 — 설정 해석 실패(config-missing)면 되돌림
timeoutMsNo기동 검증 제한(ms)
projectDirYes프로젝트 디렉터리(절대경로 권장)
tomcatHomeNo기동 검증에 쓸 설치된 Tomcat(기본: 캐시)

Output Schema

NameRequiredDescriptionDefault
envYes
modeYes
filesYes
notesYes
dryRunYes
manualYes
verifyNo
runtimeYes
summaryYes
findingsYes
planPathNo
backupDirNo
generatedYes
projectDirYes
rolledBackNo
secureCodingYes
deployUpdatedYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.15.0

TDQS

A4.5/5.0
Behavior5/5

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

The annotations say this mutates and destroys data, and the description adds substantive context: changes are applied as a file transaction, originals go to migration-backup/ with an explicit warning not to commit them, and verify mode restores on startup failure. It also discloses that original values are never written to results or logs, which is critical for a secrets tool.

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?

Nearly every clause carries real information, but it is delivered as one very dense run-on paragraph with nested dashes and parentheticals, making it hard to scan. Front-loading the purpose is good, but mode behavior and limitations would read far better as separate sentences or a short list.

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 an 8-parameter mutating tool this covers what matters: what changes, what is preserved, how rollback and verification work, what is left as manual work, and how secrets are kept out of output. An output schema exists, so the description does not need to enumerate return fields, and it does not.

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 baseline is 3, but the description adds decision semantics: auto picks per how the key is read, env replaces values with ${EGOV_…_PASSWORD}, crypto-path moves algorithmKey/algorithmKeyHash out and injects Globals.CryptoConfigPath=${EGOV_CRYPTO_CONFIG:}. It also ties verify and timeoutMs to an actual startup check.

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 concrete verb and object ('설정 파일 … 의 DB 비밀번호·비밀 값을 저장소 밖으로 옮깁니다') and lists the exact files it touches. It also distinguishes itself from sibling tools by stating it reuses the check_egovframe_secure_coding hardcoded-config-password rule plus whitelist, and that XML <property name="password" value="리터럴"/> is caught additionally.

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?

It gives clear operating context: default dryRun, apply path, verify=true with rollback on config-missing, and prerequisites such as generate_egovframe_deploy artifacts being present for env placeholders. It also names cases it will NOT handle automatically (keys read via EgovProperties.getProperty, 4.x context-crypto.xml) and routes them to manual items, though it never explicitly names an alternative tool to run instead.

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