Skip to main content
Glama
Sign In
EricSeokgon

egovframe-scaffold-mcp

by EricSeokgon
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Spring 설정 파일 생성

generate_egovframe_config

Generates eGovFrame Spring configuration files from official Initializr templates for datasource, transaction, cache, logging, and scheduling, with XML, JavaConfig, YAML, or properties output.

Instructions

공식 eGovFrame Initializr 설정 템플릿(21종, 오프라인 동봉)으로 Spring 설정 파일을 생성합니다 — datasource(DBCP/C3P0/JDBC·JNDI), transaction(datasource/JPA/JTA), cache(Ehcache), logging(log4j2 console/file/rolling/time-rolling/jdbc), scheduling(Quartz job/trigger/scheduler), idGeneration(sequence/table/uuid), property. 형식은 xml(Spring XML)·javaConfig(@Configuration 클래스)·yaml·properties(logging 만). 필드를 생략하면 Initializr 웹뷰 폼과 같은 기본값을 쓰고, 기존 파일이 있으면 덮어쓰지 않고 거부합니다. 템플릿별 필드·기본값·선택지는 리소스 egovframe://catalog/config-templates 에서 확인하거나 dryRun 결과의 context 로 볼 수 있습니다.

Input Schema

NameRequiredDescriptionDefault
dryRunNotrue면 파일을 쓰지 않고 내용·경로·컨텍스트만 반환
fieldsNo템플릿 변수 덮어쓰기 (예: { txtDatasourceName: 'dataSource', rdoType: 'DBCP', txtUrl: 'jdbc:mysql://…', txtConfigPackage: 'kr.go.sample.config' }). 템플릿에 없는 필드는 거부
formatNoxml | javaConfig | yaml | properties (yaml·properties 는 logging 계열만)xml
configIdYes설정 템플릿 id (예: datasource, transaction-datasource, logging-rolling-file, scheduling-cron-trigger)
fileNameNo파일명(확장자 제외) 또는 JavaConfig 클래스명. 미지정 시 Initializr 기본값(예: context-datasource, EgovDataSourceConfig)
outputDirNo프로젝트 상대 출력 디렉터리. 미지정 시 xml→src/main/resources/egovframework/spring(logging 은 src/main/resources), javaConfig→src/main/java/<패키지>
projectDirYes대상 프로젝트 디렉터리(절대경로 권장)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.6.0
    • removedInput schema / additionalProperties
      Removed value: -false
    • addedInput schema / properties / fields / propertyNames
      Added value: +{
+  "type": "string"
+}
  2. Addedv0.36.1

TDQS

A4.3/5.0
Behavior5/5

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

Annotations only declare write-side flags (readOnly=false, destructive=false, idempotent=false, openWorld=false); the description adds the facts that matter: existing files are not overwritten but rejected, unknown fields are refused, defaults mirror the Initializr web form, and dryRun returns content/path/context without touching disk. That is non-obvious behavior an agent could not infer from the annotations or schema alone.

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?

Purpose and the 21-template scope are front-loaded in the first clause, followed by formats, defaults, and the overwrite policy. The long inline enumeration of template categories is partly redundant with the configId enum, costing some density, but the paragraph is otherwise free of filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a high-complexity tool (21 templates, free-form nested `fields`, four format modes) the description closes the biggest gap by pointing to egovframe://catalog/config-templates and the dryRun context output for discovering per-template variables. With no output schema, the non-dryRun return value (written path, any file list) is left unspecified, which is the remaining hole.

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

Parameters3/5

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

Schema description coverage is 100%, and the description largely restates what the schema already documents (format availability for yaml/properties limited to logging, default fileName/outputDir behavior, dryRun semantics, field rejection). The genuine additions are the pointer to the catalog resource for per-template field names and the note that omission means Initializr defaults, so it sits just above the baseline.

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?

States a specific verb (생성) and resource (Spring 설정 파일) and bounds the scope precisely: 21 official Initializr templates, enumerated by category (datasource, transaction, cache, logging, scheduling, idGeneration, property). An agent can immediately tell this apart from siblings like create_egovframe_project or add_egovframe_components, which operate on project/component structure rather than config files.

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 operating context: omitted fields fall back to Initializr web-form defaults, and an existing file causes a refusal rather than an overwrite. It also routes the agent to egovframe://catalog/config-templates or a dryRun 'context' result for template-specific fields. It stops short of naming an alternative tool or stating explicit when-not-to-use conditions beyond the overwrite case.

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

Deploy Server

Other Tools