egovframe-scaffold-mcp

운영 준비 점검

check_egovframe_operations

Read-onlyIdempotent

Checks eGovFrame production configuration before deployment, flags risky settings, and suggests exact lines to change without modifying files.

Instructions

"기동은 되는데 운영에서 터지는" 설정을 운영 투입 전에 점검합니다(읽기 전용, 값을 고치지 않고 바뀔 줄을 제안). 운영 설정 세트 — Boot 는 application + application-prod(production·release·ops 중 있는 것, profile 로 지정).* 만 보고 dev·local·test 프로파일은 뺍니다, Classic 은 globals.properties·context-*.xml·web.xml·log4j2/logback.xml — 에서 규칙 데이터(catalog/operations-rules.json, 규칙마다 출처 명시) 17종을 평가합니다: SQL 로깅 프록시 드라이버(log4jdbc·P6Spy) 잔존, DEBUG/TRACE 로그 수준, 콘솔 전용 로그(로테이션 없음), spring-boot-devtools, 내장 DB(HSQL·H2) 잔존, 커넥션 풀 크기·타임아웃·수명·누수 감지 미설정, 세션 타임아웃 없음/60분 초과, 세션 쿠키 http-only·secure, 업로드 상한 없음/100MB 이상·허용 확장자 없음, 업로드 경로 상대·/tmp·웹 루트, 오류 상세 노출(include-stacktrace·show-sql·debug), error-page 없음, actuator 전체 노출, 표준프레임워크 개발 플래그(LocalIp 127.0.0.1·Hsql.AutoInit), 운영 프로파일 없음, 하드코드 비밀값(보안약점 규칙과 같은 판정, externalize_egovframe_config 참조). 결과는 점검표(규칙 × 통과/미달/해당 없음)·미달 항목(파일·줄·현재 값·제안·근거)·등급 A–D(규칙 단위: A 높음 0·중간 ≤1, B 높음 ≤1·중간 ≤3, C 높음 ≤3, D). 예외는 .egovframe-ops-ignore.json(rule·path·reason·reviewer). 공식 운영 기준 문서가 없어 근거는 공식 템플릿 기본값 실측·HikariCP/Spring Boot/Tomcat 문서입니다. 평가서(generate_egovframe_report)에도 「운영 준비」가 들어갑니다. 부하 시험·운영 WAS(JEUS 등)·OS/DB 서버 설정은 보지 않습니다.

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": "check_egovframe_operations"
  }
}

Input Schema

Name	Required	Description	Default
`topN`	No	Markdown 에 보일 미달 항목 수
`rules`	No	점검할 규칙 id(기본 전체)
`format`	No	응답 형식	markdown
`profile`	No	운영 프로파일 이름(Boot, 기본: prod·production·release·ops 중 있는 것)
`projectDir`	Yes	프로젝트 디렉터리(절대경로 권장)

Output Schema

Name	Required	Description	Default
`grade`	Yes
`notes`	Yes
`rules`	Yes
`runtime`	Yes
`summary`	Yes
`findings`	Yes
`configSet`	Yes
`ignoreFile`	Yes
`projectDir`	Yes
`filesScanned`	Yes
`rulesVersion`	Yes
`invalidIgnores`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Addedv1.15.0Nov 5, 2026

TDQS

A4.3/5.0

Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive, yet the description still adds substantial behavior: it evaluates 17 named rules from a catalog file with cited sources, produces a pass/fail/N-A checklist plus per-finding file, line, current value, proposal and rationale, and assigns an A–D grade with explicit thresholds. It also discloses the suppression mechanism (.egovframe-ops-ignore.json with rule/path/reason/reviewer) and the basis for judgments (measured official template defaults, HikariCP/Spring Boot/Tomcat docs) — none of which any structured field conveys.

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 purpose is front-loaded in the first clause, but the body is a single sprawling sentence with stacked parentheticals and dash clauses that is hard to scan despite nearly all content being relevant. Heavy nesting and inline rule inventories make it dense at the cost of readability.

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 complex 17-rule audit tool the description covers scope, exclusions, result shape, grading, suppression, and rule provenance, and it even explains return values despite an output schema existing. An agent has everything needed to decide to call it and to interpret the response without opening other tools.

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%, so all five parameters are already documented, and the description largely restates them (17 rules maps to the rules enum, checklist/findings maps to topN and format). It adds only modest value, mainly the profile resolution rule for which files get scanned. Baseline 3 is appropriate.

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 opening sentence states a concrete verb and target: it audits configuration that 'starts fine but blows up in production' before go-live, read-only, proposing changed lines rather than fixing them. It then enumerates exactly which file sets are in scope (Boot: application + application-prod; Classic: globals.properties, context-*.xml, web.xml, log4j2/logback.xml) and explicitly excludes dev/local/test profiles and non-scope areas (load tests, JEUS/WAS, OS/DB settings), so an agent can tell it apart from validate/diagnose siblings.

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?

Timing guidance is explicit ('before putting into operations') and the negative scope is spelled out, plus a pointer to externalize_egovframe_config for hardcoded secrets and to generate_egovframe_report for where results also surface. What is missing is direct routing against the closest siblings (validate_egovframe_project, diagnose_egovframe_project, check_egovframe_secure_coding), which an agent must still infer.

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

Deploy Server