egovframe-scaffold-mcp

포트폴리오(기관 단위) 현황

summarize_egovframe_portfolio

Aggregates assessment reports from multiple eGovFrame projects into one comparison table for migration, supply-chain, security, and operations readiness, with priority fixes and change tracking.

Instructions

여러 전자정부 표준프레임워크 프로젝트의 전환 준비도·공급망·보안약점·운영 준비를 한 표로 모읍니다(새 분석 없이 평가서를 모으기·비교·표). 입력 inputs 는 디렉터리 목록(끝이 /* 면 그 아래 디렉터리 전부)이고 종류를 자동 판별합니다 — 프로젝트(pom.xml·build.gradle: generate_egovframe_report 평가서를 실행, jobs 로 병렬, offline 기본 true), 납품 패키지(delivery-manifest.json: assessment/assessment.json 을 읽기만), CI 아티팩트(egovframe-assessment.json 또는 egovframe-delivery/ — 생성 CI 의 egovframe-supply-chain 아티팩트를 내려받은 폴더). 행: RTE 버전·세대, 전환 난이도·공급망·운영 준비 등급, 수동 전환 항목, 취약 의존성(OSV 조회한 평가서만)·노후 의존성, 보안약점 높음/중간, 공통컴포넌트 수, 평가일, 담당(ownerMap CSV). 분포(세대·등급별)와 '먼저 손댈 것'(여러 프로젝트에 걸친 취약 좌표·보안약점 규칙·운영 미달 규칙 Top N). previous(이전 portfolio.json)를 주면 프로젝트별 등급·취약 ID 변화와 빠진 프로젝트, sort·only(migration:C·supplyChain:D·operations:C·vulnerabilities>0·secure>0·era:4.x·failed)로 정렬·필터. 실패한 입력은 행에 사유. outputDir 를 주면 portfolio.md·portfolio.csv(UTF-8 BOM, 엑셀)·portfolio.json 을 새 디렉터리에 씁니다(프로젝트는 바꾸지 않음).

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": {
      "inputs": "<inputs>"
    },
    "name": "summarize_egovframe_portfolio"
  }
}

Input Schema

Name	Required	Description	Default
`org`	No	기관·사업 이름(제목)
`run`	No	프로젝트 디렉터리면 평가서를 실행(false 면 납품 패키지·CI 아티팩트만 읽음)
`jobs`	No	동시에 평가할 프로젝트 수
`only`	No	필터(쉼표로 여러 개, 모두 만족): migration:C · supplyChain:D · operations:C · vulnerabilities>0 · secure>0 · manual>=10 · era:4.x · failed
`sort`	No	정렬(등급은 나쁜 순, vulnerabilities 는 많은 순)	name
`topN`	No	'먼저 손댈 것' 항목 수
`format`	No	응답 형식	markdown
`inputs`	Yes	프로젝트·납품 패키지·CI 아티팩트 디렉터리(절대경로 권장, 끝이 /* 면 하위 디렉터리 전부)
`offline`	No	프로젝트 평가 때 OSV 조회 안 함(false 면 조회 — 취약점 열이 채워짐)
`ownerMap`	No	프로젝트 → 담당 CSV(name,owner)
`previous`	No	비교할 이전 portfolio.json
`outputDir`	No	portfolio.md·csv·json 을 쓸 새(비어 있는) 디렉터리

Output Schema

Name	Required	Description	Default
`org`	Yes
`top`	Yes
`rows`	Yes
`notes`	Yes
`filter`	Yes
`summary`	Yes
`written`	No
`previous`	Yes
`generatedAt`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Addedv1.17.0Nov 9, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations declare readOnlyHint=false and destructiveHint=false, and the description usefully adds that files are written only into a new empty outputDir and "프로젝트는 바꾸지 않음", plus that offline defaults to true, jobs runs evaluations in parallel, and failed inputs still produce a row with a reason. It does not warn about the runtime cost of running reports across up to 500 inputs, which is the main undisclosed trait for a non-idempotent, non-readOnly tool.

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 is front-loaded in the first clause and every subsequent sentence carries operational detail, with no filler. The single ultra-dense paragraph with nested parentheses stacked on top of dashes makes it harder to scan than a short bulleted structure would be, so it is efficient but not optimal.

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 12-parameter aggregator with three output formats and an output schema, the description covers input type auto-detection, what each output file is, deltas versus a previous run, and where failures surface. An agent has everything needed to invoke it correctly without opening the schema.

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 real meaning: the `/*` glob convention for inputs, `run:false` meaning "납품 패키지·CI 아티팩트만 읽음", `offline:false` filling the vulnerability column, and `previous` producing per-project grade/vulnerability-ID deltas plus dropped projects. The only/lang syntax is also illustrated with concrete examples rather than just the enum list.

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 (aggregate into one table) and resource (multi-project portfolio), and pieces out the row schema, distributions, and top-N rollups. An agent can distinguish this from single-project siblings like generate_egovframe_report purely from the text.

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 clearly frames the scenario (portfolio-level comparison across many projects, with comparison via previous and filtering via only/sort) and explains per-input-type behavior, including that project directories delegate to generate_egovframe_report while delivery packages and CI artifacts are read only. It stops short of explicitly naming a sibling to use instead for a single project, so it stops at a strong 4.

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

Deploy Server