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

No annotations provided, so description fully bears behavioral disclosure. Describes returned data (page count, tables, fields, body text, controls) and version-specific catalog. Lacks error handling or input validation 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 tight sentences, front-loaded with key purpose and return content. 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?

No output schema, but description lists major return categories. Could benefit from structural details of the return object. However, with many siblings, the prerequisite guidance is helpful.

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 file_path with schema description 'HWP/HWPX 파일 경로'. Description adds no additional semantics beyond schema; schema coverage is 100%, 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?

Specifies verb 'analyze document structure', resource 'HWP/HWPX', and lists return items. Distinguishes from siblings by being the mandatory first call for any document.

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 states 'must call this tool first when dealing with a document'. Clear usage context, though no explicit exclusions or alternatives 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 must disclose behavior. It mentions reuse of other tools (90%) and output usage, but does not explicitly state it is non-destructive, latency, or other side effects. For a learning/analysis tool, the description is insufficient.

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: first states purpose, second gives implementation details and downstream usage. It is reasonably concise, though the implementation detail (reuse percentage) could be removed for brevity.

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 what the tool does and its output usage, but lacks details about return value format (no output schema). Given the single parameter and simple nature, it is 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 one parameter (file_path) described simply as '양식 파일 경로' (form file path). The description adds no additional meaning beyond the schema, 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 it learns formatting patterns (font, line spacing, indentation, numbering system) from a form file. It distinguishes itself from sibling tools by noting it reuses extract_full_profile, extract_style_profile, and get_table_format_summary, indicating it is a higher-level analysis tool.

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 as a prerequisite for hwp_extend_section and hwp_apply_style_profile, but does not explicitly state when to use this tool versus siblings or provide when-not/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 provided. Description states the action (apply batch) but does not disclose side effects (e.g., overwriting existing formatting, reversibility, or prerequisites). Limited behavioral insight beyond the core operation.

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, front-loaded with action. No redundant information. Could potentially list presets more efficiently, but overall concise and clear.

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 tool with one parameter and no output schema, the description covers what it does, what it applies, and eligible values. Lacks error conditions or result confirmation but adequate for typical use.

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 parameter description listing allowed values. The description adds meaning by explaining what each preset does (paper settings + font/line spacing), going beyond the schema's label-only description.

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 applies document presets with paper settings and font/line spacing, and lists the six preset names. This distinguishes it from siblings like hwp_apply_style or hwp_set_page_setup.

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 applying a complete preset but does not explicitly state when to use vs. alternatives (e.g., listing presets first via hwp_get_preset_list). No exclusions or when-not-to-use 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?

No annotations provided. Description does not disclose behavioral traits like overwriting existing styles, impact on formatting, or error conditions (e.g., invalid style name).

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 action and examples. Efficiently communicates core purpose without unnecessary detail.

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?

Adequate for a simple one-parameter tool with no output schema, but lacks details on error handling, prerequisites, and behavior when cursor position is invalid.

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 describes the parameter with examples. The tool description repeats the examples, adding no extra semantic value beyond what the schema provides.

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 applies a paragraph style at the current cursor position and provides examples of style names. However, it does not differentiate from similar sibling tools like hwp_set_paragraph_style.

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 on when to use this tool versus alternatives such as hwp_set_paragraph_style, nor any context about prerequisites 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, the description must be transparent. It discloses that it repeatedly calls set_paragraph_style, indicating it modifies paragraph styles. However, it does not explain handling of table_styles or title_styles in the profile, leaving ambiguity about the full effect on the document.

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: first states primary purpose, second adds context about input source and implementation. 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?

Given the sibling tools and no output schema, the description covers the input relationship and implementation. It could clarify the effect on non-paragraph elements, but overall it is complete enough for an agent to use 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 coverage is 100% with descriptions. The description adds value by explaining that the profile is the output of hwp_analyze_writing_patterns and that the tool internally calls set_paragraph_style, which helps understand how the parameters are used.

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 applies a 'formatting pattern profile (WritingPatterns)' to the current document, with the verb 'applies' and a specific resource. It distinguishes itself from siblings like hwp_apply_style (single style) and hwp_set_paragraph_style (individual style) by referencing the profile input and repeated calls.

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 specifies that the tool uses the output of hwp_analyze_writing_patterns as input, providing clear usage context. It does not explicitly state when not to use it, but the close coupling with the analysis tool implies a workflow, which is sufficient.

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 shoulders full responsibility. It mentions '서식 보존 채우기' (format-preserving fill) and '일괄 수행' (batch perform), but does not disclose whether the tool modifies the document in-place, creates a new one, or what happens on failure (e.g., mapping errors, file access issues). For a composite tool, more behavioral context is needed.

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 key functionality. However, it could be more structured with bullet points or separation of purpose from usage context. Still, it is appropriately sized and clear.

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 tool's composite nature and many sibling tools, the description lacks information on workflow steps, output format, and prerequisites (e.g., file must exist, document must be open). It also does not specify that it likely modifies the current document. With no output schema, more context is needed for complete understanding.

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 all parameter descriptions are present in the schema. The description adds no additional parameter details beyond the schema, so it meets the baseline without adding extra 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's a one-stop tool for automatic mapping and format-preserving filling from Excel/CSV, integrating three sub-tools. It provides a concrete example request, and the verb '수행' (perform) combined with '원스톱 도구' (one-stop tool) distinguishes it from sibling tools that are more granular.

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 mentions it integrates hwp_smart_fill, hwp_read_reference, and hwp_auto_map_reference, implying it should be used when all three are needed. However, it does not explicitly state when NOT to use it or provide alternatives for simpler tasks, leaving some ambiguity.

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 bears full burden. It states that the tool generates data (non-destructive), but does not disclose whether it modifies the document, what the generated data looks like, error handling, or prerequisites. Insufficient for a mapping 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 three concise sentences, front-loaded with the main purpose, then steps and tips. No redundant or extraneous 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 workflow but misses important details such as the output format (mapping results), error conditions, and prerequisites. Without an output schema, more context on return value is needed. Adequate but not comprehensive.

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 three parameters. The tool description does not add new meaning beyond the schema, such as providing defaults, examples, or constraints. Baseline score of 3 is appropriate due to high 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?

