Skip to main content
Glama
EricSeokgon

egovframe-scaffold-mcp

by EricSeokgon

SBOM 생성 (CycloneDX)

generate_egovframe_sbom

Generates a CycloneDX 1.6 or SPDX 2.3 SBOM from Maven or Gradle projects without changing build files, attaching eGovFrame baseline judgments and optional OSV vulnerabilities for public-sector SBOM submission.

Instructions

Maven/Gradle 프로젝트의 SBOM 을 CycloneDX 1.6 JSON(기본) 또는 SPDX 2.3 JSON(bomFormat=spdx-json — 패키지·DEPENDS_ON 관계·purl·공급자·작성자·생성 시각)으로 만듭니다(빌드 파일 변경 없음). Maven 은 cyclonedx-maven-plugin(makeAggregateBom, 해시·라이선스 포함), Gradle 은 해석된 의존성 트리로 문서를 구성합니다. enrich=true(기본)면 component 마다 기준 판정(egovframe:status·basis·baseline)을 properties 로 붙이고, offline=false 면 OSV 로 알려진 취약점을 vulnerabilities[] 로 넣습니다. 출력은 프로젝트 안 경로(기본 sbom/bom.cdx.json)만 허용하고 기존 파일은 overwrite=true 가 아니면 거부하며, dryRun(기본)은 실행 없이 계획만 돌려줍니다. 2027년부터 단계화되는 공공기관 SBOM 등록·제출에 쓸 수 있는 표준 형식입니다.

Input Schema

NameRequiredDescriptionDefault
scopeNoruntime(compile+runtime, 기본) | all(test·provided 포함)runtime
authorNoSBOM 작성자(metadata.authors) — 없으면 supplier
dryRunNotrue(기본)면 실행 없이 명령·출력 경로만 보고
enrichNocomponent 마다 기준 판정 속성 부착
formatNo응답 형식markdown
offlineNofalse 면 OSV 조회 결과를 vulnerabilities[] 로 포함
supplierNo공급자(주 component·문서 metadata.supplier) — 없으면 pom <organization><name>
bomFormatNoSBOM 형식: cyclonedx-json(CycloneDX 1.6, 기본) | spdx-json(SPDX 2.3 — CycloneDX 로 만든 뒤 변환)cyclonedx-json
overwriteNo기존 출력 파일 덮어쓰기 허용
timeoutMsNo생성 명령 타임아웃(ms)
outputPathNo프로젝트 상대 출력 경로(기본 sbom/bom.cdx.json, spdx-json 이면 sbom/bom.spdx.json)
projectDirYes프로젝트 디렉터리(절대경로 권장)
componentNameNo주 component 이름 덮어쓰기(기본 artifactId)
fillSuppliersNo공급자가 없는 component 를 공급자 표(catalog/sbom-rules.json)로 보완(egovframe:supplierBasis=catalog) — 기본은 enrich 와 같음
componentVersionNo주 component 버전 덮어쓰기(기본 pom version)

Output Schema

