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 that the tool clones the last paragraph's structure (paraPr/charPr/style refs) and replaces text, which goes beyond the input schema. However, it does not mention any required permissions or side effects beyond appending.

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

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

The description is two sentences, front-loaded with the core action. No unnecessary words; every 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 the tool's simplicity (3 parameters, no output schema, no nested objects), the description covers the essential behavior. It explains cloning and replacement. Minor omissions: no mention of file existence handling or error cases, but acceptable for a straightforward append 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 description coverage is 0%, so the description must compensate. It lists the parameter names ('file_path, text, output_path (optional)') but does not explain their types, formats, or constraints. The schema itself only provides types (string). The description adds minimal meaning beyond the names.

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 'Append a new paragraph to the end of an .hwpx document body.' It uses a specific verb (Append) and resource (paragraph), and distinguishes from siblings like append_hwp_table_column or append_hwp_table_row.

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. With 31 sibling tools, context on when to prefer this over e.g., set_hwp_paragraph_text or insert_hwp_table would be helpful but is missing.

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 fully disclose behavior. It states the column is appended and clarifies the 'cells' parameter format (JSON string array per row). However, it omits whether the file is modified in-place or a new file is created (output_path optional implies default overwrite), error behavior for invalid table_index, or side effects.

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 purpose, second specifies cells format and lists arguments. No redundancy, efficient, and 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?

For a file-modifying tool with 4 parameters and no output schema, the description lacks critical details: expected file_path format, behavior on invalid table_index or mismatched cells length, whether original file is overwritten by default, and any restrictions. Significant gaps.

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 0%, so description must compensate. It explains 'cells' as a JSON string array of cell texts top-to-bottom but provides no semantics for file_path, table_index (0-based?), or output_path defaults. Partial value added but insufficient for all 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 explicitly states the action: 'Append a new column to the Nth table in an .hwpx.' This specific verb ('append') and resource ('column to table') clearly distinguish it from siblings like 'append_hwp_table_row' or 'delete_hwp_table_column'.

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 (e.g., set_hwp_cell_text, fill_hwp_template). No prerequisites, exclusions, or context for when this operation is appropriate.

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 convey behavioral traits. It mentions appending a row and cell length constraint but omits critical details: error handling (e.g., invalid table_index), side effects (modifies original file if output_path omitted), and required permissions. This is insufficient 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 brief (two sentences) and front-loaded with the key action. However, it could be better structured by separating parameter details into a list. Still, it is efficient and avoids redundancy.

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

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

Given the tool's complexity (modifying an .hwpx table) and lack of output schema, the description covers the core operation but lacks details on error scenarios, file handling, and constraints. It is minimally adequate but not comprehensive for an AI agent to invoke reliably.

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 0%, so the description must compensate. It explains that 'cells' is a JSON string array and must match column count, and lists parameters and output_path optionality. However, it does not clarify file_path (path to .hwpx), table_index (0-based), or output_path semantics beyond 'optional'. Adds some value but not fully detailed.

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: 'Append a new row to the Nth table (0-based) in an .hwpx.' It uses specific verb and resource, and is distinguishable from sibling tools like append_hwp_paragraph and delete_hwp_table_row.

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 basic usage context (e.g., cells must match column count) but does not explicitly state when to use this tool versus alternatives like set_hwp_cell_text or append_hwp_table_column. No exclusion criteria 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?

With no annotations, the description adds valuable behavioral details: it modifies header.xml by adding a new paraPr and retargets the paraPrIDRef. This discloses internal file structure changes, though it could mention handling of invalid paragraph indices or overwriting behavior.

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

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

The description is brief and front-loaded with the core purpose. It uses a structured list for align values. One minor improvement would be to separate parameter details more clearly, but overall it 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?

With 6 parameters, no output schema, and no error handling notes, the description provides a basic functional overview but lacks details on file_path format, paragraph_index bounds, units for indent/line_spacing, and return value. The internal file structure detail partially compensates.

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

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

