Skip to main content
Glama
Sign In
egovframe-scaffold-mcp

egovframe-scaffold-mcp

by EricSeokgon
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

프로젝트 구조 지도·변경 영향

map_egovframe_project
Read-onlyIdempotent

Map an eGovFrame project's static architecture from tables and mapper XML through DAO, Service, Controller, URLs, and views, and trace impact for handover or change analysis.

Instructions

프로젝트를 읽어 테이블 → 매퍼 XML(네임스페이스, DB 별 사본은 하나로) → DAO/Mapper 인터페이스 → Service → Controller → URL → 화면(JSP·Thymeleaf)의 구조 지도를 만듭니다(읽기 전용, 정적 해석 — 파일·정규식·심볼 테이블, 런타임 추적 없음). 표준프레임워크 규약(EgovComAbstractDAO 의 "네임스페이스.문장id" 문자열, @Resource(name=…) 빈 이름, *ServiceImpl)과 Spring 어노테이션(@Mapper·@Autowired·@GetMapping 등)을 둘 다 읽고, 공통컴포넌트 파일은 카탈로그 경로 접두어로 컴포넌트를 표시합니다. impact 로 한 노드의 영향을 거리순으로 — table(COMTNBBS) 은 사용하는 매퍼·서비스·컨트롤러·URL·화면(위로), url(/cop/bbs/selectArticleList.do)·view 는 거꾸로 테이블까지(아래로) + 링크하는 화면 한 단계, class 는 양쪽. 인수인계 표 3종(화면 목록: URL·Controller·화면 / 프로그램 목록: Controller·Service·DAO·매퍼 / DB 접근 표: 테이블 × C·R·U·D × 매퍼)과 고아(호출 없는 매퍼·문장, URL 없는 Controller, 미참조 컴포넌트 테이블), 해석 실패율(동적 SQL ${…} 테이블·찾지 못한 뷰)을 함께 냅니다. format=json 은 전체 그래프(nodes·edges·statements·handover), mermaid 는 components 또는 impact 로 좁힌 200 노드 이하만. 동적 SQL 의 테이블 이름·프런트(React) 라우팅·리플렉션은 보지 않습니다.

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

Input Schema

NameRequiredDescriptionDefault
topNNoMarkdown 표마다 보일 행 수
formatNo응답 형식(mermaid 는 components 또는 impact 로 좁힌 범위만)markdown
impactUrlNo영향 조회: URL(예 /cop/bbs/selectArticleList.do) — 거꾸로 테이블까지 + 링크하는 화면
componentsNo공통컴포넌트 id 로 범위를 좁힘(그 경로 아래 파일 + 거기에 닿는 화면)
impactViewNo영향 조회: 화면(뷰 이름 또는 파일 경로)
projectDirYes프로젝트 디렉터리(절대경로 권장, 멀티 모듈이면 루트 — 노드에 module 표시)
impactClassNo영향 조회: 클래스(FQN 또는 단순명) — 양쪽
impactTableNo영향 조회: 테이블 이름(예 COMTNBBS) — 사용하는 매퍼·서비스·컨트롤러·URL·화면

Output Schema

NameRequiredDescriptionDefault
edgesYes
nodesYes
notesYes
impactNo
orphansYes
summaryYes
handoverNo
durationMsYes
projectDirYes
statementsYes
generatedAtYes
componentTablesYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.15.0

TDQS

A4.6/5.0
Behavior5/5

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

The annotations already declare read-only, idempotent, non-destructive, and closed-world behavior, and the description adds substantial context beyond them: static file/regex/symbol-table analysis with no runtime tracing, supported EgovFrame and Spring conventions, common-component prefix handling, bidirectional impact semantics, handover tables, orphan detection, parse-failure reporting, and mermaid's 200-node limit. No annotation contradiction is present.

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?

The description is long but justified by the tool's complexity, and it is front-loaded with the core purpose. The dense parenthetical details and long clauses make it harder to scan than necessary, but every sentence contributes functional 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?

Given an eight-parameter tool with full schema coverage, annotations, and an output schema, the description is complete enough for correct invocation. It covers purpose, static-analysis behavior, impact directionality, output modes, handover artifacts, orphan detection, parse-failure reporting, and known limitations.

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 description coverage is 100%, so the baseline is 3. The description adds meaning beyond the schema by explaining impact directionality for impactTable, impactUrl, impactView, and impactClass, and by clarifying that format=json returns the full graph while mermaid is limited to narrowed components or impact output.

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 description states a specific verb and resource: it reads the project and builds a structure map from table through mapper XML, DAO/Mapper, Service, Controller, URL, and screen. It also distinguishes the tool from siblings implicitly by framing it as static structure/impact mapping rather than diagnosis, validation, or generation.

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?

The description gives clear usage context: read-only static analysis, impact lookups by table/url/view/class, and output format choices. It also states what the tool does not see (dynamic SQL table names, React routing, reflection), which helps set boundaries. However, it does not explicitly compare this tool with alternatives such as diagnose_egovframe_project or explain_egovframe_component.

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