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

Goes well beyond the annotations by disclosing real behavioral traits: backups are created, removal restores originals, missing dependencies are inserted only inside marker sections, and any conflict causes a full abort with nothing written. It also notes dryRun needs no network. It does not describe the response/report shape, which keeps it off a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Four dense sentences, front-loaded with the outcome, then the mechanics, then the safety guarantee, then the preview tip. Every sentence carries information, though the parenthetical feature chain makes the first sentence heavy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a mutating, open-world assembly tool the description covers what is copied, what is merged, failure behavior, and the dry-run escape hatch, and annotations already carry the safety profile. What an agent still lacks is the result/report content and any prerequisite checks, but overall it is sufficient to call correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so every parameter (stack enum, ref, dryRun, includeUi/includeInfra/includeTests, projectDir) is already documented in the schema. The description reinforces dryRun and the UI/infra copies but adds no new syntax, defaults, or interactions beyond what the schema states, so the baseline 3 applies.

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

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

States a concrete verb+resource: assembling an official egovframe-ai-rag sample RAG chatbot (upload→embedding→hybrid search→LLM) into an existing Boot project, plus what gets copied (source, config, UI, infra) and the pom edit. It is clearly distinct from the generic add_egovframe_components in scope, but it never names that sibling to make the boundary explicit.

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

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

Usage is implied by the context ('기존 Boot 프로젝트에 조립', egovframe-boot-starter-parent based) and there is a strong workflow hint to run with dryRun=true first. However, it gives no explicit when-to-use/when-not versus add_egovframe_components or reassemble_egovframe_components, and no stated prerequisites for the target project.

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

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

Adds substantial behavior beyond the annotations: dependencies are auto-included, DB DDL/DML scripts are copied only when database is specified, and the write is all-or-nothing — any conflict with existing files aborts the whole operation without writing anything. That atomic-refusal guarantee is the key detail for a non-idempotent write tool and it is stated explicitly.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Four short sentences, each carrying a distinct fact (what is copied, DB-script condition, conflict policy, preview option), with the core action front-loaded and zero filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a mutating multi-file install tool with no output schema, the description covers the essential risks: conflict handling, dependency expansion, DB-script side effect and a no-network dry run. The only real gap is the explicit prerequisite chain to create_egovframe_project, which is left to the schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents dryRun, database, components, projectDir and includeDependencies. The description reinforces the semantics (database → DDL/DML copying, dependencies pulled in) but does not add format, ordering or validation detail beyond what the schema gives, so the baseline 3 applies.

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

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

States a concrete verb+resource (공통컴포넌트를 조립) and immediately bounds the scope: copies dependent components' source, mapper and JSP files into an existing project. That scope distinguishes it from create_egovframe_project (scaffolds new projects), remove_egovframe_components and reassemble_egovframe_components without needing the schema.

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

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

The only usage guidance is the recommendation to preview with dryRun=true first; there is no explicit statement of when to pick this tool over siblings such as reassemble_egovframe_components or apply_egovframe_recipe. The prerequisite (run create_egovframe_project first) lives in the projectDir schema description rather than in the tool description, so the workflow is only implied.

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

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

Annotations already declare readOnlyHint=false, idempotentHint=false, openWorldHint=true, so the agent knows this mutates state and is not repeat-safe. The description adds the sequential multi-phase nature and the dryRun safety valve, but never mentions overwrite behavior for an existing outputDir or what happens on partial failure mid-sequence — important for a non-idempotent, open-world writer.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences, with the operation and its phases front-loaded before the dryRun tip. The second sentence largely repeats the dryRun parameter description already in the schema, so one clause is slightly redundant, but nothing is verbose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

This is a multi-phase orchestrator with no output schema, so the description should say what the returned plan/result looks like and how partial failures surface — neither is covered. Combined with the missing overwrite/idempotency context, it is adequate but has clear gaps for a tool of this complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so every parameter (including recipeId pointing at list_egovframe_recipes and the dryRun flag) is already documented in-schema; the description's recipe/dryRun mentions restate that. Baseline 3 applies — no extra syntax, format, or cross-parameter interaction is added.

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

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

States a specific verb and resource ('레시피 하나를 골라') and spells out the composite job: project creation followed by common-component assembly, optionally with AI layer. That composite scope implicitly separates it from create_egovframe_project / add_egovframe_components, but those siblings are never named.

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

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

The dryRun sentence implies a preview-then-run workflow, which is useful guidance. However there is no explicit statement of when to pick this composite tool over the granular create_egovframe_project + add_egovframe_components path, and no prerequisites or exclusions are given.

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

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

Annotations already declare readOnly=false, idempotent=true, destructive=false, openWorld=true, and the description adds substantial context beyond them: automatic maven/gradle and mvnw/gradlew detection, file/line error parsing, failureKind=repository-unavailable classification, -U re-execution for transient 5xx/disconnect failures only (not compile/test failures), and dryRun preview. Missing only what the structured result actually contains, e.g. artifact paths or the full error list shape.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the core action ('실제로 빌드하고 결과를 구조화해 반환') followed by the valuable behaviors. Four dense sentences with parenthetical asides that all carry content, though the packing makes it slightly heavy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 6-parameter build tool with no output schema and open-world network behavior, the description covers tool detection, error parsing, transient-failure handling, timeout and dryRun. What remains thin is the shape of the returned structured result and any environment prerequisites (JDK/toolchain availability).

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the schema already documents goal, dryRun, retryTransient, timeoutSeconds and maxLogLines, establishing a baseline of 3. The description reinforces retryTransient's semantics (only transient repository failures trigger a refresh-argument retry) but adds little that the schema descriptions do not already state.

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

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

States a concrete verb and resource — actually builds (compiles/tests/packages) a generated eGovFrame project and returns structured results — which is more specific than the create_/validate_ siblings. However it never names or contrasts those siblings, so an agent must infer the boundary with test_egovframe_project and validate_egovframe_project.

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

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

Usage is only implied via '(생성→검증 루프 완성)' and the dryRun preview, indicating it belongs after project creation. There is no explicit when-to-use vs when-not, and no statement of how it differs from the test or validate siblings.

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

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

Goes well beyond the readOnly/idempotent annotations: states it does not modify disk, defaults to offline with bundled catalog and only hits api.osv.dev when offline=false, warns resolve needs build tool + repo access and takes tens of seconds, and explains multi-module per-module judging plus the 5.1.0/-egov.N normalization special cases.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the core purpose, but it is one enormous run-on sentence packed with parenthetical enumerations, making the special-case rules (5.1.0, -egov.N, 멀티 모듈) hard to extract on a fast read.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With annotations covering the safety profile, an output schema present, and full schema coverage, the description supplies nearly everything needed: scope, offline/online behavior, resolve cost, and multi-module handling. Only sibling disambiguation is left as a gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3; the description earns extra credit for clarifying what resolve actually produces (전이 의존성 + 트리 경로 + 선언·해석 버전 차이) and what offline toggles (OSV 조회), meaning an agent understands the cost/benefit tradeoff before setting them.

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

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

