egovframe-scaffold-mcp

납품 패키지 만들기

prepare_egovframe_delivery

Packages eGovFrame audit and inspection deliverables into one directory with manifests, SBOMs, security results, and optional build artifacts; verifies integrity or compares previous deliveries.

Instructions

감리·검수에 내는 산출물을 새 디렉터리 하나에 모읍니다 — 전환 준비도 평가서, 의존성 조치 목록, SBOM(CycloneDX 1.6·SPDX 2.3), SBOM 점검과 VEX 초안, 보안약점 결과와 SARIF, 컨테이너·배포 산출물, (지정 시) 빌드 결과. delivery-manifest.json(파일별 sha256·크기, 도구 버전, 입력 지문, 전체 지문 rootHash)과 목차 index.md 를 쓰고, 실패한 항목은 빼지 않고 이유와 함께 목차에 남깁니다. previousDelivery 를 주면 이전 차수와 비교한 diff.md(등급·SBOM 구성요소와 버전·새/해소 취약점·새/해소 보안약점)를 만들고 이전 VEX 의 사람 판단을 보존합니다. verify=true 면 받은 패키지(outputDir)의 지문을 다시 계산해 변조·누락을 봅니다. 프로젝트는 읽기만 하고(SBOM 도 프로젝트에 쓰지 않음) outputDir 는 비어 있어야 합니다. dryRun(기본)은 계획만, zip=true 면 .zip 도 만듭니다.

Input Schema

Name	Required	Description	Default
`zip`	No	true 면 <outputDir>.zip 도 만듦
`dryRun`	No	true(기본)면 계획만
`format`	No	응답 형식	markdown
`verify`	No	true 면 만들지 않고 outputDir 의 manifest 지문을 재검증
`include`	No	담을 항목(기본: build 를 뺀 전부 — build 는 로컬 JDK·Maven/Gradle 로 package 를 실제 실행)
`offline`	No	false 면 OSV 취약점 조회(의존성·SBOM·평가서, 오프라인 번들이 있으면 번들로)
`supplier`	No	SBOM 공급자(없으면 pom <organization><name>)
`outputDir`	Yes	패키지를 만들 디렉터리(프로젝트 밖, 없거나 비어 있어야 함). verify=true 면 검증할 패키지 디렉터리
`projectDir`	Yes	프로젝트 디렉터리(절대경로 권장) — 읽기만 함
`previousDelivery`	No	이전 차수 패키지 디렉터리 — 비교 절(diff.md)과 VEX 판단 보존

Output Schema

Name	Required	Description	Default
`diff`	No
`mode`	Yes
`bytes`	No
`files`	No
`items`	No
`notes`	Yes
`dryRun`	No
`verify`	No
`include`	No
`written`	No
`zipPath`	No
`rootHash`	No
`outputDir`	Yes
`projectDir`	No
`manifestPath`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed15 schema fields changedv1.6.0Oct 26, 2026

removedInput schema / additionalProperties
```
Removed value: -false
```
addedOutput schema / properties / bytes / maximum
```
Added value: +9007199254740991
```
addedOutput schema / properties / bytes / minimum
```
Added value: +-9007199254740991
```
changedOutput schema / properties / diff / additionalProperties
```
Previous value: -trueNew value: +{}
```
addedOutput schema / properties / files / maximum
```
Added value: +9007199254740991
```
addedOutput schema / properties / files / minimum
```
Added value: +-9007199254740991
```
changedOutput schema / properties / items / items / additionalProperties
```
Previous value: -trueNew value: +{}
```
addedOutput schema / properties / items / items / properties / durationMs / maximum
```
Added value: +9007199254740991
```
addedOutput schema / properties / items / items / properties / durationMs / minimum
```
Added value: +-9007199254740991
```
addedOutput schema / properties / items / items / properties / summary / propertyNames
```
Added value: +{
+  "type": "string"
+}
```
changedOutput schema / properties / verify / additionalProperties
```
Previous value: -trueNew value: +{}
```

changedOutput schema / properties / verify / properties / manifest / anyOf

Previous value: -[
-  {
-    "additionalProperties": true,
-    "properties": {
-      "createdAt": {
-        "type": "string"
-      },
-      "files": {
-        "type": "integer"
-      },
-      "items": {
-        "type": "integer"
-      },
-      "rootHash": {
-        "type": "string"
-      },
-      "tool": {
-        "type": "string"
-      }
-    },
-    "required": [
-      "createdAt",
-      "tool",
-      "rootHash",
-      "files",
-      "items"
-    ],
-    "type": "object"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "additionalProperties": {},
+    "properties": {
+      "createdAt": {
+        "type": "string"
+      },
+      "files": {
+        "maximum": 9007199254740991,
+        "minimum": -9007199254740991,
+        "type": "integer"
+      },
+      "items": {
+        "maximum": 9007199254740991,
+        "minimum": -9007199254740991,
+        "type": "integer"
+      },
+      "rootHash": {
+        "type": "string"
+      },
+      "tool": {
+        "type": "string"
+      }
+    },
+    "required": [
+      "createdAt",
+      "tool",
+      "rootHash",
+      "files",
+      "items"
+    ],
+    "type": "object"
+  },
+  {
+    "type": "null"
+  }
+]

changedOutput schema / properties / verify / properties / mismatched / items / additionalProperties
```
Previous value: -trueNew value: +{}
```
addedOutput schema / properties / verify / properties / verified / maximum
```
Added value: +9007199254740991
```
addedOutput schema / properties / verify / properties / verified / minimum
```
Added value: +-9007199254740991
```

Addedv1.2.0Oct 23, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Goes well past the annotations by disclosing what gets written (delivery-manifest.json with per-file sha256, tool versions, rootHash, plus index.md), that failures are retained with reasons rather than dropped, and that previousDelivery preserves prior VEX human judgments. Annotations already cover the read-only/destructive/open-world profile, so this added write-scope detail is the valuable part.

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?

Front-loaded with the core action and artifact list, then moves to outputs, then comparison, then verification, then preconditions — a logical order. It is a single dense paragraph with heavy parenthetical nesting, which costs a little scannability, but essentially no sentence is 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 10-parameter mutation tool with an output schema, it covers write scope, failure handling, comparison behavior, preconditions, and the dryRun/zip modes. What it leaves implicit are operational details such as runtime cost and behavior on a partially populated outputDir, though the emptiness precondition implies an error.

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%, but the description still adds semantics: previousDelivery produces diff.md and carries VEX decisions forward, verify switches the tool from generation to fingerprint re-computation, and include's 'build' option is called out as actually running a local JDK/Maven/Gradle package. That is meaning beyond the schema's own one-liners.

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 concrete verb and resource ('산출물을 새 디렉터리 하나에 모읍니다') and enumerates exactly which artifacts are collected (assessment, dependency list, SBOM, VEX, SARIF, deploy, build), which no sibling does. An agent can distinguish it from generate_egovframe_sbom or generate_egovframe_report, which produce single artifacts.

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 explicit preconditions ('outputDir 는 비어 있어야 합니다', project is read-only) and two distinct modes: verify=true re-verifies an existing package instead of building, and dryRun(default) plans only. It does not explicitly say 'use this instead of X sibling', so it stops short of full alternative routing.

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

Deploy Server