The schema has 0% parameter descriptions, so the description fully compensates by enumerating acceptable align values (LEFT|CENTER|RIGHT|JUSTIFY|DISTRIBUTE), clarifying that align/indent/line_spacing are optional subsets, and noting output_path is optional. However, file_path and paragraph_index lack format hints.

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 paragraph formatting (alignment, indent, line_spacing) to a specific paragraph by index in an .hwpx file. The verb 'apply' and resource 'paragraph style' are unambiguous, and it distinguishes from sibling 'apply_hwp_text_style' which handles text-level styling.

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 paragraph-level formatting but does not explicitly state when to use it over alternatives like 'apply_hwp_text_style' or 'set_hwp_paragraph_text'. No exclusionary conditions or context for use 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?

The description discloses internal behavior (adding charPr to header.xml, retargeting <hp:run>) and specifies color format. No annotations exist, so the description carries the burden; it mostly succeeds but omits details like what happens if target_text is not found.

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-loading the purpose and concisely listing parameters. Every sentence adds 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?

Given no output schema and no annotations, the description explains the tool's operation and parameters well. Minor gaps: no error handling, no mention of behavior when multiple runs contain target_text. Overall, it is sufficiently complete for a tool of this complexity.

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

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

With 0% schema description coverage, the description fully explains all parameters: file_path, target_text, color (with hex example), bold/italic/underline (boolean), font_size (number), and optional output_path. This adds significant meaning beyond the bare property names.

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 applies formatting (color/bold/italic/underline/font_size) to the first run containing target_text, distinguishing it from sibling tools like apply_hwp_paragraph_style which formats paragraphs.

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 formatting the first run with target text, but does not explicitly state when not to use it or provide alternatives. The context of siblings suggests other formatting tools exist, but no exclusion 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?

The description discloses key behaviors: it creates a new file, and tables are rendered as flat text in v0.2. However, it does not mention if it overwrites existing files or error conditions. Since no annotations are provided, this is a good disclosure of behavioral traits.

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 only two sentences. The first sentence states the primary purpose, and the second adds a note about table rendering and lists the arguments. Every sentence is informative and 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?

Given the tool's complexity and no output schema, the description covers the input format well but does not mention success/error responses or what happens on file overwrite. For a creation tool, some additional context on behavior 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?

With 0% schema description coverage, the description adds significant value by specifying that output_path must end with '.hwpx' and content is a JSON string. It describes the expected JSON structure (list of {type:'text',text} items) and tables, which goes 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 creates a new .hwpx file from a JSON content list, specifying item types like text and table. This distinguishes it from sibling tools that manipulate existing files, such as append_hwp_paragraph or insert_hwp_table.

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 input format but does not provide explicit guidance on when to use this tool versus alternatives. It gives instructions on the JSON content structure but lacks context on usage scenarios or prerequisites.

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 the description must carry the full burden. It discloses the operation (delete) but does not mention side effects (e.g., file modification, destruction), prerequisites, or error conditions. The term 'delete' implies mutation, but more detail is needed for safe agent 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 extremely concise—one sentence plus a parameter list—with no wasted words. It front-loads the action, making it easy to parse quickly. However, a more structured format (e.g., bullets) could improve readability.

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

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

Given the complexity (3 parameters, no output schema, many siblings), the description is insufficient. It does not explain the return value, whether the file is modified in place or a new file created, nor its relationship to other image tools like insert_hwp_image or replace_hwp_image.

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 0%, so the description must compensate. It lists all three parameters and clarifies 'target' as basename or full entry and 'output_path' as optional. This adds basic meaning beyond the bare schema, but lacks details like format or constraints (e.g., file_path must be a valid .hwpx).

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 deletes a BinData/ZIP entry inside an .hwpx file, effectively removing embedded image bytes. It uses a specific verb (delete) and resource, and distinguishes from sibling tools like delete_hwp_paragraph by focusing on image removal.

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 such as replace_hwp_image or other deletion tools. The description implies usage for removing images but lacks when-not or context 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 are provided, so the description must disclose behavioral traits. It does not specify whether the operation modifies the file in place, what happens if output_path is omitted, or any side effects. The agent is left uncertain about the tool's impact.

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

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

