Skip to main content
Glama
Sign In
EricSeokgon

egovframe-scaffold-mcp

by EricSeokgon
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

테스트 실행

test_egovframe_project
Idempotent

Runs eGovFrame project tests, parses JUnit XML reports, and returns structured suite pass/fail/error/skip counts plus failure messages and locations; supports test filters and dry-run preview.

Instructions

eGovFrame 프로젝트의 테스트를 실제로 실행하고 JUnit XML 리포트(surefire/gradle)를 읽어 결과를 구조화합니다. 스위트별 통과·실패·오류·건너뜀 수와, 실패 케이스의 메시지·예외 타입·테스트 파일/라인을 반환합니다. testFilter로 특정 클래스/메서드만 실행할 수 있고, 원격 저장소 일시 장애는 다시 실행합니다(retryTransient). dryRun으로 실행 예정 명령을 미리볼 수 있습니다. (build_egovframe_project 의 테스트 후속)

Input Schema

NameRequiredDescriptionDefault
dryRunNotrue면 실행 없이 감지된 빌드도구·명령·리포트 위치만 반환
projectDirYes테스트할 프로젝트 루트 디렉터리(pom.xml 또는 build.gradle 위치, 절대경로 권장)
testFilterNo실행할 테스트 패턴(빌드도구 문법 그대로). maven: `FooTest`, `FooTest#bar`, `com.acme.*Test` / gradle: `com.acme.FooTest`, `*FooTest.bar`. 생략 시 전체
maxFailuresNo반환할 실패·오류 케이스 최대 수. 기본 50
maxLogLinesNo반환 로그의 최대 줄 수(마지막 N줄). 기본 200줄
retryTransientNo원격 저장소 일시 장애(503·연결 끊김)로 실패하면 갱신 인자(-U / --refresh-dependencies)를 붙여 다시 실행할 횟수(0–3). 컴파일·테스트 실패는 다시 실행하지 않음. 기본 1
timeoutSecondsNo테스트 타임아웃(초). 초과 시 중단. 기본 600초

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.6.0
    • removedInput schema / additionalProperties
      Removed value: -false
    • addedInput schema / properties / retryTransient
      Added value: +{
+  "default": 1,
+  "description": "원격 저장소 일시 장애(503·연결 끊김)로 실패하면 갱신 인자(-U / --refresh-dependencies)를 붙여 다시 실행할 횟수(0–3). 컴파일·테스트 실패는 다시 실행하지 않음. 기본 1",
+  "maximum": 3,
+  "minimum": 0,
+  "type": "integer"
+}
  2. Addedv0.36.1

TDQS

A4.1/5.0
Behavior4/5

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

The annotations already declare non-read-only, open-world, idempotent, non-destructive, so that safety profile is covered; the description adds value by disclosing report consumption (surefire/gradle JUnit XML), the retry policy (only transient 503/connection failures, retried with -U/--refresh-dependencies, compile/test failures are not retried), and the dryRun preview path. It does not say what happens when the timeout is exceeded, or whether a failing test returns a result or raises an error.

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?

Four sentences, front-loaded with what it does and what it returns, then the controls, then the workflow link. Dense but each sentence carries real information; no 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?

There's no output schema, so the description must explain the result shape, which it does, at the level of per-suite counts and failure-case fields. Combined with a 7-param schema that's fully documented, an agent has enough to invoke it correctly; only error and timeout behavior at the boundary remains implicit.

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 coverage is 100%, and every parameter already has a detailed description, including examples of the testFilter build-tool-specific syntax. The description's mentions of testFilter, dryRun, and retryTransient restate what the schema already says, so it does not add meaning beyond the structured fields. Baseline 3 applies.

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 and resource (실제로 실행 = actually run the project's tests) and goes on to describe the return shape (per-suite pass/fail/error/skip counts, failure messages, exception type, file/line). This clearly separates it from build_egovframe_project, which is named as the preceding step.

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 parenthetical '(build_egovframe_project 의 테스트 후속)' places it in the workflow as the follow-up to a build, and the description names three usage modes: testFilter for narrowing to a class/method, dryRun for previewing, retryTransient for flaky remote repos. What's missing is an explicit statement of when not to use it (e.g., after a failed compile, or for running an actual build).

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