Opens with a specific verb+resource: Maven/Gradle 의존성을 기준 버전과 대조해 분류·보고. It names concrete baseline sources (공식 5.x parent, Spring Boot BOM, RTE 18종) and output categories (기준 충족/전환 대상/교체 필요 등), which none of the siblings (check_egovframe_sbom, validate_egovframe_project) describe.

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

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

Usage is implied by the content ('프로젝트의 의존성 점검'), and the offline flag hints at when network use is warranted, but the description never states when to pick this over check_egovframe_sbom or check_egovframe_secure_coding, nor any prerequisites beyond resolve's build-tool requirement.

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

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

Adds substantial context beyond the annotations: the input SBOM is never modified, format is auto-detected, OSV lookups occur only when offline=false (consistent with openWorldHint=true), and vex=true writes a CycloneDX VEX draft to a stated default path while preserving human-authored judgments. The write path explains the readOnlyHint=false / idempotentHint=false annotations rather than contradicting them.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the core statement, then organized into numbered (1)-(4) modes so each paragraph maps to a capability; almost nothing is redundant. It is nonetheless a very dense single block with heavy parentheticals, which slightly hurts scannability.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Eight parameters, one required, 100% schema coverage, and an output schema exists — so the description need not specify return values, and it doesn't. It covers every mode the parameters enable plus the 2027 submission-framing rationale, leaving no operational gaps for the agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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 on top: it constrains vex to CycloneDX inputs only (not stated in the schema), explains what baselinePath compares (added/removed, version changes, verdict changes, new vulnerabilities), and clarifies dryRun's interaction with vex=true.

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

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

States a specific verb and resource ('이미 만든 CycloneDX 또는 SPDX 2.x JSON SBOM 을 제출물로서 점검합니다') and enumerates the four distinct check modes so the agent knows exactly what it does. It is clearly differentiated from the sibling generate_egovframe_sbom: this consumes an existing SBOM, it does not produce one ('SBOM 파일은 바꾸지 않음').

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

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

Gives explicit when-to-use conditions for each mode: baselinePath for regression comparison, offline=false for re-querying OSV during operation, vex=true for drafting VEX, dryRun=true for preview. The 'generation-time vs now' framing tells the agent when this is the right tool. It does not, however, name the alternative sibling (generate_egovframe_sbom) explicitly, so it falls short of a 5.

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

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

Discloses behavior well beyond annotations: comments are ignored, exceptions require reason/reviewer via .egovframe-secure-ignore.json, writes SARIF when sarifPath is set (consistent with readOnlyHint=false), and the intra-method-only data-flow limitation is stated explicitly. These operational details are exactly what the annotations do not convey.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose is front-loaded, but the description is a very dense wall of text with a long inline enumeration of rule categories and version-history notes (v1.5, v1.7) that increase cognitive load. Most content earns its place, but the density hurts scannability.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Complete for a 12-parameter tool: output schema and 100% schema coverage handle the return/param surface, and the description covers exceptions, baseline diffing, SARIF export, and analytical limitations. Nothing needed 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.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3, but the description adds real meaning: the v1.5 paragraph elaborates what dataFlow=true does (raises/lowers grades, finds flows through variables, not inter-method) and explains baselinePath accepts prior JSON or SARIF. Adds value beyond the schema's field descriptions.

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

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

States a specific verb (소스에서 찾습니다) and resource (구현단계 보안약점) and enumerates the concrete vulnerability classes it detects (SQL 삽입, XSS, 경로 조작, etc.). It is clearly a static security-pattern scanner, readily distinguished from the sibling fix_egovframe_secure_coding which it explicitly references for remediation.

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

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

Routes fixable findings to fix_egovframe_secure_coding and frames itself as '패턴 기반 진단 보조이며 공인 진단을 대체하지 않습니다', which is a clear scope/limitation caveat. It does not explicitly contrast against other diagnostics like diagnose_egovframe_project, so silent-vs-silent selection is left to inference.

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

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

Annotations already flag a non-read-only, non-idempotent, open-world write; the description adds that it downloads from GitHub (network dependency), writes files under outputDir, that dryRun avoids disk writes, and that alignParent mutates pom versions post-generation. The one gap is what happens when outputDir is non-empty or the name already exists — important for a non-idempotent writer.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Four sentences of dense, front-loaded content: purpose first, then template mechanics, then dryRun, then alignParent. Slight redundancy between the description and the alignParent schema text, but no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema and no return-value description — an agent does not know whether it gets a path, a file list, or a summary. For a disk-writing, network-dependent scaffold generator, the description should also mention prerequisites (network, JDK/Maven) and how an existing outputDir is handled.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3 and the schema already explains ref, dryRun, database, template, outputDir and projectName. The description restates the main knobs and adds rationale for alignParent (official templates pin parent 5.0.0/5.0.1), but adds little on ref, template choices, or outputDir constraints.

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

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

States a specific verb and resource (create a new project skeleton) plus the source of truth: the official eGovFrame GitHub template. That is clearly distinguishable from siblings like add_egovframe_components or upgrade_egovframe_project without opening any schema.

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

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

Gives real workflow guidance: preview with dryRun=true first, and use alignParent=true when the generated project must sit on the latest 5.0.x parent/RTE. It does not name an alternative for the case where a project already exists (e.g. upgrade_egovframe_project), so there is no explicit when-not clause.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), and the description adds the key operational fact that it actually sends outbound DNS and HEAD requests to external hosts, plus that it writes no files and needs no project directory. It discloses the failure taxonomy and the concrete remediation it will suggest. It does not say whether failed hosts shorten or abort the sweep, nor how long a full run takes.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose is front-loaded in the first clause, followed by the trigger condition and the negative constraints. The long host enumeration and the remediation env-var list duplicate schema content and make the first sentence dense, but nothing is truly wasted.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, return values need no explanation, and the description supplies purpose, trigger, side effects, and remediation content. What remains unstated is behavior on partial failure and whether results are actionable when all hosts pass but builds still time out.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so each parameter is already documented and the enums constrain hosts and format. The description repeats the host list and adds no syntax or behavioral detail for hosts/timeoutMs/format beyond the schema, so baseline 3 is appropriate.

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

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