The description is a single, front-loaded sentence that efficiently conveys the core action. It is concise with no unnecessary words, though it could be slightly more structured to separate the purpose from parameter hints.

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 deletion tool with no annotations, the description omits critical information such as error handling (e.g., invalid index), file existence requirements, and default behavior when output_path is not specified. The tool's overall behavior is not fully specified.

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 description adds minimal value beyond the schema by noting that index is 0-based and that output_path is optional. Given 0% schema description coverage, this is helpful but still lacks details like file_path format or range constraints for index.

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 (delete), the resource (paragraph), the source (.hwpx body), and the indexing scheme (0-based). It is specific and distinct from sibling tools that delete images or table elements.

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 given on when to use this tool versus alternatives like delete_hwp_image or delete_hwp_table_row. There are no prerequisites or conditions mentioned, leaving the agent to infer 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?

No annotations are provided, so the description bears the full burden. It reveals that the operation removes <hp:tc> elements from every row, which is useful. However, it does not indicate whether the file is modified in place or if output_path (optional) changes behavior. The destructive nature is implied but not explicitly stated.

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, no redundant information. It front-loads the action and then lists arguments. Could be slightly more structured (e.g., bullet list), but it is efficient 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 complexity (4 parameters, optional output, no output schema), the description lacks completeness. It does not explain what happens if output_path is omitted, error handling, file size limits, or any side effects. The behavioral detail on <hp:tc> removal is a plus, but overall, essential context is missing.

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

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

Schema description coverage is 0%, meaning the description must compensate. It lists the parameter names but adds no additional meaning—e.g., file_path format, table_index meaning (0-based?), col_index 0-based confirmed in action but not in args section, output_path behavior when omitted. The description provides minimal semantic value beyond the schema.

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

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

The description clearly states the tool's action: 'Delete the Mth column (0-based) from the Nth table in an .hwpx'. It specifies the resource (column in table), the file type (.hwpx), and provides technical detail about what is removed ('removes one <hp:tc> from every row'). This distinguishes it from sibling tools like delete_hwp_table_row or delete_hwp_image.

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 use when needing to delete a column from a table, but it does not explicitly guide when to use this tool versus alternatives. No mention of prerequisites, limitations, or when not to use. Siblings include other deletion tools, but no comparative guidance 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?

No annotations are provided, so the description carries full burden for behavioral disclosure. It states the tool deletes a row (destructive action) but does not mention whether it modifies the file in place or requires output_path, permissions, or side effects. This is insufficient 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 a single sentence that is front-loaded and concise, but it omits important details. It is adequate but not well-structured; the reference to 'Args' is informal.

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 and no parameter descriptions, the description is incomplete. It does not explain return values, error conditions, or behavior when output_path is omitted. For a tool with 4 parameters and no sibling differentiation, more context is needed.

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

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

Schema description coverage is 0% (no parameter descriptions), and the description only lists parameter names without adding meaning like allowed values, formats, or constraints. The optional output_path is mentioned but not explained.

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 (delete a row) and the resource (table in an .hwpx file) with precise 0-based indexing. It distinguishes from siblings like delete_hwp_table_column and delete_hwp_paragraph by specifying table and row indices.

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 vs alternatives. It does not mention prerequisites, when it is appropriate, or when other tools (e.g., delete_hwp_table_column) would be better.

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 cover behavioral traits. It mentions that output_dir is optional with a default, but fails to disclose key behaviors like file overwrite policy, image format, error handling, or performance implications for large files.

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

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

The description is extremely concise with two short sentences, front-loaded with the action. Every word adds value; no unnecessary details.

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 two parameters, the description covers the essential operation and parameter defaults. However, it lacks details on what the tool returns (e.g., success status, list of saved files) and does not address potential errors, making it moderately 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 description coverage is 0%, so the description must compensate. It identifies file_path and output_dir, explains output_dir's default, but does not clarify file_path's expected format or specify allowed values beyond being strings. Some value added, but insufficient given the lack of 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 'Save every embedded image to disk,' specifying the exact action and resource. This distinguishes it from sibling tools like delete_hwp_image, insert_hwp_image, and list_hwp_images, which perform different operations on images.

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 a usage context (extracting images from a file) but does not explicitly state when to use this tool versus alternatives. No guidance on prerequisites, limitations, or when not to use it 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?

No annotations provided; description does not disclose whether the tool modifies the original file or creates a new one, how missing placeholders are handled, or any side effects. The optional output_path is mentioned but not 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?

Description is concise, with two clear sentences and a version note. Information is front-loaded. Could be slightly more structured but 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?

Lacks explanation of return value, error handling, and behavioral details. With no annotations and no output schema, the description should provide more context for an AI agent to use the tool 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?

