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

No annotations are provided, so the description carries full burden. It discloses key behaviors: copies sources/config/UI/infra, inserts dependencies, creates backup, refuses on conflict, and supports dryRun preview. It does not detail side effects like modification of existing files despite backup, but overall it is transparent.

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 a single paragraph in Korean, about three sentences. It is concise and packs essential information without redundancy, though it could be slightly restructured for readability.

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 7 parameters, no output schema, and no annotations, the description covers core functionality, conflict handling, dryRun, and stack details. It does not cover error handling or success indications, but it is sufficiently complete for an AI agent to decide selection and 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 description coverage is 100%, so baseline is 3. The description adds context beyond schema: it explains the purpose of stack choices (spring-ai vs langchain4j with backends) and details dryRun behavior. This adds meaning beyond the parameter 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?

The description clearly states the tool adds an AI RAG chatbot based on the egovframe-ai-rag sample to an existing Boot project. It specifies the actions (copy sources, config, UI, infra) and distinguishes from sibling tools like remove_egovframe_components or add_egovframe_components.

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 indicates usage for adding an AI chatbot to a Boot project, mentions safe mode (dryRun), conflict behavior, and stack choices with mutual exclusivity. However, it does not explicitly state when not to use or provide alternatives, though the sibling list implies different purposes.

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 no annotations provided, the description carries full burden. It discloses that it copies source/mapper/JSP plus DB scripts if database specified, refuses to write on file conflicts, and supports a preview mode. This provides good behavioral context, though it could mention any irreversible actions or prerequisite the project exists (implied by projectDir).

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 highly concise: four sentences covering main action, dependency handling, conflict behavior, and dry run. Each sentence serves a distinct purpose with no redundancy.

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 all 5 parameters are described in the schema and no output schema exists, the description provides sufficient context for the tool's operation (copy behavior, conflict handling, preview). It could mention what happens after success (e.g., no return value) but overall complete for this tool.

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 description adds little beyond what the schema already provides. The description redundantly mentions dryRun and database parameters but does not enrich understanding of the component IDs listing or includeDependencies behavior 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 clearly states the tool's purpose: selecting and assembling common components (EgovFrame) into an existing project, copying source files, mappers, JSPs, and optionally DB scripts. It distinguishes from sibling tools like add_ai_components by specifying the EgovFrame context.

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 mentions a dry run option ('dryRun=true로 먼저 미리볼 수 있습니다'), offering usage advice but does not explicitly contrast with alternative tools or provide when-to-use/when-not-to-use guidance. Usage is implied 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?

No annotations provided, so description carries full burden. Mentions sequential execution and dryRun behavior. Does not disclose potential side effects like file overwriting, permissions required, or whether it modifies existing projects. Some behavioral context but missing important details.

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 concise sentences with front-loaded main action. No redundant words. Every sentence provides essential information: what the tool does and how to preview the plan.

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, so description need not explain return values. However, it does not describe what happens after execution (e.g., output files, logs, success/failure indication). Missing prerequisites or dependency info. Adequate but could be more complete.

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% with descriptions for all 6 parameters. The tool description adds no additional meaning beyond what the schema already provides. dryRun behavior is mentioned in both, so description adds minimal value.

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?

Description clearly states it selects a recipe, generates a project, and assembles common components (with optional AI components) sequentially. The verb '실행합니다' and resource '레시피' are specific. Distinguishes from siblings like create_egovframe_project (project creation alone) and add_egovframe_components (component addition separately).

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?

Describes dryRun=true for previewing the plan. Implies this tool combines project creation and component assembly, but does not explicitly state when to use vs. alternatives like creating a project first then adding components. Provides clear usage context but lacks 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?

No annotations provided; description notes dryRun for preview but lacks details on potential destructive behavior (e.g., overwriting existing directories), required permissions, or error handling.

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 concise sentences, front-loaded with purpose, no unnecessary 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?

Briefly covers purpose and a key flag (dryRun) but omits output/return value description (no output schema). Given 7 parameters, schema already details them; additional behavioral or success criteria would improve completeness.

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%; description adds minimal extra context beyond schema (e.g., 'official GitHub template'). DryRun hint already present in 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?