States a specific verb (diagnose) and a precisely bounded resource: DNS lookups and HEAD requests to a fixed host list, reporting reachability, latency, and failure class. The enumerated hosts and failure taxonomy distinguish it clearly from the sibling diagnose_egovframe_project, which targets project state rather than outbound connectivity.

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

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

'프로젝트 생성·컴포넌트 조립이 타임아웃으로 실패할 때 먼저 실행하세요' gives an explicit trigger condition and orders it ahead of create_egovframe_project/add_egovframe_components. It also states what is not needed (프로젝트 디렉터리도 필요 없습니다). It stops short of naming when-not-to-use or an explicit alternative for non-network failures.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is clear. The description adds that it supports existing non-scaffolded projects, but its read-only statement largely repeats annotations and it provides no additional permission, rate-limit, or side-effect context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences and front-loads the scan/diagnose action and scope. It is dense but has no redundant filler, apart from the read-only statement already covered by annotations.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists and the single parameter is fully documented in the schema, so the description only needs to explain purpose and scope. It does that well, including the non-scaffolded project case, though it could be stronger by explicitly routing agents away from similar validation or dependency-check tools.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There is one parameter, projectDir, and schema description coverage is 100%, with the schema already recommending an absolute path. The description identifies the target as a project but does not add path syntax or format meaning beyond the schema.

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

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

The description states a specific verb and resource: scanning and diagnosing an existing eGovFrame project. It enumerates concrete diagnostic areas (build system, RTE version, DbType, common components, configuration issues) and clarifies that non-scaffolded projects are included, though it does not explicitly distinguish this from validate_egovframe_project or check_egovframe_dependencies.

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

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

The description implies when to use it by specifying existing projects, including ones not created by scaffolding tools, but it gives no explicit when-not guidance and does not name alternatives such as validate_egovframe_project or check_egovframe_dependencies.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so the trailing '(읽기 전용)' is mildly redundant but not contradictory. The real added value is the enumeration of return contents, which matters because there is no output schema; no auth or rate-limit context is provided, keeping it below a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single front-loaded sentence plus a parenthetical tag, with every clause listing a concrete return element. The redundant '(읽기 전용)' is the only wasted token, preventing a 5.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description carries the burden of describing the return value and does so by enumerating its sections. The lone required parameter is fully documented by the schema, and annotations cover safety, so an agent has nearly everything needed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There is only one parameter and schema description coverage is 100%, with an example ('bbs') already in the schema. The description adds no syntax, format, or lookup guidance beyond that, so baseline 3 applies.

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

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

The description uses a specific verb ('반환합니다') and resource ('공통컴포넌트 하나의 상세') and enumerates exactly what the response contains (dependencies, dependents, reference tables, guide links, install command). The word '하나의' (one) implicitly contrasts it with the sibling search_/list_ tools, but no sibling is named explicitly.

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

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

The single-component scope implies when to use it versus the list/search siblings, but the description never states the condition ('when you have an id and need full detail') or any exclusions. Usage is left to inference from the name and scope.

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

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

Annotations already declare destructive=true, openWorld=true, and idempotent=false, and the description adds substantial beyond-annotation context: default dryRun behavior, file-transaction application with backups under migration-backup/<timestamp>-deps-fix-…, compile verification with full rollback on failure, and offline bundle behavior. It also discloses what is intentionally not fixed and how vulnerability counts are reported.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the purpose and the contrast against check_egovframe_dependencies, then structured as a numbered remediation sequence. It is dense and long, but the length is justified by the tool's complexity; minor readability loss comes from packing extensive caveats into a single paragraph.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the mutation/destructive nature, nine parameters, full schema coverage, and an output schema, the description is complete enough for an agent to invoke the tool correctly. It covers the remediation workflow, backup and rollback semantics, Gradle limits, manual fallbacks, offline behavior, and what the result reports, without needing to explain return values that the output schema already defines.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all nine parameters and the baseline is 3. The description still adds workflow meaning for several parameters: target as the parent upgrade goal, dryRun as plan-only by default, verify as compile-and-rollback, offline as OSV-skipping, and the four kinds as the ordered remediation categories.

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

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 fixes dependency problems in pom.xml, including multi-module projects, and explicitly contrasts this with check_egovframe_dependencies, which only finds them. An agent can distinguish this tool from the diagnostic sibling without opening the schema.

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

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

It names the alternative check_egovframe_dependencies and defines the selection condition: use that tool to find issues, this tool to fix them. It also states important exclusions and limitations: parent-managed and transitive vulnerabilities are reported but not fixed, Gradle support is limited to literal g:a:v unpin and cve-bump, and major-version changes or missing fix versions are manual.

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

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

With destructiveHint=true already declared, the description adds substantial context beyond annotations: which rules are auto-fixed, which are deliberately downgraded to suggestions only (cookie-flags), which are routed to manual (HTML editor body fields, no logger, static context), that originals are preserved in migration-backup/, and that writes use a file transaction. The recheck-gate rule ('고친 항목만 사라지고 새 항목·다른 규칙 변화가 없어야 함') is exactly the kind of safety contract an agent cannot infer from annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the core contract, then per-rule behavior, then the dryRun/transaction gate—a logical order with no filler sentences. It is a dense block of semicolon-joined clauses that would scan faster as a short list, which is the only reason it is not a 5.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 9-parameter destructive fixer, the description covers the decision boundaries (which findings get fixed vs. deferred), the safety model (default dryRun, backup directory, transactional apply, recheck mismatch aborts), and the exclusion policy. An output schema exists, so return-value detail is correctly omitted.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3, but the description goes further by tying parameters to behavior: includeComponents/includeTests are off by default for provenance and test isolation, and ignoreHtmlTagFilter is conditioned on HTMLTagFilter being registered and the intent of switching to output escaping. That explains the concrete consequence of each flag rather than restating its schema text.

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

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

Names a specific verb and resource ('고치고' / auto-remediation of secure-coding findings) and explicitly scopes the work as a subset of what check_egovframe_secure_coding reports, which distinguishes it from that sibling in one clause. An agent knows immediately this is the write-side counterpart of the checker.

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

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