The description adds meaning for 'replacements' by specifying it is a JSON object string and giving an example. However, 'file_path' and 'output_path' lack additional context 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?

Clearly states the tool fills multiple placeholders in an HWPX template, specifying version and file type. However, it does not differentiate from sibling tools like replace_hwp_text or set_hwp_field_value.

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 a usage example but no guidance on when to use this tool over alternatives. Does not explain prerequisites or context for 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?

With no annotations, the description must disclose behavioral traits. It implies a read operation but omits details on return format, error cases, permissions, or side effects.

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, using one sentence and an arguable listing. Every word is essential, and the core action 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?

Given the tool's complexity (2 params, no output schema, many siblings), the description is too sparse. It fails to specify return values, error handling, or relationships to sibling tools.

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

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

Schema description coverage is 0%. The description adds minimal semantics by stating 'by name' for the name parameter, but file_path remains undefined. Partially compensates for schema gaps.

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 ('Get'), resource ('Hancom field'), and qualifier ('by name'), distinguishing it from sibling tools like list_hwp_fields and set_hwp_field_value.

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 (e.g., list_hwp_fields, read_hwp), nor any prerequisites or conditions.

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 fails to disclose any behavioral traits such as read-only nature, error handling, or side effects. Full burden on description, which only states what metadata is retrieved.

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?

Extremely concise single sentence with no fluff. Could benefit from structured listing of metadata, but overall efficient and 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?

Missing critical details: no output schema, no hint on return format (JSON/string), no description of error cases (invalid path, unsupported file). Incomplete for a metadata retrieval tool.

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

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

Schema description coverage is 0%, and the description only repeats 'file_path' without adding any format, restrictions, or semantics beyond the schema. No compensation for the lack of schema documentation.

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 (Get) and the resource (document metadata), and lists specific metadata items (version, page count, etc.) distinguishing it from sibling tools that extract content.

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 like read_hwp or read_hwp_tables. The agent must infer its purpose from the metadata focus without 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 carries the full burden. It describes what data is retrieved but does not disclose whether the operation is read-only, if it accesses the file system, or any side effects 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 three short, front-loaded sentences with no unnecessary information. Each sentence serves a purpose.

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

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

For a simple one-parameter tool with no output schema, the description covers the basic purpose and return value. However, it lacks mention that the tool reads files or is read-only, which 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 description only adds 'Args: file_path' without explaining what the parameter expects (e.g., path type, file format). With 0% schema description coverage, more detail 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 retrieves per-section page definition including paper size, margins, columns, and section properties. This is specific and distinguishes it from sibling tools like read_hwp or render_hwp_page.

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 says it is 'useful for understanding document layout' which implies context but provides no explicit guidance on when to use versus alternatives, nor any when-not-to-use conditions.

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 carry full burden. It explicitly states the tool modifies the .hwpx file structure: adds to BinData/, registers in content.hpf, appends paragraph with inline image. This discloses side effects beyond a simple 'insert' verb, though missing error conditions (e.g., duplicate names, unsupported ext).

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 front-loaded with the action and key details. The argument list is appended succinctly. No extraneous words; every part 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 4 parameters and no output schema, the description adequately covers the tool's action and side effects. However, it omits the return value (e.g., success indicator or new image ID) and does not explain behavior when output_path is omitted. Still, it provides enough for basic agent 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 description coverage is 0%, forcing the description to define parameters. It lists four args and clarifies ext auto-detection and output_path optionality, but does not fully explain file_path (presumably the target .hwpx) or source_path (image source). The argument list adds value over the raw schema but lacks complete 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 uses a specific verb ('Insert') and resource ('image into an .hwpx'), and lists exact file system operations (adds to BinData/, registers in content.hpf, appends inline <hp:pic>). This clearly distinguishes the tool from siblings like replace_hwp_image or delete_hwp_image.

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 lists arguments and notes ext auto-detection and optional output_path, but does not specify when to use this tool over alternatives (e.g., replace_hwp_image) or mention prerequisites like the .hwpx file being open or existing. Usage context is only implied through the action description.

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 for behavioral disclosure. It explains the JSON format for headers and rows but omits critical details such as error handling, overwriting behavior, permission requirements, or what happens if the file does not exist. It does not state whether the table is appended to existing content or requires an empty 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?