Description clearly states it creates a new project skeleton from official eGovFrame template with specified settings. However, it does not explicitly differentiate from sibling tools like add_egovframe_components or 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?

Only mentions using dryRun=true for preview. No guidance on when to use this tool versus alternatives, prerequisites, or when not to use it.

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 explicitly states '디스크를 변경하지 않는 읽기 전용입니다' (read-only, does not change disk), providing clear behavioral transparency. Since no annotations are provided, the description carries full burden; the read-only nature is well communicated, though no other behavioral traits (e.g., permissions) are mentioned.

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 a single Korean sentence that concisely covers the tool's purpose and key aspects. It is front-loaded with the main action. Slightly longer due to listing diagnostic items, but remains efficient.

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?

The description provides a good overview of what the tool checks (build system, version, DB type, common components, configuration issues) and its read-only nature. However, it does not describe the output format or return values, which would be helpful given 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 description coverage is 100% (only one parameter), and the schema already describes 'projectDir' as the directory to diagnose (recommended absolute path). The description adds no additional parameter information beyond what the schema provides, 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?

Descriptiom clearly states the tool scans existing eGovFrame projects to diagnose build system, RTE version, DbType, common components, and configuration issues. It uses a specific verb ('diagnose') and resource, distinguishing it from siblings like 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?

The description implies usage for diagnosing existing projects (including non-scaffolding) and notes it is read-only, but it does not provide explicit guidance on when to use this tool versus alternatives or when not to use it.

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 no annotations, the description disclosure that the tool is read-only ('읽기 전용') and lists all return elements. This gives clear behavioral context. It does not mention potential failure modes or permissions, but for a simple read tool this is adequate.

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 a single sentence that efficiently packs all key details. While it uses parentheses for a list, it remains clear and front-loaded. No unnecessary words, though the list could be formatted more cleanly.

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?

The tool has low complexity (one parameter, no output schema). The description explains what the return value contains, which is sufficient for the agent to understand the output. It could mention that the component must exist, but the example mitigates this.

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 schema has 100% coverage with a description for the id parameter. The description adds an example ('예: bbs'), which is helpful but does not provide additional meaning beyond what the schema already states. Baseline score 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?

The description clearly states that the tool returns detailed information about a single common component, listing specifics like description, dependencies, tables, guide links, and installation commands. It uses a specific verb and resource, and the name 'explain' distinguishes it from siblings that list, search, or add components.

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 usage when you need full details of one component, but it does not explicitly state when to use this tool versus alternatives like list_egovframe_components or get_egovframe_guide. No exclusions or prerequisites are mentioned.

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?

No annotations are provided, so the description carries the burden. It discloses that dryRun previews content without creation and that actual generation refuses to overwrite existing files. These are key behavioral traits. However, it does not mention error handling for missing build tools or other edge 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?

Two sentences, zero waste. First sentence states the core purpose, second adds key behaviors (detection, dryRun, non-overwrite). Information is front-loaded and efficient.

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, so description should clarify return values. It states dryRun returns content, but not what normal creation returns (e.g., success message or file path). Missing this detail reduces completeness for an 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%, baseline 3. The description adds context: dryRun behavior, absolute path recommendation for projectDir, and default JDK version. This adds marginal value beyond schema but does not deepen parameter semantics significantly.

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 states it generates a GitHub Actions CI workflow (build/test) for a project. It specifies automatic detection of build tools (maven/gradle) and JDK specification, distinguishing it from sibling tools like create_egovframe_project or add_ai_components.

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 usage for CI workflow generation but does not explicitly state when to use this tool versus alternatives. It mentions dryRun and overwrite prevention but lacks context on prerequisites (e.g., existing build tool) or when not to use.

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 no annotations provided, the description carries the full burden. It discloses an important safety behavior (pre-checks file conflicts and writes nothing if any exist), which adds valuable context beyond the schema. It doesn't mention permissions, return format, or directory side effects, which keeps it from 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?