The description clearly states the tool's function: automatic matching of reference data headers with table labels to generate fill data. It specifies the source (Excel/CSV) and distinguishes itself from siblings like hwp_fill_table_cells and hwp_read_reference by outlining the workflow.

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 clear context on when to use the tool: after reading reference data with hwp_read_reference and before filling with hwp_fill_table_cells. It does not explicitly mention alternatives or when not to use it, but the workflow guidance is strong.

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 describes the pipeline steps (write, style, TOC, verify, save, PDF, layout validation), session state auto-save, cancel check, and version-specific default behaviors for auto_fix and preserve_template_style. It discloses the behavioral changes across versions. It does not mention file overwriting behavior or error handling, but overall it is fairly 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 that front-loads the main purpose and then provides key details about modes and version-specific defaults. It is concise with no filler, but the dense formatting (version numbers, parameter names) could be more readable. Overall 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?

With no output schema and 16 parameters, the description covers the pipeline flow, modes, and some parameter defaults. However, it does not specify the return value or response structure (e.g., what plan returns vs execute, or what 'awaiting_approval' means). The plan_session_id interaction is mentioned but not fully explained. This leaves gaps for an agent to understand the complete interaction.

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 16 parameters have schema descriptions with 100% coverage, so the baseline is 3. The main description adds pipeline-level context but does not significantly enhance understanding of individual parameters beyond what the schema provides. It mentions version-dependent defaults for some parameters, but this is marginal improvement.

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 is a 12-step pipeline for automatic document creation, taking sections and tables, applying templates, styling, TOC, validation, save, PDF, and layout validation. It distinguishes mode=plan from mode=execute. However, it does not explicitly differentiate from siblings like hwp_document_create, though the pipeline nature is evident.

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 two modes: plan for estimation, execute for actual run. It mentions defaults for auto_fix and preserve_template_style and that sections/tables can be omitted with plan_session_id. However, it lacks explicit guidance on when to use this tool versus alternatives like hwp_autopilot_plan or hwp_document_create, and does not specify 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?

With no annotations, the description carries the burden. It discloses that this tool does not call an LLM, saves state to a file (~/.hwp_studio_state), and generates a skeleton. However, it does not mention side effects like file system writes, permissions, or idempotency, which are relevant for an agent.

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 purpose, and every sentence adds value. No redundant 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?

Given the complexity (9 parameters, integration with other tools, no output schema), the description explains the workflow, file storage, and the role of the returned plan. It is complete enough for an agent to understand how to use it in the autopilot pipeline, though details about the plan structure are limited.

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 adds context that output_path is passed to autopilot_create and session_id ties the steps, but does not add significant meaning beyond what the schema already provides.

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 structured plan for automatic document generation, and distinguishes it from sibling tools like hwp_autopilot_create by explaining the two-step workflow. The verb 'returns' and resource 'structured plan' are specific.

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 is part of an autopilot pipeline: it creates a plan, then Claude host fills content and calls hwp_autopilot_create. It implicitly suggests using this tool before hwp_autopilot_create, but does not explicitly state when not to use or mention 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 no annotations, the description carries full behavioral disclosure burden. It does not mention whether original files are modified, error handling, prerequisites, or return behavior. This is insufficient for a batch operation 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, clear sentence that conveys the core purpose without any wasted words. It is appropriately front-loaded and concise.

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 is minimal and does not cover important aspects like return values, error conditions, or prerequisites. Given the lack of output schema and annotations, more context is needed for a batch operation.

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 does not add extra semantics beyond what the schema already provides for input_dir, output_dir, and output_format.

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 action (batch convert), the resource (all HWP files in a folder), and the format specification. It effectively distinguishes from sibling tools that handle single file conversions or other operations.

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 batch tool versus single-file conversion alternatives like hwp_export_pdf. The description lacks context for appropriate usage.

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, and the description does not disclose any behavioral traits such as side effects, permissions, or what happens to the cursor. It only states the operation without context beyond the action.

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, concise sentence that immediately states the purpose. No wasted words; 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?

Given no parameters and no output schema, the description is minimal. It explains the action but lacks context about prerequisites (e.g., must be in a multi-column section) or what happens after insertion. Adequate but could provide more.

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?

No parameters exist, so the schema coverage is complete. The description adds no parameter information, but with zero parameters, a baseline of 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 action ('inserts') and the resource ('column break') with a specific location ('at current position'). It distinguishes from sibling tools like hwp_insert_page_break (page break) and hwp_break_section (section break).

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 on when to use this tool vs alternatives. Does not mention that it should be used for multi-column layouts or that it differs from page or section breaks. Lacks explicit usage context.

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 must convey behavioral traits. It only states the action without disclosing what happens after insertion (e.g., document structure changes, whether content shifts, or if the operation is destructive).

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 in Korean, front-loaded with the verb. It contains no filler or redundant 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 simple parameterless tool, the description provides the essential purpose and location. However, it lacks sufficient context for an agent to understand when to use it among many sibling tools, and it does not explain return values or side effects.

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 are zero parameters, so the schema provides no information. The description adds the core action and location. Baseline for no parameters is 4, and the description meets this by clearly indicating the tool's function.

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 ('inserts') and resource ('section break') with a specific location ('at current position'). It distinguishes from sibling tools like hwp_insert_page_break (page break) and hwp_break_column (column break).

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 on when to use this tool versus alternatives. For example, it does not explain when a section break is preferred over a page break or column break, nor does it mention any prerequisites or effects.

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 the full burden. It discloses a multi-step process (detect type, extract structure, parse tips, read references, return context) and notes it is non-destructive (prepares data for AI). It does not mention error cases or permissions, but the core behavior is well explained.

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: one paragraph with a clear structure, using a bullet-like enumeration and minimal fluff. Every sentence adds information, and the version number is included without clutter.

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 complexity (multi-step analysis), the description lacks details about the output format (what 'AI context' entails) and error handling. Although it references the next tool, the agent may need more context on the return structure to use the result 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?

Schema coverage is 100%, so both parameters are documented. The description adds value by explicitly stating reference_files is optional and explaining its role in section mapping, which goes beyond 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 tool's purpose: analyzing business plan templates to generate AI auto-writing context. It lists five explicit steps and distinguishes itself from the sibling hwp_korean_business_fill by noting that this tool prepares context for that subsequent fill 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 description explains that this tool is a preparatory step before hwp_korean_business_fill, implying a sequential workflow. It does not explicitly say when not to use it or compare with alternatives, but the context is clear enough for an agent to infer usage.

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 mentions diagnostics and guidance but does not disclose side effects or permissions needed. Adequate for a simple diagnostic 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?

Two concise sentences front-load the main action. 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?

Given zero parameters and no output schema, the description covers purpose, what is checked, and usage context. Could optionally mention output format.

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?