Description is two sentences and front-loads the core purpose. The second sentence is a bit run-on with 'Args:' but conveys necessary parameter info concisely. Could be more scannable with bullet points, but 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?

Given no output schema and no annotations, the description should cover inputs, behavior, and output. It covers input formats but omits what the tool returns (success indicator, error messages, created table details). Behavior for optional output_path is not described. Missing behavioral constraints for a tool that modifies files.

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 0% (properties have only type string, no descriptions). The description adds significant meaning by explaining file_path as path to .hwpx file, headers as JSON array of strings (single-row), rows as array of row arrays, and output_path as optional. It clarifies the expected JSON structure for parameters, compensating for the schema's lack of detail.

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 action ('Insert'), resource ('real OWPML table at the end of an .hwpx body'), and specifies the structural elements (<hp:tbl>/<hp:tr>/<hp:tc>). This differentiates it from siblings like append_hwp_table_row (which adds rows to existing tables) or insert_hwp_image (different resource).

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

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

The description does not provide explicit guidance on when to use this tool versus alternatives like append_hwp_table_column or merge_hwp_cells_horizontal. It mentions inserting 'at the end' but lacks direction on prerequisites, conditions for use, 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 exist, so the description carries full burden. It implies read-only operation ('List... entries') but does not elaborate on side effects or performance. Adequate for a straightforward listing 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?

Extremely concise—two sentences covering purpose, scope, and usage hint. No extraneous text. Front-loaded essential 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 no output schema and single parameter, the description sufficiently explains the tool's function and context. Could mention return format but not essential for usability.

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

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

Only one parameter (file_path) with 0% schema description coverage. The description repeats the parameter name ('Args: file_path') but adds no additional meaning or constraints 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?

Clearly states the tool lists ZIP entries under BinData/ in .hwpx files, specifically image and binary attachments. Differentiates from siblings by mentioning its utility before replace_hwp_image.

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 a usage hint ('Useful before replace_hwp_image') that guides the agent on when to use it among siblings. Lacks explicit when-not-to-use but is sufficient for a simple tool.

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 listing fields with name and type, which implies a read-only operation, but does not explicitly state non-destructiveness or any side effects.

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 short and to the point, with a clear statement of function and a brief mention of the argument. It earns its length without unnecessary 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?

For a simple list tool with one parameter and no output schema, the description covers the main purpose and usage context. However, it could be improved by describing the return format or expected output.

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 0% with no description for file_path. The description merely says 'Args: file_path' without adding format or constraints, failing to compensate for the missing schema information.

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 lists Hancom-style fields with name and type, and mentions its usefulness before fill_hwp_template. This distinguishes it from sibling tools like get_hwp_field_value or fill_hwp_template.

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 'Useful before fill_hwp_template', providing a clear use case. It does not list alternatives or when not to use, but the context 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 exist, so the description carries the burden. It says 'list' but doesn't confirm read-only behavior, permissions, or whether it reads the entire file. Minimal behavioral insight beyond the action itself.

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. Efficiently conveys the action and main parameter.

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 minimal parameter info, the description omits return format, error handling, or usage examples. For a simple tool it's somewhat adequate but lacks completeness.

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

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

Schema description coverage is 0%, so the description must compensate. It adds 'HWP/HWPX file' context and notes the parameter name, but doesn't explain what file_path should be (absolute path, relative, etc.). Only marginal help.

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 lists embedded images with specific attributes (mime, byte length, locator) in HWP/HWPX files. It distinguishes from siblings like extract_hwp_images by using 'list' instead of 'extract', though it doesn't explicitly name alternatives.

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 like extract_hwp_images or list_hwp_bindata. Lacks context about prerequisites or limitations.

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 mentions the mechanism (colSpan) and that col_count >=2, but does not explain if the operation is destructive, error handling, or what happens when output_path is omitted (e.g., modifies original file).

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 only two sentences: the first states the purpose and method, the second lists arguments. It is front-loaded but could be more structured with bullet points.

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 6 parameters, no output schema, and no annotations, the description lacks completeness. It does not specify indexing conventions, default behavior, error conditions, or when to choose horizontal vs vertical merge.

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

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