Establishes the workflow precondition (run the checker first, then fix only rule-determinable items) and states that remaining findings are emitted as manual items with reasons, which effectively tells the agent when this tool will not do the work. It does not explicitly name an alternative for the unfixable cases, but the manual-item fallback covers the routing need.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the safety class is known; the description adds the meaningful detail that existing files are protected behind an explicit overwrite gate and that dryRun is a non-writing preview. That is real added context about what would be destroyed. It does not describe the returned payload shape or failure modes when the project cannot be diagnosed, keeping it below 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose is front-loaded in the first clause, and the em-dash content list is dense information an agent needs rather than filler. The single very long sentence with a nested comma list makes it slightly harder to scan, but nothing is redundant.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description carries the burden of explaining what comes back, and it does: file creation gated by overwrite, content-only return under dryRun. Combined with the itemized document contents and language options, an agent has enough to call it correctly. The one gap is that the success return value (written path versus raw content) is only implied.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents lang, dryRun, fileName, overwrite and projectDir. The description only restates the overwrite and dryRun semantics and notes the Korean default/English option, adding no format or constraint detail (e.g. absolute-path expectation, filename pattern) beyond the schema. Baseline 3 applies.

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

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

The description names a specific verb (진단해 ... 생성합니다) and a concrete artifact (AGENTS.md for Claude Code/Copilot/Cursor), then enumerates exactly what the document will contain. That is far beyond a tautology. It stops short of 5 because the '프로젝트를 진단해' framing overlaps with the sibling diagnose_egovframe_project, and the description never states how this differs from that tool's diagnostic output.

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

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

It gives clear conditional usage rules: an existing file is refused unless overwrite=true, and dryRun=true returns content without writing — both are explicit when/when-not cues an agent can act on. It does not name any alternative tool (e.g. generate_egovframe_report or generate_egovframe_config) or say when to skip this one entirely, so it falls 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.

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

Goes well beyond the annotations (readOnly=false, destructive=false, idempotent=false): it discloses that existing files are refused rather than overwritten, that Maven builds retry up to 3 times with -U only on 5xx/connection drops, and that gate failures produce artifacts and a PR grade. These are exactly the side-effect nuances the hints cannot convey.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose is front-loaded and no sentence is pure filler, but the body is a single dense paragraph packing supply-chain, mirror, retry, dryRun and delivery branches together. It would read faster as short labeled clauses; as-is it demands re-reading.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 13-parameter mutating tool with no output schema, the description covers conditional interactions (delivery requires supplyChain), failure semantics, environment-variable plumbing, and overwrite refusal. An agent has enough to invoke it correctly in every mode.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so parameters are already documented; the description largely restates them. It does add a little meaning (npmRegistry/offlineBundle are injected as environment variables, mavenMirror applies only to Maven builds), but this duplicates what the schema descriptions already state.

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

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

Opens with a specific verb+resource ('프로젝트에 CI 설정을 생성합니다') and immediately enumerates the concrete artifacts per platform (.github/workflows/egovframe-ci.yml, .gitlab-ci.yml, Jenkinsfile). An agent can distinguish this from generate_egovframe_deploy or generate_egovframe_config without inspecting the schema.

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

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

Gives clear conditional guidance: dryRun to preview, supplyChain=true to add the gate, delivery=true requires supplyChain. However, it never names an alternative sibling (e.g. when to prefer generate_egovframe_deploy for delivery vs. the delivery=true flag here), so routing is inferred rather than explicit.

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

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

Annotations only declare write-side flags (readOnly=false, destructive=false, idempotent=false, openWorld=false); the description adds the facts that matter: existing files are not overwritten but rejected, unknown fields are refused, defaults mirror the Initializr web form, and dryRun returns content/path/context without touching disk. That is non-obvious behavior an agent could not infer from the annotations or schema alone.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose and the 21-template scope are front-loaded in the first clause, followed by formats, defaults, and the overwrite policy. The long inline enumeration of template categories is partly redundant with the configId enum, costing some density, but the paragraph is otherwise free of filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a high-complexity tool (21 templates, free-form nested `fields`, four format modes) the description closes the biggest gap by pointing to egovframe://catalog/config-templates and the dryRun context output for discovering per-template variables. With no output schema, the non-dryRun return value (written path, any file list) is left unspecified, which is the remaining hole.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, and the description largely restates what the schema already documents (format availability for yaml/properties limited to logging, default fileName/outputDir behavior, dryRun semantics, field rejection). The genuine additions are the pointer to the catalog resource for per-template field names and the note that omission means Initializr defaults, so it sits just above the baseline.

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

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

States a specific verb (생성) and resource (Spring 설정 파일) and bounds the scope precisely: 21 official Initializr templates, enumerated by category (datasource, transaction, cache, logging, scheduling, idGeneration, property). An agent can immediately tell this apart from siblings like create_egovframe_project or add_egovframe_components, which operate on project/component structure rather than config files.

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

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

Gives clear operating context: omitted fields fall back to Initializr web-form defaults, and an existing file causes a refusal rather than an overwrite. It also routes the agent to egovframe://catalog/config-templates or a dryRun 'context' result for template-specific fields. It stops short of naming an alternative tool or stating explicit when-not-to-use conditions beyond the overwrite case.

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

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

The standout disclosure is the all-or-nothing conflict pre-check: if any target file exists, nothing is written. That is genuinely non-obvious safety behavior beyond the annotations. It does not address idempotency (annotation says idempotentHint=false) or what happens on partial failures, so it stops short of full behavioral disclosure.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose is front-loaded correctly, but the body reads as a changelog with 'v1.4:'/'v1.8:' prefixes and repeated restatement of schema descriptions (paging, dialect). Several clauses, especially the nested parenthetical about commas and the 'primary key' string, are hard to parse and partly duplicate parameter docs.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 27-parameter generator with no output schema, the description covers what files are produced, profile differences, paging/search feature activation and the conflict-abort contract. The notable gap is that it never describes the return value (file manifest vs dryRun plan), which matters given there is no output schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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 semantics: ddl parsing rules (COMMENT/DEFAULT commas, the 'primary key' string trap), dialect-neutral LIKE with bind and escaping for search, and per-dialect paging strategies plus the dialect-resolution fallback chain. That is value beyond the parameter list itself.

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

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

First sentence names a concrete verb (생성합니다) and enumerates the exact artifacts produced (VO, Mapper XML, Service, Controller, JSP, JUnit 5 skeleton) against a named standard (eGovFrame official CRUD wizard input). This is far more specific than any sibling generator (generate_egovframe_config, generate_egovframe_ci, create_egovframe_project), so an agent can route on purpose alone.

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

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

It establishes when this applies (CRUD scaffolding for classic vs boot profiles) and implies the required starting conditions, but never explicitly names an alternative sibling or states when-not-to-use. The ddl-vs-fields mutual exclusion is documented in the schema, not the description, so routing guidance is clear but not exhaustive.

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

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