Two compact sentences: the first states exactly what is generated, the second covers profiles and conflict safety. No filler, front-loaded with the core purpose.

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 complex 21-parameter generator with no output schema, the description gives a strong high-level overview, including the generated artifact types and safety behavior. It does not explain the return value or plan output for dryRun, which is a minor gap given the tool's richness.

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 input schema has 100% description coverage for all 21 parameters, so the description does not need to add parameter detail. The few high-level mentions (profiles, optional JSP/tests) map to schema fields without adding new semantic value. 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?

The description clearly states the tool generates a VO/Mapper/Service/Controller/JSP/JUnit skeleton per eGovFrame's official CRUD wizard, and mentions profile support and conflict-checking behavior. This distinguishes it from siblings like generate_egovframe_ci or create_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?

The context is clear: use this when an eGovFrame CRUD scaffold is needed, with profiles and optional JSP/tests indicated. However, it does not explicitly name alternatives or state when not to use it, so it stops short of full usage guidance.

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 explicitly notes the tool is read-only ('읽기 전용'), which is a key behavioral trait. With no annotations provided, this disclosure helps, but additional details (e.g., no side effects, no network calls) are missing.

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 extremely concise: two sentences that front-load the main action and purpose, with no redundant or irrelevant content.

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 read-only report generator with one parameter and no output schema, the description covers the content and read-only nature. It lacks specification of where the report is saved or returned, but this is a minor 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 schema description coverage is 100% (single parameter with description requiring absolute path). The tool description does not add new information 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 clearly states the tool scans a project and generates a Markdown report containing installed components, reference tables, guide links, and issues. This specific verb+resource combination distinguishes it from sibling tools like diagnose_egovframe_project or add_egovframe_components.

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 mentions suitability for documenting assembly results or attaching to README, providing some context. However, it does not explicitly state when to use this tool instead of alternatives like diagnose_egovframe_project, nor does it list 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?

No annotations provided, so description must cover behavior. It discloses that multiple documents return a list and can be selected via docIndex, but does not describe return format for single documents, error behavior, or read-only nature. Adequate but not thorough.

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 sentences, no wasted words, front-loaded with purpose. Highly concise and easy to parse.

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?

Lacks return format specification for single documents and does not cover error cases. With no output schema, more detail on response structure would improve completeness. Adequate for a simple read tool but not fully complete.

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. Description adds examples for component (bbs, login) and explains docIndex selection behavior, which adds value 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?

Description clearly states it fetches the official guide document for a given component, with verb '가져옵니다' and specific resource. It mentions docIndex for selecting among multiple documents, distinguishing it from sibling search_egovframe_docs implicitly, though not 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?

No explicit guidance on when to use vs sibling tools, but the intended use case (fetching a specific component guide) is implied. Lacks when-not-to-use or 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?

No annotations are provided, so the description carries full burden. It mentions the catalog is auto-generated from a repository scan, implying it is read-only. However, it does not disclose any other behavioral traits (e.g., side effects, permissions). For a list operation, this is adequate but not rich.

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, dense sentence in Korean provides the purpose and source of the data. No unnecessary words, front-loaded with the main action.

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 parameterless list tool, the description covers the basics: what it returns and its generation method. However, it lacks details about the return format (e.g., structure of the catalog), which could be helpful given 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?

The tool has zero parameters, so schema coverage is 100% by default. The description adds no parameter information, which is acceptable since there are none. Baseline for 0 parameters is 4.

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 states the verb ('returns') and resource ('common component catalog that supports selective installation'), distinguishing it from sibling tools like 'add_egovframe_components' or 'search_egovframe_components'.

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 explains the tool's output but does not explicitly state when to use it versus alternatives. The context of 'selection installation' implies it's a preliminary step before adding components, but no direct guidance is 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?

No annotations are provided, so the description bears full burden. It states the tool returns a list but gives no information about side effects, permissions, rate limits, or output format. For a simple list tool this is passable but not thorough.

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 extremely concise with two short sentences. The first sentence states the purpose, and the second provides a related action. No filler 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 no input parameters and no output schema, the description is mostly complete for a list tool. It could optionally describe the output structure (e.g., what fields each recipe contains), but it's not critical for basic usage.

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 has no parameters, so the description does not need to add parameter meaning. Schema coverage is 100% (empty). Baseline 4 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?