The schema has 0% description coverage. The description adds a constraint (col_count >=2) and marks output_path as optional, but does not explain the meaning of other parameters like row, col_start, table_index (e.g., zero-indexed) or file_path 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 tool merges horizontal cells in a table row by setting colSpan and removing absorbed cells. It includes specific verb and resource, and distinguishes from the sibling merge_hwp_cells_vertical.

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 lists required arguments but provides no guidance on when to use this tool versus alternatives like merge_hwp_cells_vertical. There are no conditions, prerequisites, or exclusions 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?

With no annotations, the description carries the full burden. It discloses that the tool sets rowSpan and removes absorbed cells, but does not explain whether the original file is modified in-place, if a backup is created, or what happens when output_path is omitted. Safety-relevant behaviors (e.g., destructive potential) are under-communicated.

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 brief and front-loaded with the action and mechanism. However, it can be improved by separating the parameter list into a clearer structure, such as bullet points.

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 cell merging (a destructive operation) and zero annotations or output schema, the description is incomplete. It lacks error conditions (e.g., overlapping merges, out-of-bounds), return value information, and implications of optional output_path. The tool’s behavior is under-specified.

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 0% so the description must explain each parameter's meaning. It lists parameter names and notes row_count >=2, but fails to define indices (e.g., zero-based vs. one-based), valid ranges, or the role of output_path. The col and row_start descriptions are missing crucial numerical context.

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 merges vertical cells across rows in a single column, and explains the mechanism (rowSpan). However, it does not distinguish itself from the sibling tool 'merge_hwp_cells_horizontal' explicitly, leaving a gap for agents needing to choose between them.

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 parameter constraints (row_count >=2) but offers no guidance on when to use this tool versus alternatives. It does not mention that horizontal merging is handled by a sibling tool or specify prerequisites like table existence.

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 does not disclose behavioral traits such as error handling, file existence checks, permissions, or size limits. It only lists output types but no 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 extremely concise with one sentence plus an Args line. It is front-loaded and contains no unnecessary text.

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 param, no output schema), the description provides essential information but lacks behavioral details and output format specifics, leaving completeness 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?

The description adds meaning for the only parameter 'file_path' by specifying it must be an absolute path, which the schema does not include. This compensates for the 0% schema description 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 reads full HWP/HWPX content as text, tables (markdown), and image listing. It distinguishes from sibling tools that read specific parts like read_hwp_text or read_hwp_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?

The description implies usage for full content extraction but does not explicitly state when to use this tool versus siblings. It lacks when-not or alternative 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 only states the basic action without disclosing error handling, file size limits, or behavior when no tables are present.

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 sentence is concise but lacks structure; the action is front-loaded but provides minimal 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?

For a simple one-parameter tool, the description omits important context such as output format details, handling of multiple tables, or error conditions.

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 0%, and the description merely restates 'file_path' without adding format, validation, or constraints 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?

Clearly states it extracts every table from HWP/HWPX files to GitHub-flavored markdown, which distinguishes it from sibling tools like read_hwp_text or extract_hwp_images.

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 information on when to use this tool versus alternatives like read_hwp or read_hwp_text, nor any prerequisites or exclusions.

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

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

Discloses that tables and images are not extracted, but does not mention return format, error handling, or path validation. With no annotations, more behavioral context would be helpful.

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 the main purpose. The second sentence adding 'Args: file_path' is redundant given the schema, but overall 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?

For a simple extraction tool with one param and no output schema, the description covers what is extracted but omits what is returned (e.g., plain text string) and any success/error conditions.

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 single parameter 'file_path' is only named in the description with no added semantics. Schema coverage is 0%, so the description should clarify expected path format or requirements, which it does not.

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

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

The description uses a specific verb ('Extract') and resource ('plain body text from an HWP/HWPX file') and explicitly excludes tables and images, distinguishing it from related sibling tools like read_hwp_tables and read_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 on when to use this tool versus alternatives, no prerequisites or exclusions stated beyond the extraction scope.

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

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

No annotations are provided, so the description must disclose behavioral traits. It mentions rendering to SVG files in a directory, which is clear, but lacks details on side effects like directory creation, overwriting, or error handling for large files.

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 with a parenthetical listing of parameters, ensuring front-loading of purpose with no extraneous text. Every word 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 has 3 parameters and no output schema, the description covers purpose and parameters but omits information about return values, side effects, and typical use cases. It is acceptable 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 properties have no descriptions (0% coverage). The description adds meaning by specifying defaults (output_dir defaults to '<file>_pages/') and noting max_pages is optional, which goes beyond the raw schema.

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

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