Goes well beyond the annotations: dryRun is on by default so nothing is written, existing files are refused rather than overwritten, unsupported projects return a reason instead of failing silently, and multi-module mode rewrites localhost references to service names. All of this is consistent with destructiveHint=false and readOnlyHint=false, so there is no contradiction.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Virtually all content is useful, but it is delivered as one dense wall of text with deeply nested parentheses, so the multi-module paragraph and the refusal conditions are hard to locate. It would benefit from splitting into purpose / artifacts / edge cases sections.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 12-parameter generator with an output schema, the description covers scope, artifact set, DB configuration strategy, air-gapped behavior, dry-run safety, refusal cases, and multi-module semantics — everything needed to invoke it correctly. Return-value details are correctly left to the output schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is already 100%, so the baseline is 3, but the description adds real meaning: imageRegistry feeds the Dockerfile ARG BASE_REGISTRY for air-gapped registries, buildInImage switches between multi-stage build and pre-built artifacts, and modules pulls in required dependency services automatically. Only some parameters (format, appName, jdk, ingressHost) are left entirely to the schema.

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

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

States a specific verb (생성) and resource (컨테이너·배포 산출물) and then enumerates the exact artifacts produced: Dockerfile, .dockerignore, deploy/docker-compose.yml, deploy/k8s/<app>.yaml. An agent can distinguish this from generate_egovframe_ci or prepare_egovframe_delivery without opening any schema.

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

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

Gives clear conditional guidance: use buildInImage=false when the container cannot reach Maven in an air-gapped network, use imageRegistry for internal registries, use modules to select a subset of services, and it explains what happens for multi-module/library-jar/no-build-file projects. It never names a sibling tool or an explicit when-not-to-use, so it stops short of a 5.

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

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

Goes well beyond the annotations: it specifies that outputPath writes only a new file, refuses existing files, and is transactional, while otherwise leaving the disk untouched — the exact write semantics an agent needs for a tool with readOnlyHint=false and destructiveHint=false. It also discloses when network and build-tool/repo access are required (offline=false, resolve=true) and that no cost estimates are produced.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose is front-loaded in the first clause and every following parenthetical carries substantive information given a complex 11-parameter, multi-section tool. It is dense to the point of being a single long block, which slightly hurts scannability, but little text is wasted.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given an output schema exists, the description needn't explain return values, and it covers section content, persistence semantics, and network/offline implications thoroughly. The remaining gap is operational sequencing — whether cheap diagnostics should precede an assessment run — which it leaves implicit.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3, but the description adds real meaning: it defines what the assessment sections (1)–(6) contain, that format=json carries assessment data, that resolve=true pulls in transitive dependencies, that offline=false triggers OSV lookups, and that a missing sbomPath renders as '없음' without generating one. It stops short of explaining topN and resolveTimeoutMs, which the schema already covers.

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

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

States a specific verb and artifact (프로젝트 리포트를 Markdown/json으로 생성) and enumerates exactly what each section contains, so an agent knows the tool produces a report rather than performing diagnosis. It does not, however, name neighboring report-producing tools (e.g. generate_egovframe_sbom, prepare_egovframe_delivery) to disambiguate.

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

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

Explains the components-vs-assessment choice through the `sections` parameter and notes the scope limit (비용·공수는 산정하지 않습니다), which implies when the tool is and isn't appropriate. There is no explicit statement of prerequisites (e.g. run diagnose/migrate first) or of which sibling tool to use instead when the agent only wants raw diagnostics.

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

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.

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.

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.

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.

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.

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.

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds that multiple matching documents come back as a list, which is real behavioral value given there is no output schema, but it says nothing about what the response content looks like (full text vs. links) or what happens when no doc exists.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences with no filler, the fetch action front-loaded and the multi-document behavior second. Every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple two-parameter read tool with full annotation coverage and no output schema, this is nearly complete: it names the source (egovframe-docs portal) and explains multi-result handling. Only the shape of the returned guide content is left unstated.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% — both `component` (with the concrete id example 'bbs, login, cop.cmy') and `docIndex` (0-based, default 0) are already documented in the schema. The description's note about docIndex only restates that, so the baseline 3 applies.

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

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

States a specific verb and resource: fetches the official guide document for a component from the egovframe-docs portal. The scope is clear, but it never distinguishes itself from siblings like search_egovframe_docs or explain_egovframe_component, so an agent must infer the boundary.

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

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

Usage is implied — look up docs for a given component id — but there is no explicit 'use this when... / instead use X when...' guidance, despite several plausible alternatives (search_egovframe_docs, explain_egovframe_component, list_egovframe_components) in the sibling set.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false and destructiveHint=false, so the safety profile is fully covered. The description adds provenance context (auto-generated from a repo scan via scripts/generate-catalog.mjs), which hints the data is derived rather than authored, but says nothing about return shape, freshness guarantees, or catalog size.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single front-loaded sentence stating the resource first, with the implementation note parenthetical trailing. Efficient, though the internal script path is of marginal value to an agent selecting the tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-param list tool with no output schema, the description should ideally indicate what a catalog entry contains (component identifiers, installable flags), since the agent must act on the result. It leaves that entirely unspecified, so it is adequate but with a clear gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline of 4 applies. No misleading parameter claims are made.

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

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

States a specific verb (반환합니다) and resource (공통컴포넌트 카탈로그), with the qualifier '선택 설치를 지원하는' scoping it to installable components. This loosely differentiates it from siblings like search_egovframe_components or list_egovframe_templates, though it never names an alternative explicitly.

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

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

The description gives no when-to-use guidance and no comparison against alternatives such as search_egovframe_components or list_egovframe_templates. A listing tool's usage is somewhat implied, but nothing is stated about when this catalog is the right call.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description adds that the catalog is curated and that entries are template+component bundles, but says nothing about ordering, size, or return shape. With annotations carrying safety, a 3 reflects modest added value.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences with zero padding. The identity of the resource is front-loaded and the actionable follow-up is placed second, which is the right priority order.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema and no parameters, so the description must carry the burden of conveying what come back — it does so at a high level by defining recipes as template+component bundles. It could say more about the fields of each entry, but for a no-arg listing tool this is complete enough.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters and the schema is empty, so there are no parameter semantics to document. Baseline 4 applies; nothing in the description misrepresents or omits parameters.

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

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

States a specific verb and resource ('curated recipes list') and, crucially, defines what a recipe is — a template+component bundle — which implicitly distinguishes it from sibling list_egovframe_templates and list_egovframe_components. It stops short of naming those siblings explicitly, so it lands at 4 rather than 5.

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

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