The description clearly states the tool returns a list of curated recipes (template+component bundles) and mentions the related tool apply_egovframe_recipe for assembly. This distinguishes it from sibling list tools like list_egovframe_templates and list_egovframe_components.

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 explicitly tells the user that after listing, the apply_egovframe_recipe tool can be used to assemble the recipe. However, it does not provide explicit when-not-to-use or contrast with other list tools, but the hint is useful.

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?

No annotations are provided, so the description carries full burden. It only states the output type (list) but discloses no behavioral traits such as authentication needs, caching behavior, data freshness, response format details, or any side effects. For a read-only listing, basic expectations are not met.

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 a single, front-loaded sentence with no extraneous words. It efficiently conveys the core purpose.

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 zero parameters, no annotations, and no output schema, the description is minimal. It should at least hint at what each template entry contains (e.g., name, ID) or whether the list is ordered. The agent may need more context to use the output 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?

The input schema has zero parameters, and schema description coverage is 100% (trivially). No parameter documentation is needed. Baseline 4 is appropriate as the description adds no parameter info but doesn't need to.

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 states the tool returns a list of eGovernment standard framework project templates ('사용 가능한...목록을 반환'). The verb 'returns' and resource 'templates' are specific, and it distinguishes from the sibling 'create_egovframe_project' (list vs create).

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 usage: to see available templates before creating a project. While no explicit when-not or alternatives are stated, the purpose naturally indicates when to use (when you need the list) and not use (when creating a project). The single sibling is understood by contrast.

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 no annotations, the description fully carries the burden. It discloses that only manifest-recorded files are deleted, refusal of dependent or hash-mismatched files by default, force creating backups in remove-backup/ with transactional removal, and dryRun preview support. This is rich, non-obvious behavior.

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 a single, dense sentence that front-loads the core purpose and follows with safety and mode details. Every word adds value; no redundant or vague phrasing.

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 removal tool with four parameters and no output schema, the description covers the essential behavioral aspects: scope, safety guards, force semantics, and preview mode. It could mention what the tool returns (e.g., list of affected files), but that is a minor gap given the dryRun preview is already described.

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 parameters are already documented. The description adds meaningful context by explaining how force and dryRun affect behavior (e.g., backup creation, transactionality), which goes beyond the schema's simple type/default 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?

The description uses a specific verb ('removes') and resource ('components assembled with add_egovframe_components'), clearly distinguishing it from sibling tools like add_egovframe_components and list_egovframe_components. The scoping to manifest-recorded files adds precision.

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 provides clear context for when to use the tool (to remove previously added components) and explains the default refusal behavior and force option. However, it does not explicitly name alternative tools or when not to use it, so it falls short of a perfect score.

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?

No annotations are provided, so the description carries the full burden. It discloses that search is a partial match across multiple fields and returns top 10 results sorted by score, which is good transparency for a search tool.

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 a single concise sentence that front-loads the action and includes all essential details without unnecessary 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 the simplicity of the tool (2 parameters, no output schema), the description adequately covers search behavior, result limit, and parameter usage. It could mention the output format, but the lack of output schema makes it acceptable.

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 adds significant value by explaining that the query parameter matches against id, name, description, and category, and that category filters using specific codes. This goes beyond the schema 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?

The description clearly states the verb '검색합니다' (searches) and the resource '공통컴포넌트' (common components). It specifies search criteria (partial match on id, name, description, category) and result limit (top 10 by score), distinguishing it from sibling tools like list_egovframe_components.

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 usage for keyword-based search with partial matching and scoring, but does not explicitly mention when to use this tool vs alternatives like list_egovframe_components or search_egovframe_docs.

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?

No annotations are provided, so the description bears full responsibility. It discloses that the default is offline index search based on title, path, linked component, and category scores, and that fetchTop>0 triggers fetching document bodies for snippets. This is sufficient for a read-only search tool.

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, front-loaded with the main purpose, followed by brief behavioral details. No unnecessary words; every sentence serves a purpose.

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?

The description covers the key behaviors and the fetchTop option. However, it lacks explicit mention of the return format (e.g., a list of results with snippets) and does not specify what happens when fetchTop is 0 beyond offline search. Slightly incomplete given 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?