The description clearly states the tool renders every page of an HWP/HWPX file as SVG files, which is a specific verb-resource combination. It distinguishes from sibling tools like render_hwp_page, which renders a single page.

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 rendering all pages (vs. single page via render_hwp_page) but does not explicitly state when to use this tool or provide exclusions or alternatives beyond the implicit sibling contrast.

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

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

No annotations exist, so description must cover behavior. It only states the action and defaults but does not disclose side effects, permissions, error handling, or return value format.

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 sentence with args listed efficiently. No redundant words, fully 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?

Simple tool, but missing output type (SVG string vs. file path) and error conditions. Acceptable for a straightforward rendering tool but not fully complete.

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

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

Schema has 0% description coverage. The description adds an example for script, units for font_size, and defaults for both font_size and color. However, the color parameter's format remains unspecified.

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?

Clear verb ('render'), resource ('OWPML equation script'), output ('SVG'), and a concrete example. Distinct from sibling tools like render_hwp_page which render whole pages.

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 rendering equation scripts via the example and name. No explicit when-not-to-use or alternatives, but sibling names provide sufficient differentiation.

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. Discloses page parameter 0-based and default 0, and output_path optional. However, does not mention any behavioral traits like file access requirements or output format (e.g., returns string vs. writes to file).

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: first states purpose, second lists parameters with key details. No extraneous text, front-loaded 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?

Description is adequate for a simple tool with no output schema or annotations. But lacks details on return value (e.g., whether it returns HTML string or writes to output_path) and fails to mention any prerequisites 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?

With 0% schema description coverage, description provides all parameter info: file_path, page (0-based, default 0), output_path (optional). Adds value beyond bare schema via defaults and 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?

Clearly states 'Render a single page of an HWP/HWPX as HTML.' Differentiates from sibling tools like render_hwp_all_pages by specifying single page, and from render_hwp_equation_svg by targeting HTML output.

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

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

States 'Useful for AI consumption when SVG isn't ideal,' providing some context but not explicit when-to-use vs. alternatives like render_hwp_page or render_hwp_all_pages. No direct exclusions.

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

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

No annotations provided, so description must carry full burden. Describes output behavior (inline vs file) but omits details on side effects, permissions, or error handling. Adequate but not exhaustive.

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 plus args list, front-loaded with purpose. No wasted words, but could integrate args more naturally.

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 3-parameter render tool with no output schema or annotations, the description covers key aspects: purpose, SVG output, and dual mode (inline/file). Lacks error handling or format constraints but sufficient.

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 0%, but description adds meaning: explains page is 0-based with default 0 and output_path is optional. Adds value beyond the raw schema.

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

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

States 'Render a single page of an HWP/HWPX document as SVG.' Uses specific verb+resource, clearly distinguishing from sibling tools like render_hwp_all_pages and render_hwp_equation_svg.

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

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

Explains that omitting output_path returns inline SVG string, useful for LLM consumption. Provides args list. Lacks explicit when-not and alternative sibling tools, but 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 are provided, so the description carries full burden. It discloses the overwrite mechanism and that target accepts basename or full path, but lacks details on output behavior when output_path is omitted, permissions needed, or side effects on the original file.

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 sentence front-loads the main purpose, and the second adds parameter notes. However, the parameter list is somewhat terse, but overall it 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?

For a file-modification tool with 4 parameters and no output schema, the description lacks clarity on the outcome when output_path is omitted (e.g., in-place modification) and error handling when target doesn't exist. More behavioral context is needed.

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

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

Schema description coverage is 0%. The description only elaborates on the 'target' parameter (basename vs full path), while 'file_path' and 'source_path' are merely listed. This adds minimal semantic value beyond the schema for most 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 it replaces an embedded image in an .hwpx file by overwriting the BinData/ZIP entry, with a specific verb and resource. This distinguishes it from siblings like delete_hwp_image or insert_hwp_image.

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 replacing images but does not explicitly state when to use this tool versus alternatives like insert_hwp_image or delete_hwp_image. No exclusions or guidance on prerequisites 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?