Gives a clear next-step routing hint: recipes can be assembled in one shot with apply_egovframe_recipe, establishing the list→apply workflow. It does not state when to prefer this list over list_egovframe_templates or list_egovframe_components, so it is clear context without exclusions.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and closed-world scope, so the safety profile is fully covered. The description contributes nothing beyond them — no mention of return shape, catalog freshness, or whether a sync is required first — so it adds no behavioral value on top of the structured data.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single front-loaded sentence with no filler, appropriate for a trivial zero-argument lister. It is efficient rather than padded, though it is arguably under-specified rather than deliberately tight.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a no-parameter, read-only listing tool with full annotation coverage, one sentence is minimally adequate. However, with no output schema the description could usefully say what a template entry contains or how the result feeds create_egovframe_project, and it omits that.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters, so per the rubric this is a baseline 4. There are no arguments whose meaning the description could clarify or fail to clarify.

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

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

States a specific verb ('반환합니다') and resource ('전자정부 표준프레임워크 프로젝트 템플릿 목록'), making the operation unambiguous. It does not, however, differentiate itself from nearby siblings such as sync_egovframe_templates or list_egovframe_components, so an agent must infer the distinction.

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

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

The description gives no when-to-use guidance, no prerequisites, and never mentions alternatives like sync_egovframe_templates or search_egovframe_docs. Usage is only implied by the verb 'list'.

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

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

Far beyond the destructiveHint=true/idempotentHint=false annotations: it discloses that auto items are rewritten in a single transaction, originals are archived to migration-backup/<시각>/, migration-plan.json is emitted, and a mid-failure rolls back to the pre-work state. It also states the safety boundary that manual items are never touched and survive into the result. That is exactly the destruction/atomicity/rollback detail an agent needs before authorizing a write.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded on the conversion path, but the entire update-mode branch (target=5.y.z, 5.1.0 provenance, update-rules.json, update-plan.json) is crammed into one trailing run-on clause separated by a colon and dashes. Much of it restates what the 100%-covered schema already documents, and the density makes skimming harder than necessary.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given an output schema exists and parameter coverage is complete, the description need not explain return shapes — and it still supplies the reasoning an agent needs: three-phase model, rule catalog provenance (catalog/migration-rules.json), the auto/manual classification, and the common-component reassembly recommendation. Nothing material is missing for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so 3 is the baseline, and the prose genuinely raises it: apply/dryRun/verify interplay, target's dual meaning (5.x = 전환 vs 5.y.z = 갱신), and skipComponents excluding common-component dirs are all explained with consequences rather than definitions. It loses a point for an internal inconsistency — the description says verify runs compile '적용 뒤' (after applying) while the schema says verify is not combined with apply — leaving the agent unsure of the legal combination.

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

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

States a concrete verb pair (진단 + 치환/적용) on a concrete resource (3.x/4.x → 5.x 프로젝트) and enumerates exactly which artifacts it rewrites (RTE 좌표, 패키지, javax→jakarta, web.xml 스키마, XML 네임스페이스). An agent knows precisely what the tool does. What it does not do is distinguish itself from near-neighbours such as upgrade_egovframe_project or rehearse_egovframe_migration, which the crowded sibling list makes a real ambiguity risk.

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

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

Explicitly lays out the internal decision tree: apply=false is diagnosis-only, apply=true + dryRun=true is preview, dryRun=false performs the write, verify=true adds the compile stage, and target=5.y.z switches to update mode. That is unusually clear gating. It stops short of a 5 because it never says when to prefer this over rehearse_egovframe_migration (dry rehearsal) or upgrade_egovframe_project.

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

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

Goes well beyond the annotations (readOnly=false, openWorld=true, non-idempotent, non-destructive): discloses container lifecycle, that existing files are never overwritten (rejects on differing content), charset/collation handling, and verification steps (table count, required rows, Korean round-trip). The container deletion is the tool's own scratch resource, not an annotation contradiction with destructiveHint=false, but that nuance is left implicit.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with purpose and source-selection priority, then detail. It is dense and long, with some very low-level charset internals that exceed selection needs, but nearly every clause carries actionable invocation information rather than filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For an 11-parameter mutation tool with an output schema, the description covers source selection, transformation logic, outputs, container behavior, safety constraints, and exclusions—everything an agent needs to invoke correctly. Return values are covered by the output schema, so no gap remains.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 100% schema coverage the baseline is 3, and the prose meaningfully contextualizes several key params—run, keep, dryRun, scripts, offline, includeComments, database—their interaction and defaults. It does not add much for timeoutMs, imageRegistry, or format, relying on the schema there.

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

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

States a specific verb (prepare DB scripts) and resource (DB schema/data scripts for common components/project), and clearly distinguishes it as a DB-preparation tool rather than project scaffolding or migration. An agent can tell what it does without opening the schema.

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

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

Explains invocation modes explicitly: default dryRun writes nothing, run=true spins Docker and verifies then tears down, keep=true retains the container, and 'scripts' overrides automatic source selection. It also gives an explicit exclusion ('운영 DB 적재·스키마 이관은 하지 않습니다'), routing production-DB work elsewhere.

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

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.

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.

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.

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.

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.

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.

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

Beyond the annotations it discloses the write-target constraint (only new/empty directories), that every file is sha256-fingerprinted and recorded with source URL and fetch time in bundle-manifest.json, that OSV lookups fall back to the local dump with a snapshot date and a 30-day staleness warning, and that Maven jars are deliberately omitted. These details explain why the tool is non-idempotent and non-destructive, which the annotations alone do not.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose is front-loaded correctly, but the second half drifts into the behavior of other tools on the closed-network side (download verification, offline OSV resolution, reassembly using the bundle mirror). That context is relevant but makes a single dense run-on paragraph that is harder to scan than the core setup instructions warrant.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a network-dependent, file-writing tool with five parameters, an output schema, and full annotations, the description covers everything an agent needs: preconditions on outputDir, default dry-run safety, network requirements, bundle contents, manifest format, and explicit exclusions. Return structure is handled by the output schema, so nothing material is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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 goes further by framing dryRun as a preview of the fetch list and by naming the four include categories in prose while clarifying that only fixed-fingerprint templates are packed by default. Only 'format' is left entirely to the schema, which is acceptable given its explicit description there.

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

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

The description opens with a specific verb and artifact: build an offline bundle for air-gapped development environments on an internet-connected PC. It enumerates the bundle's exact contents (OSV vulnerability dump, pinned component archive with sha256, Initializr zip templates, origin tag mirror, bundle-manifest.json) and explicitly excludes Maven jars. It does not name any sibling tool, so the boundary with prepare_egovframe_delivery or reassemble_egovframe_components must be inferred.

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

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

It states the precondition clearly ('새(또는 빈) 디렉터리에만 쓰며') and that dryRun defaults to listing what would be fetched, giving the agent a safe first step. It also explains the downstream scenario (setting EGOVFRAME_OFFLINE_BUNDLE on the closed-network PC). It never names an alternative tool or says when a sibling should be used instead.

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

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