All three parameters are fully described in the schema (100% coverage). The description adds value by explaining the default search algorithm and the effect of fetchTop, going beyond the schema's basic 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?

The description clearly states it searches official guide document indexes by keyword, specifying the default offline search behavior and the option to fetch document bodies for top results when fetchTop>0. It distinguishes from sibling tools like search_egovframe_components.

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 does not provide explicit guidance on when to use this tool versus alternatives such as search_egovframe_components. It describes the fetchTop parameter but does not compare to other search strategies.

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 no annotations, the description carries full responsibility for disclosing behavioral traits. It mentions checking integrity and upstream changes, but does not clarify whether the tool is read-only, whether it modifies the local catalog, what happens on integrity failures, or if it makes network calls. The term 'sync' in the name adds ambiguity, which the description does not resolve.

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 a single, densely informative sentence with no filler. It uses technical terms appropriately and front-loads the main action, making it easy to scan. Every part of the sentence contributes to understanding the tool's purpose.

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 tool with no annotations and no output schema, the description is too sparse. It does not explain expected outputs, side effects, prerequisites, or how the 'sync' aspect operates (e.g., does it update the catalog or just report differences?). The one-line description leaves important gaps for an agent deciding whether to invoke this tool and what to expect.

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 the single parameter 'ref', which already explains the tag/branch/commit and the default use of the official fixed tag. The tool description adds no additional parameter context beyond referencing the fixed catalog, so the 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?

The description clearly states a specific verb ('검증하고' and '점검합니다' meaning verify/inspect) and a distinct resource (egovframe-common-components tags, commits, archives), while also defining the scope: comparing against the fixed catalog and checking sec.security security packages. This clearly distinguishes it from sibling tools like validate_egovframe_project or diagnose_egovframe_project by focusing on upstream changes and catalog integrity.

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 provides no guidance on when to use this tool versus alternatives. It does not state that it should be used to check upstream changes or to validate catalog integrity, nor does it mention any exclusions or alternatives. The name implies a sync operation, but the description neither confirms nor denies whether it updates the catalog, leaving usage context entirely unspecified.

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 no annotations, the description describes key behaviors: user-modified files preserved without force, dryRun default, backup before overwrite, and rejection on hard conflicts. It could mention error cases or permissions, but overall it provides good transparency.

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 sentences, each conveying a distinct behavior without redundancy. Front-loaded with the main action, then details on preserving files, dry-run, backup, and conflict handling. No wasted 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?

The description explains the tool's operation but omits return value or output format (e.g., what dryRun displays, success/error messages). With no output schema, this is a gap. Also, it doesn't specify when to use vs. sibling tools, but in context, upgrade is clear.

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 does not add significant detail beyond schema descriptions for parameters like force, dryRun, components, and projectDir. The overall behavioral context adds marginal value.

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 states it updates installed common components by comparing with upstream, with specific actions like preserving user files, dry-run, backup, and conflict refusal. It is distinct from sibling tools (add, create, apply, etc.) due to the upgrade focus.

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 explains usage with dryRun for planning and force for overwriting, guiding when to use each mode. However, it does not explicitly contrast with sibling tools like add_egovframe_components or apply_egovframe_recipe, though the name implies upgrade.

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 lists two specific checks (file existence, Db type consistency) but does not disclose whether the tool is read-only, requires permissions, or what happens on failure. With no annotations, this is moderate transparency.

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 concise with two sentences, covering the core purpose and key checks without unnecessary verbosity.

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?

The tool lacks an output schema and the description does not explain what the tool returns (e.g., success/failure, error details). For a validation operation, this is a significant gap that leaves the agent without understanding how to interpret results.

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 parameter exists with 100% schema description coverage. The description adds no extra detail beyond the schema's '검증할 프로젝트 디렉터리' (project directory to validate), so baseline score of 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?

The description clearly states the tool diagnoses integrity of an assembled project, performing specific checks like file existence and DB type consistency. This is distinct from sibling tools like 'diagnose_egovframe_project', though not explicitly differentiated.

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 guidance is provided on when to use this tool versus alternatives. It implies use after project assembly but does not specify prerequisites or scenarios where it should be avoided.

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