No annotations are provided, so the description must disclose behavioral traits. It mentions version and format support but does not state whether the operation is destructive, modifies files in-place, or requires specific permissions. The optional output_path suggests behavior but is not 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 very concise (two sentences) and front-loads the purpose. It includes a version note and lists parameters efficiently. However, it could be slightly more structured (e.g., separate parameter explanations) without adding 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?

Given the lack of annotations, output schema, and 0% parameter coverage, the description is incomplete. It does not explain return values, error behavior, or how it interacts with the file system. The sibling tools list suggests many alternatives, but the description provides no contextual 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?

Schema description coverage is 0%, so the description should compensate. It lists the four parameters (file_path, old_text, new_text, output_path) but adds no semantic detail beyond their names. For example, it does not clarify if old_text supports regex or what happens if output_path is omitted.

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 ('Find and replace text'), the target resource ('HWPX file'), and distinguishes from siblings by specifying the operation type. The mention of 'v0.2: only .hwpx is supported' adds precision.

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

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

The description provides a constraint (only .hwpx) but no explicit guidance on when to use this tool versus alternatives like set_hwp_cell_text or replace_hwp_image. The typical use case of find-and-replace is implied but not differentiated.

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 only says 'Replace'. Does not disclose whether the file is modified in-place or a new copy; error handling (e.g., missing cell) not mentioned. Behavior like overwriting existing text is implied but not explicit.

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

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

One sentence plus parameter list; no fluff. Front-loaded with purpose. Could be structured with bullet points for readability, but current form 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?

Missing return value info (success? new path?), error cases (cell out of bounds, file not found), and dependencies (file must have table). With no output schema and 6 parameters, more context is needed for correct usage.

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

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

Description adds value by specifying coordinates are 0-based and output_path is optional. Schema coverage is 0%, so this is minimal but helpful. Parameter names are self-explanatory, but deeper semantics (e.g., what table_index refers to) are not clarified.

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 and target: 'Replace a single cell's text in a table inside an .hwpx.' It lists the parameters, including coordinate base. However, it does not differentiate from similar siblings like set_hwp_paragraph_text or merge 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?

No guidance on when to use this tool versus alternatives (e.g., append, merge, replace text). No mention of prerequisites (e.g., file must exist, table must exist at table_index).

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 details the XML-level insertion but lacks clarity on side effects (e.g., overwrite vs. append), error handling (e.g., field not found), and whether output_path allows in-place modification.

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, consisting of two sentences followed by a parameter list. It is front-loaded with the core action and wastes no 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 write nature and absence of output schema, the description should cover prerequisites (referenced list_hwp_fields), but misses error cases, behavior when field is missing, and the effect of output path omission. It 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?

With 0% schema coverage, the description merely lists parameter names (file_path, name, value, output_path) and labels one as optional. It does not explain their types, constraints, or formats, failing to compensate for the missing 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 explicitly states the tool sets a Hancom field value by name in an .hwpx file, describing the mechanism of writing between XML tags. It clearly distinguishes from sibling tools like get_hwp_field_value and fill_hwp_template.

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 directs users to use list_hwp_fields first to discover field names, providing a prerequisite action. However, it does not explicitly specify when not to use this tool or mention sibling alternatives beyond the implied distinction.

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 paragraph attributes are preserved and runs are collapsed into a single run. However, it does not mention side effects like in-place modification when output_path is omitted, or error handling. Without annotations, more detail would be helpful.

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 plus an args list, with no redundant information. Every sentence provides distinct, useful details. 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?

The description covers core behavior and parameter list, but lacks details about file format requirements, in-place modification behavior when output_path is omitted, and potential error conditions. Given no output schema and moderate complexity, it is adequate but not 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 description coverage is 0%. The description lists parameter names but does not explain their formats, constraints, or valid values. For example, index is 0-based and file_path must be a valid file path. This minimal information adds little beyond the parameter names.

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 'Replace', the resource 'Nth paragraph in an .hwpx body', and specifies that attributes are preserved and runs are collapsed. It distinguishes from sibling tools like set_hwp_cell_text.

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 use for replacing paragraph text, but does not explicitly state when to use this tool over alternatives like append_hwp_paragraph or apply_hwp_paragraph_style. No exclusion or context for 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.