Goes well beyond the annotations: discloses that dryRun=false writes in one transaction with archive sha256 verification, deletes originals absent from 5.x after backup, replaces user-modified sources while preserving unified-diff patches, keeps user config/asset files, records a manifest consumed by upgrade/validate/remove, and states patches are NOT auto-reapplied. It also names operational prerequisites (git required, EGOVFRAME_CACHE_DIR default) and artifact locations, consistent with destructiveHint=true and idempotentHint=false.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the core action and pinned version, then numbered steps that map to the execution order. It is long and uses heavily nested Korean clauses, which costs readability, but essentially every sentence carries distinct operational information (backup paths, patch policy, git/cache requirements).

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive, open-world migration tool the description covers the full lifecycle: input detection, per-file classification outcomes, transactional write behavior, backup/artifact layout, returned task list, and downstream tool effects. With an output schema present, no return-value explanation is owed, and nothing an agent needs to call this safely is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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 behavior the schema cannot: sourceTag can be auto-detected by git blob-id comparison without downloading file contents, dryRun=false means transaction apply, and verify=true runs compile and appends errors to the task list. The components, database, and format parameters are left to the schema, which is acceptable at full coverage.

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

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

States a specific verb (reassemble) and resource (egovframe common components copied into a 3.x/4.x project) pinned to a catalog version (v5.0.7), and outlines the identify/classify/apply pipeline. It is clear what the tool does, but it never names the sibling it should be chosen over (upgrade_egovframe_project, add_egovframe_components), so the agent must infer the boundary.

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

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

The target situation is implied ('3.x/4.x 또는 이전 5.x 프로젝트에 복사돼 있는 공통컴포넌트 소스') and dryRun=true default gives a safe first step. However there is no explicit when-to-use vs when-not, and no routing against upgrade_egovframe_project or rehearse_egovframe_migration, which are the nearest alternatives.

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

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

With annotations declaring readOnlyHint=false and destructiveHint=false, the description goes well past that bar: it discloses the copy location and exclusion set (build artifacts, VCS, backups), the fixed stage ordering and why (reassemble before migrate to preserve original tag identification), the javac fork with -Xmaxerrs removing the 100-error cap, the directory-fingerprint check proving the original is unchanged, and that results surface in section 6 of the report.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The scope guarantee is front-loaded in the first clause, followed by the numbered stage sequence, then the return values. It is one dense paragraph but nearly every sentence carries distinct information; only the return-value enumeration is partly redundant with the output schema.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a multi-stage, mutating (on a copy) tool with 8 parameters, the description covers intent, stage semantics, side effects, safety verification, output contents and workspace retention. An output schema exists, so the extra return-value prose is surplus rather than a gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% for all 8 parameters, so the baseline is 3. The description adds a little meaning — the ordering rationale behind the steps list and the fact that keepWorkspace leaves a copy behind — but most parameter semantics are already carried by the schema.

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

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

The description states a specific verb and resource — 'rehearse the 5.x migration on a copy without touching the project' — and enumerates the four concrete stages it performs (reassemble, migrate, compile, align-pom, recompile). It does not name the sibling tools it substitutes for (migrate_egovframe_project / upgrade_egovframe_project), so the differentiation from siblings is implicit rather than explicit.

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

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

'프로젝트를 건드리지 않고 사본에서 미리 돌려 봅니다' implies when to use it — a safe preview before committing to a real migration — and the keepWorkspace note hints at follow-on inspection. However, no alternative tool is named and there is no explicit 'use this instead of X when Y' rule, so selection is left to inference.

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

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

Annotations only say destructiveHint=true; the description goes far beyond, disclosing that only manifest-recorded files are deleted, that dependency-shared and hash-mismatched files are refused by default, that force backs up to remove-backup/ before transactional removal, and that a dryRun preview exists. This is exactly the pre-mutation context an agent needs.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three compact sentences, front-loaded with what is removed, then the safety gate, then the escape hatch. No filler and no repetition of the schema.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive, non-idempotent mutation with no output schema, the description covers scope, refusal conditions, backup location, transactionality, and preview mode. What happens to the project afterwards is inferable; nothing needed to call it safely is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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 still adds value by explaining force as backup-then-transactional-remove and dryRun as a preview, and by introducing the install-time hash validation concept that the schema fields only hint at.

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

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

States a specific verb (제거) and resource (add_egovframe_components로 조립한 컴포넌트), and explicitly names the inverse sibling in the first sentence. An agent can distinguish this from add/reassemble tools without inspecting schemas.

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

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

Ties usage to the counterpart tool (add_egovframe_components) and spells out the default refusal conditions, which tells the agent when the call will be rejected. It does not, however, say when to prefer this over reassemble_egovframe_components or when force should be considered acceptable, leaving a sibling-selection gap.

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

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

The description goes beyond the safety hints provided in the annotations by disclosing critical operational behaviors. Specifically, it reveals that the search performs partial matching across the ID, name, description, and category fields, which is vital behavioral context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The definition is a single, highly efficient sentence. It front-loads the core function and immediately provides the crucial operational constraints (what it matches and how many results are returned), leaving no superfluous words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given that this is a search tool, the description is complete. It defines the resource being searched (components), the input type (keyword), and the output constraints (partial match, top 10). No major context is missing for an agent to use it effectively.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

While the schema defines `query` as a simple string, the description clarifies its semantics—it is used for partial matching across four different attributes (id, name, description, category). This context dramatically enhances the utility of the parameter definition.

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

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

The description clearly identifies the tool's purpose: searching common components by keyword. It distinguishes this from listing tools by detailing the scope (Top 10) and matching criteria.

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

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

The description dictates exactly how the tool operates (partial match on four fields, limited results). This operational clarity helps the agent choose this tool when the user expects a specific, filtered result rather than an exhaustive search, making it highly practical.

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

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

Annotations already declare readOnly/idempotent/non-destructive/openWorld, so the safety profile is covered. The description still earns credit by disclosing the mode switch: default is offline index only, while fetchTop>0 triggers an actual network fetch of document bodies to build snippets — a meaningful nuance on openWorldHint that the annotations do not convey.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two tightly packed sentences with zero filler: the resource and search source come first, then the default behavior and the fetchTop deviation. Every clause carries information an agent needs.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists, and the description compensates reasonably by describing result ordering and the presence of snippets when fetchTop>0. It stops short of sketching the returned fields (title, path, category, score) or noting result-count/pagination behavior, which would fully close the gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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 goes beyond the schema by explaining the ranking dimensions (title, path, linked component, category) and by framing fetchTop as the toggle between offline-only results and body-composed snippets. It does not explain limit behavior or ordering interaction between limit and fetchTop.

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

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