No parameters exist; schema coverage is 100% trivially. Baseline 4 applies as description adds no parameter info but none is needed.

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 that the tool diagnoses the user environment by checking Python, pyhwpx, and HWP program installation status, and provides installation guidance. It distinguishes itself from siblings like hwp_install_deps.

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 says to call this tool first when using for the first time or when errors occur. Lack of explicit when-not-to-use or alternatives prevents 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?

No annotations are provided, so the description carries the full burden. It discloses the core behavior (closing) but omits important details such as whether unsaved changes are auto-saved, discarded, or prompted, and what happens if no document is open. This is a moderate gap for a mutation 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?

Two short sentences with no wasted words. The first sentence delivers the primary function; the second provides usage context. 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?

For a simple, parameterless close operation, the description covers the essential purpose and usage. With no output schema needed, it is sufficiently 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?

There are zero parameters and schema coverage is 100% (empty). The description does not need to add parameter details. A baseline of 4 is appropriate as it does not detract.

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 action ('closes the currently open HWP document') and the resource ('HWP document'). Among many sibling tools, none duplicate this close function, so it distinguishes itself effectively.

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?

Explicit usage guidance is provided: 'Call before opening another document or after completing work.' This tells the agent when to invoke the tool versus 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 no annotations, the description must convey behavioral traits. It mentions 'compares text and returns differences' but does not disclose if it modifies documents, requires permissions, or has side effects. The read-only nature is implied but not explicit, leaving a gap for the agent.

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 is concise and front-loaded. It communicates the core functionality without any fluff or redundant information. Every word 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 tool has no output schema, and the description does not explain the format of the returned differences (e.g., unified diff, list of changes). It lacks details on handling large files, error conditions, or performance implications. For a comparison tool, this is incomplete.

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 both parameters have descriptions in the schema. The description does not add any additional meaning beyond what the schema already provides. No extra context like accepted file formats or path formats is given.

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 compares the text of two HWP documents and returns differences. The verb 'compare' and resource 'two HWP documents' are specific, distinguishing it from siblings like hwp_compare_with_template or hwp_get_document_text. No ambiguity.

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 guidance on when to use this tool versus alternatives. It does not mention exclusions, prerequisites, or context such as whether documents need to be open. Sibling tools exist for similar purposes (e.g., hwp_compare_with_template, hwp_get_document_text), but no differentiation is provided.

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 reveals that the tool internally calls two other tools and that self-comparison yields 100. However, it does not disclose side effects, authentication needs, or rate limits. The behavioral details are partial but non-contradictory.

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) yet packs essential information: purpose, internal mechanism, and a self-test result. Every sentence earns its place with 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?

Given no output schema, the description should indicate the return format but only vaguely mentions 'scores'. It also does not explain prerequisites or error conditions. For a tool with internal complexity, more completeness would be beneficial.

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 schema already provides descriptions for each parameter (including default weights for the weight object). The description does not add new semantic information beyond the schema, so a 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 that the tool compares a result document with a template and calculates scores for format, structure, and content. It also mentions it uses a weighted sum from two other tools (extract_template_structure and analyze_writing_patterns), which distinguishes it from sibling tools like hwp_compare_documents.

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 vs alternatives. It implies usage for template adherence checking but lacks when-not-to-use or specific conditions, making it less helpful for selection among many sibling tools.

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 mentions output ('■ 표시가 있는 일정표') but does not disclose side effects (e.g., whether it overwrites existing content, prerequisites like an open document, or potential errors). This is insufficient for a tool that modifies document content.

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 long, front-loads the purpose, and contains no extraneous information. Every word 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?

Given the lack of output schema and the complexity of a Gantt chart (mapping months to columns), the description could explain more about the output structure and parameter mapping. It is adequate for a basic understanding but leaves questions about how to use start/end months and the resulting table layout.

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 parameter descriptions. The description adds only '작업 목록과 기간' (task list and period), which maps to the parameters but does not provide additional semantic context beyond the schema. 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 creates a Gantt chart table automatically ('추진일정 간트차트 표를 자동 생성합니다'), which is a specific verb-resource pair. The name also reinforces this. However, it could be more explicit about distinguishing from generic table creation tools like hwp_table_create_from_data.

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 creating schedule Gantt charts with task lists and periods, but it does not provide explicit when-to-use vs when-not-to-use guidance, nor does it mention alternatives among the many sibling tools.

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. Discloses version history and extract_first option, but does not mention irreversibility, error behavior, or side effects. Sufficient for basic understanding but not comprehensive.

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?

Multiple sentences but mixes version info with usage. Could be more structured (e.g., separate behavioral notes from usage). Not extremely concise, but adequate length.

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; description does not explain return values or error states. For a 4-parameter tool with no annotations, it covers basic usage but lacks completeness regarding outcomes and edge cases.

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 100% (baseline 3). Description adds value by explaining scope enum values beyond schema, recommending defaults, and noting extract_first as a new feature. Provides context for patterns and table_keywords defaults.

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 deletes guide text in HWP forms, with specific verb 'delete' and resource 'guide text'. It distinguishes from sibling tool hwp_extract_guide_text by action (delete vs extract).

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?

Provides clear usage context: 'Use after filling out public institution forms before submission.' Recommends default scope='both' for general form cleanup. However, lacks explicit when-not-to-use or comparison to alternative deletion methods.

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 describes the detection and recommendation behavior, implying a read-only operation. However, it does not explicitly state that it makes no changes to the document or mention any potential side effects, which would be clearer for 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?

The description is concise with two sentences and a type list. It front-loads the purpose. However, it includes a version note '(v0.7.5.4 신규)' that is not essential for the agent, slightly reducing conciseness.

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 parameters and no output schema, the description covers the tool's output (recommended_preset) and its integration with another tool. It does not mention fallback behavior or error cases, but for a zero-parameter detection tool, it is sufficiently 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?

The input schema has zero parameters, so the baseline is 4. The description adds value by explaining the output usage but does not need to elaborate on parameters since none exist.

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 specifies the action (automatically detect document type) and the resource (government standard form presets). It lists the possible types and explains how the result feeds into another tool, distinguishing it from sibling tools that do not offer detection.

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 explicitly instructs to call this tool first before working on business plans or official documents, and explains how to pass the result (recommended_preset) to hwp_insert_body_after_heading for automatic formatting. This provides clear when-to-use and integration 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?

No annotations are provided, so the description carries full burden. It discloses two traits: works without Hancom program and generated file is compatible with Hancom. However, it does not specify whether the tool overwrites existing files at output_path, nor does it mention error handling or limitations.

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 three short sentences, each adding distinct value: what it creates, independence from Hancom, and output compatibility. It is front-loaded with the primary action and contains 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?