NameRequiredDescriptionDefault
bytesYes
notesYes
directYes
dryRunYes
formatYes
commandYes
logTailNo
minimumNo
writtenYes
osvErrorNo
statusesYes
buildToolYes
generatorYes
componentsYes
durationMsNo
outputPathYes
projectDirYes
transitiveYes
overwrittenYes
specVersionYes
absolutePathYes
vulnerabilitiesYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed19 schema fields changedv1.6.0
    • removedInput schema / additionalProperties
      Removed value: -false
    • addedOutput schema / properties / bytes / maximum
      Added value: +9007199254740991
    • addedOutput schema / properties / bytes / minimum
      Added value: +-9007199254740991
    • addedOutput schema / properties / components / maximum
      Added value: +9007199254740991
    • addedOutput schema / properties / components / minimum
      Added value: +-9007199254740991
    • addedOutput schema / properties / direct / maximum
      Added value: +9007199254740991
    • addedOutput schema / properties / direct / minimum
      Added value: +-9007199254740991
    • changedOutput schema / properties / minimum / additionalProperties
      Previous value: -trueNew value: +{}
    • addedOutput schema / properties / minimum / properties / componentsWithGaps / maximum
      Added value: +9007199254740991
    • addedOutput schema / properties / minimum / properties / componentsWithGaps / minimum
      Added value: +-9007199254740991
    • addedOutput schema / properties / minimum / properties / supplierFromCatalog / maximum
      Added value: +9007199254740991
    • addedOutput schema / properties / minimum / properties / supplierFromCatalog / minimum
      Added value: +-9007199254740991
    • addedOutput schema / properties / statuses / additionalProperties / maximum
      Added value: +9007199254740991
    • addedOutput schema / properties / statuses / additionalProperties / minimum
      Added value: +-9007199254740991
    • addedOutput schema / properties / statuses / propertyNames
      Added value: +{
      +  "type": "string"
      +}
    • addedOutput schema / properties / transitive / maximum
      Added value: +9007199254740991
    • addedOutput schema / properties / transitive / minimum
      Added value: +-9007199254740991
    • addedOutput schema / properties / vulnerabilities / maximum
      Added value: +9007199254740991
    • addedOutput schema / properties / vulnerabilities / minimum
      Added value: +-9007199254740991
  2. Changed5 schema fields changedv0.45.0
    • changedInput schema / properties / bomFormat / description
      Previous value: -"SBOM 형식(현재 CycloneDX JSON)"New value: +"SBOM 형식: cyclonedx-json(CycloneDX 1.6, 기본) | spdx-json(SPDX 2.3 — CycloneDX 로 만든 뒤 변환)"
    • changedInput schema / properties / bomFormat / enum
      Previous value: -[
      -  "cyclonedx-json"
      -]New value: +[
      +  "cyclonedx-json",
      +  "spdx-json"
      +]
    • removedInput schema / properties / outputPath / default
      Removed value: -"sbom/bom.cdx.json"
    • changedInput schema / properties / outputPath / description
      Previous value: -"프로젝트 상대 출력 경로"New value: +"프로젝트 상대 출력 경로(기본 sbom/bom.cdx.json, spdx-json 이면 sbom/bom.spdx.json)"
    • changedOutput schema / properties / format / enum
      Previous value: -[
      -  "cyclonedx-json"
      -]New value: +[
      +  "cyclonedx-json",
      +  "spdx-json"
      +]
  3. Changed6 schema fields changedv0.40.0
    • addedInput schema / properties / author
      Added value: +{
      +  "description": "SBOM 작성자(metadata.authors) — 없으면 supplier",
      +  "maxLength": 200,
      +  "minLength": 1,
      +  "type": "string"
      +}
    • addedInput schema / properties / componentName
      Added value: +{
      +  "description": "주 component 이름 덮어쓰기(기본 artifactId)",
      +  "maxLength": 200,
      +  "minLength": 1,
      +  "type": "string"
      +}
    • addedInput schema / properties / componentVersion
      Added value: +{
      +  "description": "주 component 버전 덮어쓰기(기본 pom version)",
      +  "maxLength": 100,
      +  "minLength": 1,
      +  "type": "string"
      +}
    • addedInput schema / properties / fillSuppliers
      Added value: +{
      +  "description": "공급자가 없는 component 를 공급자 표(catalog/sbom-rules.json)로 보완(egovframe:supplierBasis=catalog) — 기본은 enrich 와 같음",
      +  "type": "boolean"
      +}
    • addedInput schema / properties / supplier
      Added value: +{
      +  "description": "공급자(주 component·문서 metadata.supplier) — 없으면 pom <organization><name>",
      +  "maxLength": 200,
      +  "minLength": 1,
      +  "type": "string"
      +}
    • addedOutput schema / properties / minimum
      Added value: +{
      +  "additionalProperties": true,
      +  "properties": {
      +    "componentsWithGaps": {
      +      "type": "integer"
      +    },
      +    "missing": {
      +      "items": {
      +        "type": "string"
      +      },
      +      "type": "array"
      +    },
      +    "supplierFromCatalog": {
      +      "type": "integer"
      +    },
      +    "verdict": {
      +      "enum": [
      +        "ready",
      +        "needs-work"
      +      ],
      +      "type": "string"
      +    }
      +  },
      +  "required": [
      +    "verdict",
      +    "missing",
      +    "componentsWithGaps",
      +    "supplierFromCatalog"
      +  ],
      +  "type": "object"
      +}
  4. Addedv0.36.1

TDQS

A4.1/5.0
Behavior5/5

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

Goes well beyond the annotations: discloses that build files are never modified, that output is restricted to project-relative paths, that existing files are refused unless overwrite=true, that dryRun defaults to true, and that offline=false triggers OSV network lookups. This is exactly the mutation/safety context the agent needs and it is consistent with destructiveHint=false and openWorldHint=true.

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 purpose and then layered by concern (format → mechanism → enrichment → output safety → dryRun), with zero filler sentences. It is dense and parenthetical-heavy, but for a 15-parameter tool every sentence carries information.

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?

Covers format choice, enrichment, network behavior, path constraint, overwrite policy, and dry-run semantics for a 15-parameter tool; return-value details are legitimately omitted because an output schema exists. Nothing an agent needs to call it correctly is missing.

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; the description nevertheless adds meaning by explaining what enrich actually attaches (egovframe:status·basis·baseline properties), what offline=false produces (vulnerabilities[]), and how spdx-json is derived from CycloneDX. Some of this duplicates the schema text, but the enrichment-property detail is genuinely beyond it.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a precise verb+resource (Maven/Gradle 프로젝트의 SBOM 생성) and specifies the produced formats (CycloneDX 1.6 JSON default, SPDX 2.3 JSON) plus the plugin/mechanism behind each. Purpose is unmistakable, but the description never explicitly contrasts itself with the sibling check_egovframe_sbom, so it stops short of full sibling differentiation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The closing sentence gives a use case (public-institution SBOM 등록·제출 from 2027) and dryRun's default implies a plan-then-execute workflow, but there is no explicit when-to-use/when-not statement and no named alternative (e.g., use check_egovframe_sbom to validate an existing SBOM). Usage is inferable rather than directed.

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