States a specific verb and resource: keyword search over the official egovframe-docs guide index, and clarifies what is being searched (the index, not the documents themselves). It does not name or distinguish itself from the closest sibling, get_egovframe_guide (which presumably reads a document body), so an agent must infer the search-vs-read split.

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

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

Usage is only implied: this is the tool to reach for when locating guides by keyword. The description explains the two operating modes (offline index by default vs. fetchTop>0 pulling bodies) but gives no explicit routing against get_egovframe_guide or explain_egovframe_component, and no when-not-to-use condition.

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

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

Annotations already declare readOnlyHint/openWorldHint/idempotentHint, so safety is covered; the description adds substantive scope detail beyond them — that it validates tag/commit/archive integrity of an official upstream source and also inspects the sec.security package. It does not describe what artifacts or findings come back, which keeps it below a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

One front-loaded sentence covering three checks, with no filler. It is dense but every clause (integrity verification, upstream diff, security package) adds distinct information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a read-only, one-optional-parameter tool with full schema coverage and no output schema, the description covers scope, source of truth, and default behavior adequately. What is missing is the form of the returned findings and any mention of network/prerequisite requirements for the upstream comparison.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the single optional 'ref' parameter is already documented in the schema, including the default of the pinned tag. The description reinforces the default behavior (고정 카탈로그 대비) but adds no syntax or format detail beyond the schema, so baseline 3 applies.

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

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

The description uses a concrete verb (검증하고/점검합니다) and a precisely named resource (공식 egovframe-common-components 태그·commit·아카이브) rather than a restatement of the name. It clarifies that the tool works against a pinned catalog comparison and sec.security package, which separates it from catalog-listing and template-sync siblings, though it never names those siblings.

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

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

No explicit guidance on when to use this versus the siblings like sync_egovframe_templates or list_egovframe_components, and no exclusion of scenarios (e.g., pre-upgrade checks vs. routine validation). Usage is only inferable from the purpose statement, and the 'sync' name could mislead against sync_egovframe_templates.

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

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

Annotations already declare readOnly/idempotent/non-destructive, and '파일은 고치지 않습니다' echoes that but the description goes further by enumerating the report categories — added/deleted/changed entries, MCP coverage gaps, new eGovFrame runtime/공통컴포넌트 tags, new parent versions, pom sha256 changes. That tells the agent exactly what evidence the report carries, which annotations alone would not. It does not say whether a network fetch is required, though openWorldHint implies it.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single very long sentence packing two comparisons and three parenthetical drift categories. The core action is front-loaded, but the density of parenthetical lists makes it harder to scan than two or three shorter sentences would be.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description does a fair job naming what the report contains, but it omits the two things an agent most needs: how this differs from sync_egovframe_catalog, and the shape/section layout of the report (or whether it is textual vs structured).

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Only one optional parameter (ref) and schema description coverage is 100%, so the schema already explains that an unspecified ref falls back to the pinned catalog branch. The description adds no additional semantics about ref, so baseline 3 applies.

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

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

States a concrete verb and resource: reconcile the official template catalog (Initializr/MCP/Development) against upstream and report adds/removals/changes plus MCP coverage gaps and drift in the 5.x rule/dependency catalog. Very specific about what is compared and what is reported, but it never distinguishes itself from the sibling 'sync_egovframe_catalog', whose name and purpose read almost identically.

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

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

Usage is implied (use when you want to know whether the pinned catalog has drifted from upstream) but there is no explicit when-to-use, no exclusion, and critically no routing guidance versus sync_egovframe_catalog or list_egovframe_templates. The agent is left to infer which sync tool to pick.

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

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.

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.

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.

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.

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.

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.

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

Adds real behavior beyond the annotations: writes are preceded by a backup into upgrade-backup/, user-modified files are preserved unless force, dryRun touches no disk, and hard conflicts are rejected atomically with nothing written. These align with destructiveHint=true and openWorldHint=true and fill in the safety/reversibility story the annotations only flag.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Four short sentences, each carrying distinct load: purpose, force/preservation rule, dryRun-first workflow with backup location, and atomic refusal on hard conflict. The safety-critical default (dryRun) is surfaced early and nothing is repeated from the schema.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Annotations already cover the destructive/open-world/idempotency profile and there is no output schema, so the description carries only the behavioral burden, which it does well. The main gap is what the dryRun plan actually reports back, which matters for the recommended preview-first workflow.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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 behavioral meaning to the two risky flags: force governs overwriting user-edited files after backup, and dryRun is the default plan-only mode. It does not clarify the components id format or how an unspecified list resolves beyond the schema's note.

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

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

Specific verb (갱신/upgrade) plus specific resource scope: components installed and recorded in the manifest, compared against upstream latest. That scoping alone separates it from add_egovframe_components (new installs), reassemble_egovframe_components, and migrate_egovframe_project, so an agent can route without opening the schema.

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

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

Gives a clear operating context: dryRun is the default so a plan is inspected first, force is required to touch user-modified files, and hard conflicts abort. It never names sibling alternatives or explicit when-not conditions (e.g., use add_egovframe_components for new components, migrate for a target-version jump), so it falls short of a 5.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and closed-world, so the safety profile is settled. The description adds genuine value by naming exactly what is cross-checked (manifest vs. files, DbType vs. DB script), though it doesn't state how failures are surfaced (there is an output schema, which mitigates this).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

One front-loaded sentence with the two concrete checks after the colon; no filler. Slightly dense but every clause earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With rich annotations, 100% parameter coverage and an output schema, the description supplies the remaining piece—the specific integrity checks performed. The notable gap is disambiguation from diagnose_egovframe_project in a crowded family of check_/diagnose_ siblings.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Single parameter with 100% schema description coverage ('검증할 프로젝트 디렉터리'), so the schema carries the semantics. The description adds nothing about the parameter (e.g., whether it must contain a previously assembled layout), which is the expected baseline-3 case.

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

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

States a concrete verb+resource ('조립된 프로젝트의 무결성을 진단') and enumerates the two specific checks (manifest-based file existence, Globals.DbType vs. copied DB script), which is far from a tautology. However, it does not differentiate itself from the similarly-scoped sibling diagnose_egovframe_project, so the agent cannot tell why one is preferred over the other.

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

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

The phrase '조립된 프로젝트' implies this tool applies after project assembly, giving implicit lifecycle guidance. There is no explicit when-to-use / when-not statement and no reference to diagnose_egovframe_project, check_egovframe_dependencies, or check_egovframe_sbom as alternatives, so usage must be inferred.

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