For a simple creation tool with no output schema and absent annotations, the description is adequate but incomplete. It covers basic functionality and key behavior (standalone, compatibility) but missing details like overwrite policy and required path format. Completeness is sufficient for a minimal viable description.

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 provides meaning for both parameters (title optional, output_path as file path). The description adds little beyond confirming the document is empty. Since schema does most of the work, 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 creates an empty HWPX document, using specific verb '생성합니다' (create) and resource '빈 HWPX 문서' (empty HWPX document). It distinguishes this tool from siblings by being the only one focused on creating a new empty document, as others operate on existing documents.

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 creating an empty HWPX file but provides no explicit guidance on when to use this tool versus alternatives like hwp_insert_text or hwp_table_create_from_data. No when-not-to-use or prerequisite information 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, and the description only states the merge action without disclosing behavioral details such as whether the operation is destructive, how the content is inserted (append vs. cursor position), or the impact on formatting. This leaves significant gaps.

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 only two sentences, efficient and front-loaded with the key action. Every word is essential with no fluff.

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 tool's simplicity (one parameter, no output schema), the description is adequate but minimal. It lacks details such as merge behavior (e.g., append vs. replace), error conditions, or prerequisites like document state. More context 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?

The input schema has full coverage for the single parameter 'file_path' with a description. The tool description does not add additional semantic value beyond the schema, but since the schema already explains it, the 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 verb ('합칩니다', meaning merges) and resource ('다른 HWP 문서의 내용' into the current document). It also distinguishes itself from siblings like 'hwp_document_split' by specifying the merging action.

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 states when to use this tool ('여러 문서를 하나로 합칠 때'), providing clear context. However, it does not mention alternatives or when not to use it, missing some 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?

No annotations exist, so the description must disclose behavioral traits. It fails to mention side effects (e.g., file creation, modification of original document), permissions, or error conditions. The only disclosed behavior is splitting and saving.

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 the core action. Every word adds value, and there is no redundancy or 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?

For a tool that creates files, the description lacks crucial context: what happens to the original, file naming conventions, output location behavior, and error handling. Given low complexity, more detail is expected.

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?

Both parameters are described in the schema with 100% coverage. The description adds the concept of 'page unit' but does not enhance schema descriptions meaningfully. 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 action (split into pages and save as separate files) and the resource (document). It distinguishes this tool from siblings like merge, info, etc., by specifying page-based splitting.

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 'when splitting a long document' gives a usage context but lacks explicit exclusions or alternatives. It does not mention prerequisites like having an open document 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?

No annotations are provided. The description implies a read-only analysis but does not explicitly confirm no side effects, nor does it disclose specifics like permissions or performance. It lacks behavioral details beyond the core actions.

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 succinct sentences, front-loading the actions in the first and the usage context in the second. Every sentence contributes value without 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?

While the tool is simple with one parameter, the description fails to specify the output format or what the returned summary contains beyond completion percentage and empty fields. This gap in completeness for a summary tool lowers the score.

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 covers the single parameter 'file_path' with a description. The tool description adds no additional meaning beyond what the schema already provides, so it meets the baseline for a simple parameter.

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 analyzes documents, highlights empty fields/cells, and calculates completion percentage. It specifies the verb 'analyze' with concrete actions, distinguishing it from siblings like hwp_analyze_document or hwp_smart_analyze.

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 advises using the tool to grasp document status and decide next steps, providing clear context for its use. However, it does not explicitly mention when not to use it or suggest alternative tools.

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 of disclosure. It only states it draws a line and lists attributes but does not mention any behavioral traits such as where the line is drawn, potential side effects, or requirements (e.g., cursor position). This lack of transparency is a gap for a mutation 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 very concise with three short sentences, no filler, and the key information is front-loaded. Every sentence adds value without unnecessary detail.

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 lists parameter attributes and compares to a sibling, but it omits important context such as where the line is drawn (e.g., at cursor or in selected area) and behavior when no parameters are provided. Given the low complexity and presence of schema descriptions, the completeness is adequate but not thorough.

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 describes all parameters. The description adds no extra semantic information beyond what is in the schema, resulting in a baseline score of 3.

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 action (draw a line) and the customizable attributes (thickness, color, style). It also distinguishes from the sibling tool hwp_insert_line by noting more detailed control, making the purpose specific and 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?

The description implies usage context by comparing with hwp_insert_line, suggesting this tool is for more detailed control. However, it does not explicitly state when to use this tool versus alternatives or any prerequisites, which could be clearer.

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 burden. It explains that the cursor moves to the first cell, supports nested tables via path, and mentions the version. It does not disclose potential side effects, but the tool is non-destructive and behavior is well-covered.

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 and front-loaded with the main action. It includes necessary details (version, path format, example, workflow) without being verbose. Slightly technical but appropriate for the audience.

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 output schema, the description sufficiently covers the outcome (cursor positioned) and the workflow (enter, then use other tools, then exit). It also provides an example path and version info, making it complete for the tool's purpose.

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 description adds substantial meaning: it explains the dual nature of table_index (number vs array), details the path format with an example, and clarifies the select_cell parameter default. This goes far 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 '지정된 표에 진입하여 첫 셀에 커서를 위치시킵니다' (enter specified table and position cursor at first cell). It distinguishes from sibling tools like hwp_exit_table and hwp_navigate_cell by specifying the entry action and the subsequent workflow.

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 when to use this tool: before calling hwp_navigate_cell, hwp_insert_text, etc., and notes that hwp_exit_table should be called after work. It provides clear context but does not explicitly state when to avoid using it (e.g., when already inside a table).

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 discloses that the tool is read-only and uses recursive DFS to find nested tables. It mentions the output structure. However, with no annotations, it fails to disclose potential performance implications for large documents, recursion limits, or error handling. Adequate but not thorough for a complex recursive 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?

Two sentences with no waste. Front-loaded with the main action. The version annotation '(v0.7.2.1 신규)' is slightly extraneous but does not harm. Efficient and to the point.

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 output schema, the description adequately explains the return type (NestedTableNode[]) and fields (path, rows, cols, children). However, it lacks details on error behavior, edge cases (empty documents), or performance notes. Given the complexity of nested traversal, slightly more context 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 coverage is 100% with a single parameter file_path already described in schema. The description adds no additional meaning or usage details beyond the schema description. Baseline score of 3 is appropriate when schema covers parameters adequately.

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 the tool enumerates all tables including nested ones in HWPX documents as a tree structure, using DFS traversal. It explicitly mentions the output format (NestedTableNode[] with path, rows, cols, children). This distinguishes it from sibling tools like hwp_get_tables which likely only list top-level tables.

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 on when to use this tool versus alternatives. Among many table-related siblings, it does not indicate prerequisites, when to avoid, or suggest other tools for simpler table queries. The description is purely functional without usage context.

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 the estimation formula, output structure (risk items, recommended actions), and that the user decides whether to proceed. It does not state side effects, but the tool is likely read-only. The detail is commendable.

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 that is both concise and informative, front-loading the purpose and then detailing inputs, outputs, and formula. Every sentence adds value; no waste.

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?

Although there is no output schema, the description fully explains the return values (pages, tokens, time, risks, recommendations) and the underlying formula. It covers prerequisites and how the tool integrates into the workflow, leaving no gaps for a planning 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 coverage is 100%, so baseline is 3. The description adds value by explaining how parameters map to the estimation process (e.g., mode, file_path for form analysis, constraints), providing context beyond the schema descriptions. It clarifies the role of each input.

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 explicitly states the tool estimates workload for HWP writing tasks, detailing inputs and outputs (pages, tokens, time, risks, recommendations). It is distinct from all sibling tools, which are focused on editing, formatting, or reading documents.

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 clearly indicates the tool is for pre-writing workload estimation and that the user decides based on results. However, it does not explicitly discuss when not to use it or compare with alternatives, though the unique purpose is evident from sibling context.

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?

Without annotations, description carries full burden. It discloses internal implementation (_exit_table_safely, MovePos(3) + BreakPara) and safety behavior (no-op when not in table). Could add more detail on side effects like cursor position, but 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?

Two concise sentences covering purpose, usage context, safety, and implementation. 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?

With no parameters and no output schema, description is complete. It covers all necessary aspects: what, when, safety, and internal behavior.

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?

No parameters, so baseline is 4. Description adds value by explaining when to use and safety, which compensates for lack of param details.

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 'Explicitly exit the current table' with specific verb and resource. It distinguishes itself from siblings like hwp_enter_table and hwp_navigate_cell by being the dedicated exit tool.

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 says to call after hwp_enter_table when cell work is done and notes it's safe to call even when not in a table (no-op). No explicit alternatives given, but the tool's purpose is unique, so this is clear enough.

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 present, so the description carries full burden. It only states the action without disclosing behavioral traits such as whether the document must be open, if the export overwrites existing files, or what happens on failure.

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. It is front-loaded and efficient, though it could benefit from slightly more behavioral context.

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 mutation tool with no output schema and no annotations, the description lacks important context such as preconditions (document open), success/failure behavior, and side effects.

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% for the single parameter (output_path), and the description adds no additional meaning beyond what the schema already provides. Baseline score for high 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?

The description clearly states the verb (export) and the resource (current document to DOCX format), distinguishing it from siblings like hwp_export_pdf and hwp_export_html.

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 tool vs alternatives (e.g., hwp_save_document). The implied usage is for exporting to DOCX, but no context or preconditions are provided.

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?

Description does not disclose behavioral traits such as whether the original document is modified, any destructive effects, or performance implications. No annotations were provided to compensate.

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?

Description is concise (one sentence) but lacks detail. It is front-loaded with the action but could include more crucial information without becoming 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?

Given the large number of sibling tools and the presence of export alternatives, the description is insufficient. It fails to specify scope (full document vs. selection), format details, or any output handling. No output schema is provided, so description should cover these aspects.

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% with a single parameter. The description does not add meaning beyond the schema's parameter description of 'output_path'. 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?

Description clearly states verb (export) and resource (current document to HTML), and the target format is evident. However, it does not distinguish from sibling export tools like hwp_export_pdf or hwp_export_docx.

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 on when to use this tool versus alternatives. No mention of prerequisites, constraints, 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 provided, the description carries full burden for behavioral disclosure. It only states the action (export) without revealing side effects like file overwrite behavior, required permissions, or error states. The lack of detail leaves the agent unaware of potential issues.

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-load the key information. Every word is necessary with no redundancy. The structure efficiently communicates purpose and usage hint in minimal space.

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 tool with one parameter and no output schema, the description covers the basic purpose and parameter. However, it lacks context on what happens on failure, whether the file is overwritten, or any prerequisites. The description is minimally sufficient but not complete for a fully informed 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% with one parameter fully described in the input schema. The description adds no extra meaning beyond the schema's parameter description. Baseline 3 is appropriate as the schema already documents the parameter adequately.

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 explicitly states 'Export the current document to PDF' with a specific verb and output format. It clearly distinguishes from sibling export tools like hwp_export_docx and hwp_export_html by naming the target format.

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 a usage hint ('Use for requests like Please convert to PDF') but does not specify when not to use this tool or mention alternatives like other export formats. No explicit exclusions or context for choosing between sibling tools.

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 burden. It discloses that content is appended to an existing section while preserving formatting via the preserve_format parameter, and that section location is found by title text. However, it does not mention side effects (e.g., whether the document is saved automatically), error conditions (e.g., section not found), or behavioral guarantees like atomicity. The version note adds minimal 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 concise (two sentences plus a version note) and front-loaded with the main purpose. It avoids redundancy but could be slightly expanded for clarity. The structure is efficient, with 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?

Despite the description covering core behavior, it lacks completeness. There is no output schema, and the description does not mention return values (e.g., success status, modified section info). Error handling and prerequisites (e.g., document must be open) are omitted. For a tool that modifies a document, more context is expected.

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 three parameters. The description adds value by clarifying that section_identifier searches by title text, and that content is paragraph-unit separated by newlines. It also implies the purpose of preserve_format. This goes beyond the basic schema definitions.

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 content at the end of a specific section in an existing form, preserving formatting. It uses a section identifier to locate the section by title text. This distinguishes it from sibling tools like hwp_insert_text or hwp_insert_body_after_heading, though it could be more explicit about what constitutes a 'section' in HWP.

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 vs. alternatives. The description mentions 'LLM-generated content' but does not clarify scenarios where other insertion tools (e.g., hwp_insert_text, hwp_insert_body_after_heading) would be more appropriate. No exclusionary criteria 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?

No annotations are provided, so the description carries the full burden. It discloses what is returned (page setup, formatting, table dimensions) but does not mention whether the tool modifies document state, any prerequisites (e.g., document must be open), or performance implications. This is 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?

The description is two short sentences, front-loaded with the purpose. The first sentence clearly states the tool's function, and the second details outputs and a usage clue. Every word adds value, achieving conciseness without loss of clarity.

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 output schema, the description adequately explains return values (page setup, text/paragraph formatting, table dimensions) and a usage context. It lacks details like error handling, document type restrictions, or performance notes, but it is largely complete for its simplicity.

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, so schema coverage is 100%. The description correctly implies no parameters are needed. Since no parameter details are required, a score of 4 is appropriate; no additional value from description is needed.

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 analyzes document style ('문서의 양식을 정밀 분석합니다') and lists specific outputs: page setup, text/paragraph formatting (19 properties), and table dimensions (up to 5). This sufficiently distinguishes it from siblings like hwp_extract_style_profile or hwp_analyze_document, which focus on different aspects.

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 says '양식 기반 문서 작성 전 반드시 호출하세요' (must call before writing a form-based document), providing a clear when-to-use directive. However, it does not mention when not to use or suggest alternatives, leaving room for improvement.

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 of behavioral disclosure. It states it extracts structured content and implies it is a read-only operation (no modification mentioned), but does not describe the output format or any side effects. While adequate, more details on the structured output would improve 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 extremely concise with two sentences: one describing the extraction action and one for usage guidance. Every sentence adds value without redundancy, making it efficient and scannable for an AI agent.

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 parameters and no output schema, the description provides sufficient context for an agent to understand the tool's purpose and when to use it. The mention of version and linking to sibling 'hwp_delete_guide_text' adds helpful context. Minor improvement could include what the structured output looks like, but it is largely 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?

The input schema has zero parameters and 100% schema coverage, so the description need not add parameter details. The tool acts on the current document context, which is implied. Baseline for zero parameters is 4, and the description meets that adequately.

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 extracts structured content from the form's writing instruction box ('양식의 작성요령 박스 내용을 구조화 추출합니다'). It also distinguishes itself from sibling tools like 'hwp_delete_guide_text' by advising to call before deletion, making its role and purpose unambiguous.

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 recommends calling before deletion to preserve requirements and suggests using the result as AI content generation context. This provides clear when-to-use guidance, though it does not explicitly state when not to use it, which is acceptable given the tool's specificity.

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. It discloses the read operation and lists extracted components. However, it does not specify side effects, permissions, or return format, leaving some gaps.

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 with no wasted words. The first sentence states the action and components, the second provides usage guidance. 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?

For a simple extraction tool with no parameters and no output schema, the description covers the essential purpose and usage. It could mention how the output can be used (e.g., to apply later), but it is already hinted by the second sentence. Adequate for the complexity level.

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?

Input schema has zero parameters, so schema coverage is 100%. The description does not need add parameter info; baseline score of 4 applies. No further semantics needed.

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 extracts style profile (font/size/spacing/indentation/margins) from a form document, using a specific verb (추출합니다) and resource. It distinguishes itself from siblings like hwp_apply_style_profile by indicating its purpose is to understand formatting for identical application.

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 states when to use: when a form file is provided and the aim is to understand formatting to apply it identically. Does not mention when not to use or name specific alternatives, but context with sibling tools makes it clear.

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 the burden. It reveals internal heuristics (regex patterns) and reuse of other functions, offering moderate behavioral insight. However, it does not disclose safety or side effects (though it is likely read-only), nor does it describe any performance implications.

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. The first states the core functionality, and the second adds technical context. Although the regex patterns could be simplified for an AI agent, it is efficiently structured.

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?

Without an output schema, the description should explain the return format, but it does not. It also fails to mention performance considerations or how the output relates to sibling tools like hwp_get_document_info. Key aspects of the tool's use are 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. The description does not add any information about the parameters beyond what the schema provides. The mention of heading depth is tangentially related to max_depth but does not elaborate.

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 extracts tree structure (toc/sections/tables/fields) from a form document and identifies it as the entry point for user form analysis. This is specific and differentiates from many sibling tools, though it could explicitly contrast with similar tools like hwp_generate_toc.

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 mentions it is the 'entry point for user form analysis' but does not specify when not to use it or suggest other tools for different scenarios.

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 does not mention any behavioral traits such as whether the operation is destructive, reversible, or requires specific permissions. With no annotations, the description carries the full burden, but it only states the obvious action.

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 adding essential information: action, prerequisite, and alternatives. No superfluous content, and the main purpose is front-loaded.

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 prerequisite and alternatives, but lacks detail on error conditions, immediate effects, or saving behavior. Without output schema or annotations, more contextual completeness would be beneficial.

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 adds no additional meaning to the parameters beyond the schema. The prerequisite mention is a usage guideline, not parameter semantics.

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 fills values into document fields, using a specific verb and resource. It also distinguishes itself from sibling tools by providing explicit alternatives for documents without fields.

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 explicitly instructs to first use hwp_get_fields to check field names before using this tool, and provides alternative tools for when fields are absent. This gives clear when-to-use and when-not-to-use 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?

No annotations are provided, so the description carries full burden. It does not disclose behavioral traits such as whether it overwrites existing content, error handling, or side effects. For a modification tool, this is a significant gap.

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 three sentences, front-loaded with the main action and prerequisite. It uses an example efficiently, with 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?

Given the tool's complexity (nested arrays, multiple cell location methods), the description is minimal. It lacks information on error handling, return values, or detailed behavior. The schema is rich but the description doesn't fully contextualize usage among many table-related 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?

Schema description coverage is 100%, so baseline is 3. The description adds value by recommending label over tab/row/col for merged cells and giving an example, but does not significantly enhance understanding 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 verb 'fills values' and the resource 'table cells of the document.' It distinguishes from sibling tools by specifying that it's for filling table cells and recommends prerequisites (hwp_get_tables) and different methods (label, tab, row/col).

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 states to first check the table structure with hwp_get_tables, recommends label matching for merged cells, and provides an example. It also mentions alternative methods (tab, row/col). However, it does not explicitly state when not to use this tool or compare with siblings like hwp_fill_fields.

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 burden. It mentions color option and formatting preservation, but does not detail side effects, document state requirements, 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 sentences, no fluff. Critical information is front-loaded and each sentence adds value.

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 numerous siblings, description provides enough distinction for typical usage. Lacks specifics on search behavior (e.g., case sensitivity) but overall adequate.

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%; description adds minimal value such as mentioning color is optional. The phrase 'add text after found text' largely duplicates 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 tool finds text and appends after it, with color specification possible. It distinguishes from siblings like hwp_find_replace (replaces) and hwp_insert_text (inserts at cursor).

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 advises use when preserving formatting while adding text, providing a clear context. It does not explicitly exclude alternatives but implies a specific use 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?

With no annotations, the description bears full responsibility. It mentions regex and case sensitivity but does not disclose whether the replacement affects all occurrences, the selection, or the entire document. No mention of side effects, return value, or state changes.

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. It front-loads the core action and clarifies options. Could be slightly more structured but is 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?

Given no output schema, the description does not mention return values (e.g., success count). For a relatively simple tool with 4 parameters, it covers the basics but lacks completeness regarding outcomes and behavioral scope.

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 descriptions are already informative. The description reinforces the usage of 'use_regex' and 'case_sensitive' but adds minimal new value beyond the schema. Baseline 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 operation: find and replace text in the entire document. It mentions regex and case-insensitive options, making the purpose specific to a text replacement tool. However, it does not differentiate from sibling tools like 'hwp_find_replace_multi' or 'hwp_find_replace_nth'.

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 such as 'hwp_find_replace_multi' for multiple patterns or 'hwp_find_replace_nth' for specific occurrences. The description lacks contextual cues for selection.

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, and the description only mentions regex support via use_regex. It fails to disclose whether the tool modifies the document in place, is destructive, or any error behavior. This is a significant gap for a write 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?

Two sentences with no wasted words. Purpose is front-loaded, and the regex note is efficiently appended.

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 is too brief for a write operation with no output schema. It omits return behavior, error handling, prerequisites (e.g., open document), and other contextual details present in 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?

Schema coverage is 100% with adequate descriptions. The tool description adds minimal value beyond the schema, essentially restating that use_regex enables regex. 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?

Description clearly states it executes multiple find/replace operations in batch, distinguishing from single find/replace siblings by specifying '여러 건의' (multiple items). It also mentions regex capability.

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?

Description implies usage for batch replacements but provides no explicit guidance on when to use this versus alternatives like hwp_find_replace or hwp_find_replace_nth. No when-not-to-use or prerequisite information 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 must fully disclose behavior. It states that the tool modifies the document (replaces text), but does not mention what happens if the Nth occurrence does not exist, whether the operation is undoable, or any side effects. For a mutation tool, this is insufficient 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 description is three sentences, front-loaded with the main action, and provides a use-case statement and sibling differentiation. It is concise with no redundant information, though it could be slightly more structured (e.g., bullet-like).

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 tool's simplicity (3 parameters, no output schema, no nested objects), the description covers the purpose and usage context adequately. However, it lacks behavioral completeness (e.g., error cases, what happens if nth is out of range) and does not mention any prerequisites or document state requirements. This makes the description minimally viable but not fully comprehensive.

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 schema already provides clear descriptions for each parameter (find, replace, nth). The description adds contextual value by explaining the Nth behavior and distinguishing from AllReplace, but does not add new meaning to individual parameters beyond the schema. 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's action (replaces only the Nth occurrence of text in the document), identifies the resource (document), and explicitly distinguishes itself from siblings by contrasting with AllReplace. The verb '치환' (replace) and resource '문서' (document) are specific.

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 explicit guidance on when to use this tool: '같은 텍스트가 여러 곳에 있을 때 특정 위치만 바꿀 때 사용하세요' (use when you want to change only a specific location when the same text appears multiple places). It also contrasts with AllReplace, helping the agent choose. It lacks explicit when-not-to-use conditions, but the context is clear.

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 disclose behavioral traits. It does not mention side effects, read-only nature, required document state, or other implications.

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, each earning its place: first states function, second gives use case. No wasted words, front-loaded.

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, but description does not explain what the tool returns (e.g., list of field types/positions). Leaves ambiguity about output for a tool with no parameters.

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 zero parameters, schema coverage is 100%. Description adds no parameter info, but none is needed. Baseline 4 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?

Description clearly states the tool detects form fields (empty brackets, checkboxes, underlines) in a document, with a specific verb and resource. It distinguishes from siblings like hwp_fill_fields or hwp_get_fields by focusing on detection before filling.

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 states when to use: 'before filling out the form.' While it doesn't explicitly exclude alternatives, the context of siblings and the use case are clear.

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 key behaviors: auto_fix is no-op since v0.7.5.4, table_cell_overrides/field_overrides allow direct control, and phases have specific stopping points. However, it lacks detail on file modification side effects, error handling, and permissions.

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 main purpose and phase summary. It is somewhat verbose due to version details, but each sentence provides useful context. No wasted repetition.

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 12 parameters, nested objects, and lack of output schema, the description covers the workflow phases, auto_fix behavior, and override mechanisms comprehensively. It lacks return value description but otherwise provides sufficient context for an AI 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 schema already documents parameters. The description adds some value by explaining phase behavior (e.g., 'all' is read-only) and auto_fix settings, but much of the description mirrors 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 it is a form file attachment workflow with specific phases (learn, plan, preview, fill, verify, rollback). It distinguishes itself by describing the phase structure and read-only default. However, it is somewhat technical and could be more concise for an AI agent.

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 when to use each phase (e.g., 'fill' requires explicit user call, 'all' is read-only) but does not explicitly compare to sibling tools like hwp_fill_fields or hwp_fill_table_cells. An agent might benefit from guidance on when to choose this workflow over other form-related tools.

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 burden is on the description. It discloses a key behavior: the template is copied into separate files for each data entry, avoiding AllReplace scope problems. However, it does not mention other behaviors like error handling, output file naming, or performance implications, leaving some gaps.

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 deliver the purpose, a key behavioral detail, and a usage case. No redundancy or filler; each 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?

Given the complexity of the tool (multiple documents, nested data) and the absence of an output schema, the description could be more complete by mentioning the return value (e.g., list of generated files) or common pitfalls. However, the combination with the schema provides adequate context for tool selection.

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 parameters. The description does not add additional semantic meaning beyond what is in the schema. It mentions 'each data' and 'AllReplace' but these are implicit in the 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?

The description clearly states the tool generates multiple documents from a single template, with each document having its own data. It distinguishes from sibling tools by specifying batch generation for multiple entities, and gives a concrete use case: 'same form with multiple people/company data'.

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 says when to use this tool ('when filling the same form with multiple people/company data') and highlights an advantage (avoiding AllReplace scope issues). It does not explicitly state when not to use it or name alternatives, but the guidance is clear and contextual.

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 does not disclose side effects (e.g., whether it overwrites existing TOC, changes to styles, or requires save). For a document-modifying tool, more behavioral context is needed.

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?

Single, well-formed sentence that delivers the core purpose efficiently with zero extraneous 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?

Covers main functionality and insertion point. Lacks mention of potential side effects or parameter details, but for a single-param tool, it's reasonably 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% (1 parameter with description). The tool description adds no further explanation of dot_leader, so it meets the baseline but doesn't enhance understanding.

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 identifies the action (generate TOC), resource (current document based on heading patterns), and insertion point (cursor). Distinct from siblings that don't generate tables of contents.

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?

Description implies usage when a TOC is needed but does not specify prerequisites (e.g., heading styles must exist) or compare with other TOC-related tools. No explicit when-not-to-use 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?

With no annotations provided, the description carries full burden of behavioral disclosure. It does not state whether the tool is read-only, what the return format is (e.g., a Markdown string), or any limitations. The conversion behavior is implied but not detailed.

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, both relevant and informative with no unnecessary words. The description is front-loaded with the primary function.

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 basic conversion purpose and table handling but lacks details about the return structure (e.g., whether it returns a string or object) and any edge cases. Given no output schema, more detail would be beneficial.

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 a clear parameter description for 'file_path'. The tool description adds no additional meaning beyond the schema, meeting the baseline for high 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?

The description clearly states it converts document content to Markdown format and specifies how tables and text are handled, making the purpose easy to understand. However, it lacks explicit differentiation from sibling tools like hwp_get_document_text or hwp_export_html, though it implies Markdown is best for AI understanding.

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 tool versus alternatives. The phrase 'AI가 문서 내용을 이해하기 가장 좋은 형식입니다' suggests usage for AI consumption but does not provide concrete when-to-use or when-not-to-use scenarios.

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 description carries full burden. It implies a read operation but doesn't explicitly state it is read-only or non-destructive. No side effects mentioned. Adequate but could be clearer.

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: first defines functionality, second gives usage guidance. No wasted words. Front-loaded with 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?

Tool has 2 required params and no output schema. Description explains purpose and usage context well. Could mention return format or structure, but it lists formatting types (font, size, etc.) as indication.

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 both parameters. The description adds domain context (character/paragraph formatting) but no additional parameter details. 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?

Description clearly states it queries character and paragraph formatting of a specific table cell. It uses specific verbs ('조회합니다') and specific resources (글자서식, 단락서식). Distinct from siblings like set_cell_property or fill_table_cells.

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 advises to use this tool before filling a cell to understand its formatting for consistent input. Provides clear context of use, though doesn't specify 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?

No annotations provided; description fully conveys read-only nature and specific return values. No contradictions; honest about being fast and lightweight.

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 key information front-loaded. 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?

Fully sufficient given zero parameters and no output schema. Describes return values, usage context, and sibling differentiation.

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?

No parameters; schema coverage is 100% trivially. Baseline 4 for zero-parameter tool.

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?

Clearly states it returns lightweight metadata (page count, file path) of the open document. Distinguishes from sibling analyze_document by highlighting speed advantage.

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 describes when to use: for quick checks if document is open and page count. Compares to analyze_document to guide selection.

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 must cover behavioral details. It indicates a read operation but does not disclose if the document must be open, error handling, or output format, which are important for safe usage.

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 concise sentences in Korean, front-loaded with the action and use case, with 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?

Given the tool's simplicity (two optional parameters, no output schema), the description adequately covers purpose and usage, though it omits details on return format and edge cases.

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 adds no extra meaning to the parameters beyond what the schema already provides.

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 extracts body text from an open or specified file, and indicates usage for reading or searching, which distinguishes it from sibling tools like hwp_text_search.

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 a use case ('read or search content') but lacks explicit guidance on when not to use or comparison with siblings, leaving some ambiguity.

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 states '조회합니다' (retrieves), implying a read-only operation, but does not explicitly confirm no side effects, required permissions, or return behavior. Adequate for a simple read tool but lacks explicit assurances.

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 long, front-loads the key action and resource, and contains no unnecessary words. 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?

Given the tool's simplicity, the description covers purpose and usage context. No output schema exists, so the return format is not described, but the tool name and context imply a list of fields. Minor gap for full 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?

The input schema has 100% coverage, and the description adds no new meaning beyond the schema: both mention the optional file_path with '생략 시 현재 문서'. The description does not compensate or elaborate on parameter usage.

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 retrieves the list and current values of document fields (forms). The verb '조회' (retrieve) and resource are specific, and it differentiates from siblings like hwp_fill_fields by indicating it's for checking fields before filling.

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 states when to use the tool: '필드를 채우기 전에 어떤 필드가 있는지 확인할 때 사용하세요' (use it to check which fields exist before filling them). It does not explicitly mention exclusions or alternatives, but the context effectively guides usage.

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, and the description does not disclose any behavioral traits (e.g., read-only, side effects, prerequisites). The tool likely is read-only, but it is not stated, leaving the agent uninformed.

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. The purpose is front-loaded, followed by filtering options and a count. Excellent conciseness.

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 list tool, the description is reasonably complete: it states the output, filtering, and scope. However, it lacks behavioral context like whether a document must be open or if the list is static, but the tool's simplicity 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 provides full descriptions, but the description adds value by listing example category values (serif/sans/display) and mentioning the filter for government documents ('gov'). It also notes the font count (40+), 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 it returns a list of available Korean fonts, with specific filtering options (category and government documents). This distinguishes it from siblings that perform document manipulation or other operations.

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 on when to use this tool versus alternatives. There is no indication of prerequisites or preference over other font-related tools, which are absent from 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?

No annotations are provided, so the description must carry the burden of behavioral disclosure. It states the tool 'reads' (read-only) and returns specific fields, but does not mention prerequisites (e.g., document must be open), side effects, error conditions, or performance implications. The description adds value by listing return fields, but falls short of full 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 a single sentence that contains all necessary information: the action (reads page setup), the scope (current document), and the return fields. Every word is meaningful, with no redundancy or waste.

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 output schema, the description effectively explains the return value by listing all fields. It covers what the tool provides without missing critical information. However, it could be more structured (e.g., specifying data types) or include error handling context, but overall it is sufficiently complete for a simple read operation.

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). According to guidelines, 0 parameters yields a baseline score of 4. The description does not need to add parameter meaning, so this 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 explicitly states the tool reads page setup of the current document and lists all returned fields (paper size, orientation, margins, etc.). It clearly distinguishes from the sibling 'hwp_set_page_setup' which writes page setup, so the purpose is specific and unambiguous.

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 clear context that the tool reads the current document's page setup, implying use when page setup information is needed. However, it does not explicitly state when not to use it or mention alternatives (e.g., use hwp_set_page_setup for modification), but the read-only nature is clear from the verb 'reads'.

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 describes the basic read-only behavior (text extraction) but does not detail return format, prerequisites (e.g., document must be open), or any side effects. For a simple extraction tool, this is minimally acceptable.

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