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

With no annotations, the description carries the full behavioral burden. It hints that a column can be inserted at a position index, but says nothing about whether existing columns shift, permission requirements, idempotency, or what happens when values/width are omitted. For a mutating table tool this is a substantial gap.

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

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

A single front-loaded sentence that wastes no words and leads with the core action. It is efficient, though slightly thin for the amount of undocumented behavior it must cover.

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

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

An output schema exists, so return values need not be explained. However, for a mutating tool with no annotations and 0% schema coverage, the description should say more about insertion side effects and defaults; it is minimally adequate rather than 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 maps three of the five parameters to meaning (optional cell text = values, optional width = width_inches, optional position index = insert_index), while file_path and table_index are self-explanatory. It still omits format details such as default width behavior or how values align to rows, so compensation is partial.

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

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

The description states a specific verb and resource: adding/inserting a column in a docx table, which clearly separates it from column-unrelated siblings. It does not explicitly name or contrast with add_row_docx or delete_column_docx, but the resource (column) makes the intent unambiguous.

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

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

There is no when-to-use guidance, no prerequisites, and no mention of alternatives such as add_row_docx or delete_column_docx. The agent can infer it inserts columns into an existing table, but nothing routes it here versus other table-editing tools.

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

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

Without annotations, the description carries the full burden. It discloses supported input formats, block/inline modes, numbering, placeholder replacement, font size, alignment, and placement in paragraph or table cell, but omits mutation side effects (e.g., file modification, permissions required) and error conditions.

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

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

The description is front-loaded with the core purpose and then lists features in a dense but information-rich sentence. No fluff, though the list could be better structured for scanning.

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 (16 parameters, no annotations, no schema descriptions), the description covers core functionality but leaves critical gaps in parameter semantics and behavioral details (file modification, permissions). It is adequate for a basic understanding but not complete enough for reliable parameter selection.

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

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

Schema description coverage is 0% for 16 parameters, so the description must compensate. It explains several key parameters (display_mode, equation_number, placeholder, font_size_pt, alignment, placement) but leaves many undocumented, including text_before, text_after, insert_before, space_before_pt, space_after_pt, and the index parameters for table/paragraph targeting.

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

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

States a specific verb (Menyisipkan) and resource (rumus matematika ke file .docx), lists supported input formats, and distinguishes itself from all sibling tools, none of which handle equations.

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

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

The context of inserting an equation into a .docx is implied by the purpose, but there is no explicit guidance on when to use it versus alternatives, nor any prerequisite conditions (e.g., file existence). The feature list describes capabilities, not when-to-use.

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

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

No annotations are provided, so the description carries the full behavioral burden, and it falls short. It does not state that this is a write/mutation operation on an existing file, whether the target file must already exist, what happens to surrounding content, or whether the rule is appended or inserted at a location. Only the parameter list hints at 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?

A single front-loaded sentence that leads with the action and then enumerates options; there is no filler or repetition. It is dense but every clause maps to real parameters, so it earns its 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?

An output schema exists, so return values need not be described. However, for a 12-parameter mutation tool with zero annotation coverage and 0% schema coverage, key calling details are missing: where the rule is placed (paragraph_index), what apply_to_existing does, and whether the file must pre-exist. The description is not complete enough to invoke this 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% across 12 parameters, so the description must compensate. It usefully enumerates the valid style values (which the schema does not, since it declares no enums) and covers thickness, indentation, border position, and color, but leaves file_path, paragraph_index, apply_to_existing, alignment, and space_before/after_pt unexplained. Partial compensation only.

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

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

The description states a specific verb and resource: inserting a horizontal rule / chapter divider, or adding a border line to a letterhead/paragraph in a docx file. This clearly distinguishes it from sibling tools like add_page_break_docx or add_section_docx, though it never names an alternative. The enumerated style list further sharpens the purpose.

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?

Two modes are implied (insert a new rule vs. add a border to an existing paragraph/letterhead), which hints at usage, but there is no explicit when-to-use, when-not-to-use, or pointer to alternatives among the many docx siblings. An agent must infer the selection logic from the phrase 'kop surat/paragraf'.

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 supplied, so the description carries the full behavioral burden. It says a break is inserted into the .docx but never states that the file is mutated in place, whether the change is reversible, what happens on invalid indices, or any permission/locking requirements for a write operation.

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

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

A single, front-loaded sentence that wastes no words and puts the operation first. It is dense but appropriately sized for the amount of information conveyed.

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

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

An output schema exists, so return values need not be explained. Still, for a 6-parameter mutation tool with zero schema descriptions and no annotations, the description should map parameters to placement modes and disclose side effects; the current text covers placement conceptually but leaves the parameter wiring implicit.

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

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

Schema description coverage is 0% across 6 parameters, so the description must compensate. It partially does by enumerating break_type values (page/column/line) and implying the placement semantics behind paragraph_index, table_index, row, and col, but file_path and the row/col indexing convention are left entirely undocumented.

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 gives a specific verb (menyisipkan/insert), the resource (page/column/line break), the target format (.docx), and the three placement modes (end of document, before a paragraph, inside a table cell). That is enough to tell it apart from most table-formatting siblings, though it never explicitly names an alternative tool.

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

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

The three placement options imply when each mode applies, which is useful implied guidance. However, there is no explicit when-to-use vs. when-not, no mention of prerequisites, and no named alternative (e.g. add_horizontal_rule_docx or add_section_docx) for related layout needs.

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

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

No annotations are provided, so the description carries the full burden. It discloses meaningful capability context (two input modes, unit options, caption/alt-text support, table-cell target), but omits any behavioral detail like which document is modified, what happens on failure, permissions, or return 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?

A single front-loaded sentence that leads with the core action and then enumerates options efficiently. Dense but not padded, though the long option list makes it slightly run-on.

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

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

An output schema exists so return values need not be explained, and the capability list is broad. However, for a 15-parameter tool with no annotations, gaps around the required file_path target and the paragraph/table-cell positioning parameters leave the agent under-informed.

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% across 15 parameters, so the description must compensate. It maps several parameters well (image_path/image_base64, width/height in Inches or Cm, alignment, caption, alt_text/title, table cell), but leaves the required file_path, paragraph_index, and the row/col/table_index interaction unexplained.

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

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

States a specific verb (insert) and resource (image into a Word document), and enumerates distinctive capabilities (path/base64 input, sizing, alignment, caption, alt text, table-cell placement) that cleanly separate it from siblings like resize_picture_docx, delete_picture_docx, and get_images_info_docx.

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

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

The description lists what options exist but never says when to choose this tool over alternatives such as resize_picture_docx or extract_images_docx, nor any prerequisites. Usage is only implied by the verb.

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

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

No annotations are provided, so the description carries the full behavioral burden, and it falls short. It does not state whether the file is modified in place, what happens to existing rows, whether insert_index shifts subsequent rows, or what happens if values length mismatches the column count.

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

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

A single front-loaded sentence with no filler, leading with the action and resource before the optional modifiers. Appropriate length, though it could have spent a clause on the append-vs-insert distinction.

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

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

An output schema exists, so return values need not be described. However, for a mutation tool with zero annotation coverage and 0% parameter documentation, the description leaves key operational questions (insert semantics, path requirements, value/column alignment) unanswered.

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 does map three of the five parameters to their meaning (cell text, height, position index), but file_path and table_index are left unexplained, and it adds no units, defaults, or constraints beyond the schema titles.

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

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

The description states a specific verb and resource ('Menambahkan atau menyisipkan baris baru pada tabel docx') and enumerates the optional inputs. It is clearly distinguishable from siblings like add_column_docx and delete_row_docx, though it never names an alternative.

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 when-to-use or when-not-to-use guidance is given. The description notes the row can be added or inserted but never explains the condition that selects append vs. insert, nor any prerequisites such as the table needing to exist.

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

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

No annotations are provided, so the description carries the full burden. It implies a mutating operation on an existing Word file but says nothing about whether the write is in-place, whether existing content is preserved, what permissions are needed, or how failures are handled — significant gaps for a document-mutating 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?

A single well-formed sentence that front-loads the action and then gives illustrative examples; nothing is wasted. It could arguably spend a few more words covering parameters, but as a sentence it is tight and readable.

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

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

An output schema exists so return values need no explanation, but with 25 undocumented parameters, no annotations, and no usage guidance, the description is far short of what an agent needs to call this tool correctly. The int/float duplication (cm vs inches) and unit selection are never addressed.

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% across 25 parameters, so the description must compensate and largely does not. It mentions only orientation, column count, and page-number restart, leaving margins, paper size, gutters, start_type, and header/footer behavior completely undocumented anywhere.

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

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

States a specific verb and resource ('Menambahkan section baru ke dokumen Word') and adds concrete examples (Landscape page, 2-column layout, page-number restart) that clarify the concept of a Word 'section'. It implicitly separates itself from add_page_break_docx by illustrating section-level properties rather than a mere break, though it never names a sibling.

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 examples hint at what a section can accomplish, but there is no statement of when to reach for this tool versus add_page_break_docx, set_page_setup_docx, or get_page_setup_docx. No prerequisites or exclusions are given, so an agent must infer the routing itself.

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

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

No annotations are provided, so the description carries the full behavioral burden, yet it only implies a write operation. It does not state whether the paragraph is appended or inserted, whether the file must already exist, permission/auth needs, or side effects. For a 29-parameter mutation tool this is a significant gap.

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

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

A single front-loaded sentence with the action verb first and no filler. It is efficient, though wrapping the whole category list into one clause makes it slightly dense and the Indonesian phrasing sits oddly against the English tool name.

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

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

An output schema exists so return values need not be described, but with 29 undocumented parameters, no annotations, and a mutation operation, the description is far too thin for the tool's complexity. It leaves file-existence, insertion position, and per-parameter meaning unaddressed.

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% across 29 parameters, so the description must compensate. It lists only broad categories (font, size, color, text style, spacing, alignment) and leaves key parameters such as heading_level, list_style, indent values, widow_control, keep_with_next, and page_break_before unexplained.

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

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

States a specific verb ('Menambahkan') and resource ('paragraf atau heading baru') with a clear target ('file .docx'), and enumerates the styling domains covered. It implies the 'new' vs 'existing' distinction that separates it from format_paragraph_docx, but never names a sibling, so an agent must infer the boundary.

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

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

The description says what the tool does but gives no when-to-use guidance, no exclusions, and no alternative tools. With siblings like format_paragraph_docx, format_text_docx, and create_or_append_docx in scope, the agent is left to guess which to call for an existing vs new paragraph.

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

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

No annotations are provided, so the description carries the burden. It discloses that dynamic TOCs use Word fields and mentions update_fields_on_open behavior implicitly through the option list, and it names what gets inserted (TOC, page breaks, heading). However it doesn't state whether the file is modified in place, whether existing content is shifted, permission needs, or file-overwrite/backup behavior. For a mutating document tool, this is a notable gap.

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

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

It's a single long run-on sentence in Indonesian with a dense feature list. It is reasonably front-loaded with the core action but packs many features into one clause-heavy enumeration, which reduces scannability.

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

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

There is an output schema, so return values need not be explained. But with 18 undocumented parameters, no annotations, and no usage prerequisites, the description is not complete enough for an agent to invoke this correctly without opening the full schema. It should at minimum clarify the key modes (toc_type values, entries vs auto detection, insertion position).

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 there are 18 parameters, yet the description only loosely maps a handful (heading title examples, dot leaders, auto-detect headings, level indentation). Most parameters (insert_before, paragraph_index, font_size_pt, line_spacing, space_after_pt, bold_level_1, update_fields_on_open) are never explained. The description does not compensate for the schema gap.

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

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

The description states a clear verb+resource: adding a Table of Contents to a .docx document. It's specific about TOC types (dynamic Word field vs. manual entries) and options. It doesn't explicitly differentiate from siblings, but siblings are almost all table or text-formatting tools, so the TOC-specific purpose is clear without naming an alternative.

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

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

The description implies usage context (you want a TOC in a docx) and lists supported features, but it never says when to choose this over alternatives like building a TOC manually with add_styled_paragraph, nor does it state prerequisites such as needing existing headings. Usage is implied rather than guided.

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

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

No annotations are provided, so the description carries the full behavioral burden. It does disclose the destructive scope (all text and tables removed, result is an empty document), which is genuinely useful. However, it says nothing about irreversibility, whether images/headers/sections/styles survive, or whether the file is overwritten in place — notable gaps for a destructive tool with zero annotation coverage.

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

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

A single tight sentence that front-loads the action and its scope with no filler. Length is appropriate, though it errs toward under-specification rather than compression.

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

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

An output schema exists so return values need no explanation, but for a destructive, unannotated tool the description is too thin. The central ambiguity — what is preserved (images, headers/footers, tables' styling) and whether the original file is overwritten — is unaddressed, and the sole parameter is unexplained.

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?

One required parameter with 0% schema description coverage, and the description never mentions file_path. Path format, whether it must already exist, and relative-vs-absolute semantics are left entirely undocumented in both schema and description.

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

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

The description gives a specific verb and scope: it removes ALL text and tables, turning the file into an empty document. 'Seluruh isi' distinguishes it implicitly from the partial deletion siblings (delete_table_docx, delete_row_docx, delete_column_docx), though it never names them or draws the contrast explicitly.

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

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

There is no when-to-use guidance, no prerequisites, and no mention of alternatives for partial clearing. With many delete_* siblings available, an agent gets no help deciding between a full wipe and targeted deletion.

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

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

No annotations are provided, so the description carries the full burden, yet it largely restates the tool name. It implies append-to-existing preserves content, but says nothing about overwrite behavior, permissions, existing-content handling, or return 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?

A single, efficient sentence with the create-vs-append distinction front-loaded. No wasted words, though it's arguably too terse given the tool's complexity.

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

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

An output schema exists so return values needn't be described, but with zero annotations and 0% parameter coverage, the description leaves too many invocation-critical details (heading usage, overwrite semantics) unspecified.

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% for 3 parameters. The description only vaguely references a 'file' and 'paragraphs', omitting the 'heading' parameter entirely and adding no format or syntax detail to compensate.

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

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

The description states a specific verb+resource: creating a new .docx or appending paragraphs to an existing one. It's clear what the tool does, but it doesn't explicitly distinguish itself from siblings like add_styled_paragraph_docx or format_paragraph_docx.

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

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

There is no guidance on when to use this tool versus the many sibling docx tools. The create-vs-append condition is implied, but no exclusions or alternative routing is offered.

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

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

No annotations are provided, so the description carries the full behavioral burden. It says a table is created but not whether it requires an existing document, whether it appends to or overwrites content, what permissions are needed, or whether the operation is reversible. For a mutation tool with zero annotation coverage this is a notable gap.

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

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

A single tight sentence with no filler and the core action front-loaded. Its brevity, however, leaves several behavioral and parameter questions unanswered rather than earning brevity through completeness.

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

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

An output schema exists so return values are covered, but with no annotations and 0% schema coverage the definition omits preconditions, side effects, and the semantics of two of three parameters. Inadequate for a document-mutating creation tool surrounded by many table siblings.

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

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

Schema description coverage is 0%, so the description must compensate. It only clarifies the 'data' parameter's 2D-matrix format; the meaning of 'file_path' (existing vs new file, format) and 'heading' (what it controls) are left undocumented in both schema and description.

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

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

States a specific verb and resource ('Membuat tabel baru' = create a new table) and the source format ('matriks data 2D') plus target ('file .docx'). It is distinguishable from delete_table_docx and edit_table_docx by the 'create' verb, though it doesn't explicitly name a sibling.

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 when-to-use guidance and no alternatives referenced. An agent is not told whether to prefer this over add_row_docx/edit_table_docx or what preconditions exist (e.g., does the .docx file already need to exist).

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

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

No annotations are provided, so the description carries the full behavioral burden for a destructive mutation. It notes the 0-indexed convention, which is genuinely useful, but says nothing about data loss, reversibility, out-of-range col_index behavior, or required permissions on the 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?

A single tight sentence with the target (column of a docx table) front-loaded and no filler. It is efficient, though it is efficient about rather little.

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

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

For a destructive, three-parameter mutation with no annotations, the definition is thin. The output schema relieves it of explaining return values, but it still omits which table is targeted (table_index semantics), preconditions, and any guidance on use vs. 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%, so the description must compensate, yet it only clarifies col_index (0-indexed) and leaves file_path and table_index completely unexplained. Two of three parameters are undocumented in both schema and description.

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

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

States a specific verb (Menghapus/deletes) and resource (satu kolom dari tabel docx), which cleanly separates it from the sibling delete_row_docx and add_column_docx. It also pins the indexing convention (col_index, 0-indexed). It does not explicitly name a sibling it is not, so it lands just short of a 5.

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

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

There is no when-to-use guidance, no prerequisites, and no mention of alternatives such as delete_row_docx or edit_table_docx for column removal. The only usage signal is what the agent infers from the tool name itself.

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

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

No annotations are provided, so the description must carry the full burden. It does not disclose whether deletion is permanent, if it requires specific permissions, whether the document must be saved afterward, or any side effects. It only states the core operation.

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

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

A single, front-loaded sentence that states the action and resource without any extraneous words. It is appropriately sized for a simple operation.

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 is a mutation operation with no annotations, no schema descriptions, and two parameters (one required), the description is insufficient. It lacks information about the return value (even though an output schema exists, the description could mention it), error conditions, or how the picture index is determined.

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 for both parameters. It mentions 'berdasarkan indeks gambar' (based on picture index), which aligns with the picture_index parameter, but does not explain the default value (0) or the format of file_path. The description adds minimal meaning 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?

Clearly states the action (delete) and the resource (a picture from a .docx document by its index). Distinguishable from siblings like add_picture_docx or resize_picture_docx. However, it lacks explicit sibling differentiation in the text itself.

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_images_docx or get_images_info_docx. The description simply states what it does without context about prerequisites or scenarios.

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

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

No annotations are provided, so the description carries the full burden. It notes the row_index is 0-indexed, which is helpful, but says nothing about whether deletion is irreversible, whether the file is saved to disk, what happens to out-of-range indices, or what the response contains. For a destructive mutation this is a significant gap.

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

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

A single short sentence with zero filler, front-loading the action and resource before the index qualifier. Nothing is wasted.

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

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

An output schema exists, so return values need not be described, but the definition remains thin for a destructive mutation with no annotations and 0% parameter coverage. It should at minimum explain table_index and file_path semantics and note the irreversibility of the 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 for all three parameters. It only clarifies row_index (0-indexed) and implicitly references the table; table_index and file_path are left completely unexplained with no format, path conventions, or index basis for table_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 states a specific verb and resource: deleting one particular row from a docx table. It clearly distinguishes itself from sibling operations like delete_column_docx and delete_table_docx by scoping to a single row. However, it does not explicitly name those siblings or clarify boundaries with add_row_docx-style operations.

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

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

There is no guidance on when to use this tool versus alternatives such as delete_table_docx or delete_column_docx, nor any prerequisites (e.g. the table must already exist, the index must be in range). Usage is only implied by the verb.

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 behavioral burden. It conveys that the operation is destructive, but says nothing about whether deletions shift subsequent table indices, whether the file is modified in place, or what happens if the index is out of range.

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

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

A single front-loaded sentence with zero filler; the resource and the index convention are stated immediately.

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

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

For a destructive, non-annotated mutation with two undocumented parameters, this is thin. An output schema exists so return values need no explanation, but the absence of any index-shift or safety context leaves a meaningful gap.

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

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

Schema description coverage is 0%, so the description must compensate. It does add one essential semantic — table_index is 0-indexed — but leaves file_path undocumented and does not clarify index bounds or behavior on invalid indices.

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

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

The description states a specific verb and resource ('Menghapus tabel dari file .docx') and adds the indexing convention. It implicitly distinguishes itself from siblings like delete_row_docx and delete_column_docx by scope, though it never names an alternative explicitly.

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

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

There is no guidance on when to use this tool versus clear_docx, delete_row_docx, delete_column_docx, or split_table_docx, and no prerequisites or exclusions are stated.

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

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

No annotations are provided, so the description carries the full behavioral burden. It discloses the 0-indexing convention but says nothing about whether existing cell text is overwritten, whether cell formatting is preserved, what permissions or file-access state are required, or any error 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?

A single, front-loaded sentence with no filler or redundancy. It is appropriately compact, though the brevity reflects missing information rather than efficient coverage.

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 five required parameters, 0% schema coverage, and no annotations, the description is too thin. An output schema exists so return values need not be explained, but the input side and the mutation behavior remain largely undocumented for what is a state-changing 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% across five required parameters, and the description only alludes to the cell coordinates via 'sel tabel tertentu (0-indexed)' and the concept of text. It never clarifies table_index (which table in a multi-table document), file_path semantics, or the exact indexing basis for row/col, so it only partially compensates for the schema gap.

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

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

States a specific verb+resource: changing the text content of a particular table cell in a .docx file. It implies scope (a single cell, 0-indexed) which distinguishes it from whole-document tools like replace_text_in_docx, but it does not explicitly name or contrast any sibling such as set_cell_text_direction_docx or merge_cells_docx.

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

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

There is no when-to-use or when-not-to-use guidance, no prerequisites, and no alternatives named. The agent must infer usage entirely from the tool name and the description's single clause.

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

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

No annotations are provided, so the description carries the full behavioral burden. It does not state overwrite behavior for existing files in output_dir, whether folders are created, what happens on failure, permissions, or count/format of saved images. Given the presence of an output schema the return shape is covered, but the write-to-disk semantics are not.

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

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

A single, front-loaded sentence with the action, target and destination in order. Efficient, though it is the only content, so there is no structural layering to evaluate beyond the one clean sentence.

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 filesystem-mutating extraction tool with no annotations and 0% param coverage, the description leaves key operational facts unspecified (overwrite policy, error handling, output naming). The output schema covers return values, but input-side and side-effect gaps make it inadequate for confident invocation.

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

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

Schema coverage is 0% and both required parameters (file_path, output_dir) are bare titles with no description anywhere. The description implies what output_dir is (a folder to save images into) but adds no detail on path format, whether it must exist, or any conflict handling, leaving both params under-specified.

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

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

States a specific verb (Mengekstrak = extract) and resource (embedded image files in .docx) plus where they go (output folder). This distinguishes it from image-related siblings like get_images_info_docx (info) and delete_picture_docx (delete), though it does not name any sibling explicitly.

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

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

No when-to-use guidance, no mention of alternatives such as get_images_info_docx for metadata-only inspection, and no preconditions (e.g., file must exist, be a valid .docx). The agent must infer the entire selection context from the name alone.

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 and no output/behavioral hints, the description carries the full burden. It does not state whether unspecified parameters leave existing formatting untouched, how targeting works (paragraph_index vs row/col/table_index), whether changes are reversible, or what permissions are needed for a mutation tool with 18 parameters.

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

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

A single well-structured sentence that front-loads the purpose and then groups the capabilities logically, with no filler. It is appropriately sized for a broad-format tool.

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

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

For a mutation tool with 18 parameters, zero schema coverage, and no annotations, the description is too thin: it omits parameter targeting semantics, mutation behavior on unspecified fields, and any output/return expectations, leaving significant gaps an agent would need filled.

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 usefully clarifies units (inches for indentation, pt for spacing, ratio like 1.5/2.0 for line spacing) and names keep_with_next/page_break_before, but it leaves core targeting parameters (paragraph_index, row, col, table_index) and widow_control entirely unexplained.

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

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

The description opens with a clear verb+resource ('Mengatur format paragraf') and enumerates the specific formatting aspects it controls (line spacing, space before/after, indentation, alignment, list, page control). However, it never distinguishes itself from the close sibling format_text_docx, which could also sound like 'formatting' in a docx context.

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

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

There is no guidance on when to use this tool versus alternatives such as format_text_docx or add_styled_paragraph_docx, nor any mention of prerequisites. It describes what can be set but not the conditions under which an agent should select it.

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

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

No annotations are supplied, so the description carries the full behavioral burden. It is a mutation tool, yet it never states that it overwrites existing formatting, whether omitted attributes are left untouched or reset, or how the file must be provided. Merely listing formatting properties is not behavioral disclosure.

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

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

It is a single, compact sentence with no wasted words, so it is appropriately sized. However it is a flat comma list with no front-loading of the operation's key constraint (that it needs a target location), so structure adds little beyond enumeration.

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 19-parameter mutation tool with 0% schema coverage and no annotations, the description is far too thin. The output schema removes the need to explain returns, but the absence of any targeting or precondition detail leaves the definition materially incomplete.

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

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

Schema description coverage is 0%, so all 19 parameters are undocumented in both schema and text. The description covers the formatting attributes but omits the critical targeting parameters (file_path, paragraph_index, table_index, row, col, target_text) and underline_style, leaving the agent unable to know how to select the text to 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 names a clear verb ('Mengatur' / sets) and enumerates the text-formatting attributes affected, so the agent understands it applies character-level formatting to text. It provides no differentiation from the sibling format_paragraph_docx, which likely overlaps in scope.

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?

There is no guidance on when to use this versus format_paragraph_docx, nor any prerequisites (open file, docx context). The list of attributes implies usage but stops short of any when/when-not instruction.

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

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

No annotations are provided, so the description carries the full burden. It helpfully discloses the payload (text, PAGE/NUMPAGES fields, link status, configuration) and that it spans all sections, but says nothing about permissions, error behavior, or whether output is read-only safe.

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

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

A single front-loaded sentence enumerating what is returned, with zero filler. Every clause earns its place.

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

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

An output schema exists, so return-format explanation is not required, and the description adequately frames the read. However it omits any explanation of the section_index parameter, leaving a real gap for a 2-parameter 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%, so the description must compensate and does not. It never mentions section_index, and its claim of covering 'seluruh section' (all sections) actively leaves the optional per-section filtering parameter unexplained.

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

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

States a specific verb (membaca/reads) and resource (Header/Footer of a .docx), plus the exact scope (all sections). An agent can immediately separate this getter from the sibling set_header_footer_docx writer without opening either schema.

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

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

Usage is only implied: an agent infers this is the read counterpart to set_header_footer_docx. There is no explicit when-to-use, no exclusion against read_docx or get_page_setup_docx, and no stated prerequisite (e.g., file must exist).

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

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

No annotations are provided, so the description carries the burden. It implies a read-only inspection and states the payload content (list plus dimensions), but says nothing about permissions, whether it scans headers/footers, or failure modes. An output schema exists, so return values need not be described.

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

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

A single front-loaded sentence with no filler, though it is dense and untranslated relative to the English sibling descriptions.

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

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

Adequate for a simple read-only getter with an output schema, but it leaves the boundary with extract_images_docx ambiguous and gives no parameter detail, so an agent has gaps to fill.

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?

One required parameter (file_path) with 0% schema description coverage. The description's reference to 'dokumen .docx' weakly implies the input is a .docx path, but it never explains the parameter directly; the single obvious parameter keeps this from being worse.

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

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

States a specific verb+resource: retrieving the list and dimension information of all images in a .docx document. This is clearly distinguishable from extract_images_docx or resize_picture_docx by what it returns, though it never names a sibling explicitly.

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

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

There is no when-to-use guidance, no mention of alternatives (e.g. extract_images_docx), and no preconditions. The agent must infer usage purely from the verb.

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

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

No annotations are provided, so the description carries the burden. It usefully discloses that the read covers all sections of the document, not just the first, but says nothing about permissions, whether sections are returned in order, or the response shape. Some value added, but well short of full behavioral disclosure.

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

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

A single tight sentence that front-loads the verb and then enumerates returnable fields with no filler. Efficient, though the field list makes it slightly dense.

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

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

An output schema exists, so return value explanation is unnecessary, and the description lists the relevant fields plus the document-wide scope. For a single-param read tool this is nearly complete; only the file path format is unaddressed.

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

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

There is a single required parameter (file_path) with 0% schema description coverage, and the description never mentions it or its format. For a one-parameter tool the omission is minor, but no meaning is added 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?

States a specific verb (membaca/reads) and resource (page setup) and enumerates the exact attributes returned — paper size, orientation, margins, gutter, header/footer distance, columns, page numbering. It is clearly distinguished from the sibling set_page_setup_docx by the read vs. write framing.

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

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

Usage is implied (inspect the current page setup before modifying it via set_page_setup_docx), but there is no explicit when-to-use or when-not statement and no alternatives named. Adequate but leaves the routing to inference.

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

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

With no annotations, the description carries the full behavioral burden but only explains the coordinate convention. It omits file_path/table_index requirements, whether merging is reversible, what happens to existing cell content, and any error behavior for a clearly mutating operation.

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

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

A single front-loaded sentence with no filler; the coordinate semantics are stated immediately. It is tight, though the terseness contributes to the parameter gaps rather than compensating for them.

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

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

An output schema exists so return values need not be described, but for a 6-parameter mutating table tool with zero annotation coverage and 0% schema description coverage, the description is too thin on file/table targeting and behavioral caveats.

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 usefully clarifies that the area spans [start_row, start_col] to [end_row, end_col] and is 0-indexed, but says nothing about file_path or table_index, leaving two required parameters unexplained.

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

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

States a specific verb (merge) and resource (a cell area defined by start/end coordinates), which is clear enough to distinguish it from the many other table tools. It does not, however, name related siblings like split_table_docx or the surrounding file/table context, so differentiation is only partial.

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

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

The description gives no when-to-use guidance, no prerequisites, and no mention of alternatives or the inverse operation (split_table_docx). Usage must be inferred entirely from the name.

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

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

No annotations are provided, so the description carries the burden. It usefully discloses that both text and tables are extracted (scope of the read), and the verb 'Membaca' implies a non-destructive operation. However, it says nothing about auth/permission needs, failure modes on corrupt or password-protected files, or whether reading is limited to a single 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?

A single short sentence with the key information front-loaded and zero padding. It is appropriately sized for a one-parameter read tool, though the brevity is also what leaves the gaps noted elsewhere.

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

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

An output schema exists, so return values need no explanation, and the tool is structurally simple (one required parameter). Still, with no annotations and no parameter documentation, the definition leaves the agent without guidance on file-path expectations or edge-case behavior.

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

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

Schema description coverage is 0% and the sole parameter (file_path) is untyped in the schema beyond 'string'. The description never mentions the parameter, so it fails to compensate for the coverage gap — it does not clarify format (absolute vs relative), extension requirements, or whether only .docx is accepted.

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

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

States a specific verb (read) and resource (.docx file) plus the extraction scope ('all text content and tables'), which cleanly distinguishes it from the many mutation-oriented docx siblings. It does not explicitly name any sibling or contrast itself with the other readers (get_header_footer_docx, get_page_setup_docx), so it stops short of a 5.

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

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

There is no statement of when to use this tool versus alternatives, no prerequisites, and no exclusions. The agent must infer from the name and from the sibling list that this is the pure content-extraction path.

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

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

No annotations are provided, so the description carries the full behavioral burden. It discloses that replacement spans both paragraphs and tables, which is useful, but omits critical mutation traits: whether all occurrences or only the first are replaced, case sensitivity, whether the file is written to disk or the change held in memory, and whether the original file is overwritten.

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

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

A single tight sentence with the action front-loaded and no filler. It is not under-long so much as under-specified, which is penalised elsewhere.

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

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

An output schema exists so return values need not be described, but for a document-mutating tool with zero annotations and zero parameter documentation, one sentence is far too thin. Details such as replace-all behaviour, scope of tables versus headers/footers, and whether changes persist are all 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% and all three parameters (file_path, old_text, new_text) are undocumented in the schema. The description adds no meaning for any of them – it never mentions path format, matching semantics for old_text, or how new_text is inserted – so the low-coverage burden is not met.

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

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

The description names a specific verb pair (search and replace) and resource (text within .docx paragraphs and tables), which is enough to distinguish it from the formatting/table-structure siblings. It does not, however, contrast itself against near-neighbours such as set_cell_text_docx or format_text_docx that also touch text 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?

There is no statement of when to use this tool versus alternatives, no prerequisites (file must exist, file must be closed, etc.), and no exclusions. The agent must infer usage entirely from the name.

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 behavioral burden and leaves key traits unstated: whether aspect ratio is preserved, what happens when only one of width/height is supplied (the schema defaults all four dimension params to null), and what occurs on an out-of-range picture index. Units are mentioned, which is the only behavioral detail added.

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

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

A single front-loaded sentence that opens with the action and immediately names the resource and selection key. The parenthetical '(resize)' gloss is slight redundancy in an otherwise waste-free line.

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

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

For a 6-parameter mutation tool with zero schema descriptions and no annotations, the description is too thin. The output schema removes the need to document return values, but the null-default semantics, required file_path role, and error/aspect-ratio behavior remain undocumented.

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 only touches picture_index and the unit choice (Inches or Cm), leaving file_path, the four individually named dimension parameters, and the significance of their null defaults unexplained. Partial compensation only.

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

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

States a specific verb (resize / 'mengubah ukuran') and resource (an existing picture in the document), and identifies the selection key (picture index). The picture-vs-table distinction from sibling resize_table_docx is carried by the name, but the description never explicitly routes 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?

'gambar yang sudah ada di dokumen' implies the picture must already exist, but there is no explicit when-to-use, no exclusions, and no mention of alternatives such as add_picture_docx or get_images_info_docx for discovering the index. This matches the 'no guidance' band rather than 'implied usage'.

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

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

No annotations are supplied, so the description carries the full behavioral burden. It does not say whether existing widths are overwritten, whether unlisted columns are preserved, what happens if col_widths length mismatches the table, or how the file is persisted. For a mutation tool with zero annotation coverage this is a notable gap.

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

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

Two tight sentences with the purpose front-loaded and the two usage modes immediately after; there is no filler. The only slight weakness is that the second clause is param-instructional rather than framing.

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

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

An output schema exists so return values need no explanation, and the width parameters are covered. But with 5 parameters at 0% schema coverage and no annotations, the description should say more about the mutation's effect on the document and the required identifiers.

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, and it does explain the core pairing semantics: col_widths for all columns, col_index + width_inches for a single column, with inches as the unit. It leaves file_path and table_index unexplained, but those are largely self-evident 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?

States a specific verb and resource ('Mengatur lebar kolom tabel') with the unit of measure (inches), which is exactly what the name promises. It is distinguishable from siblings like add_column_docx or delete_column_docx since the scope is width only, though it never explicitly contrasts itself with those siblings.

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

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

The description specifies two invocation modes ('seluruh kolom via col_widths' vs 'satu kolom via col_index & width_inches'), which is useful operational guidance. However it gives no context on when to prefer this tool, no prerequisites, and no exclusions relative to table-formatting siblings.

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

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

No annotations are provided, so the description carries the full burden. It discloses the accepted alignment values, but says nothing about required permissions, whether omitted row/col means 'entire table' or 'no-op', or whether existing alignment is overwritten.

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

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

A single compact sentence that front-loads the action and then the value options. No wasted words, though brevity comes at the cost of the missing parameter context.

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

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

An output schema exists so return values need not be described. However, for a mutation tool with zero annotations and 0% schema coverage across 6 params, the definition leaves too much unresolved—particularly whether null row/col targets the whole table.

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% for all 6 parameters. The description usefully documents the allowed values for horizontal and vertical (which the schema leaves as bare strings), but leaves row, col, file_path, and table_index semantics—especially the meaning of null row/col—entirely undocumented.

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

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

States a specific verb+resource ('set cell text alignment') and enumerates the horizontal and vertical value options. It is distinguishable from table-level siblings by 'sel' (cell), though it does not explicitly contrast with set_table_alignment_docx.

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

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

No guidance on when to use this versus set_table_alignment_docx or the other cell-formatting siblings. The 'and/or' phrasing hints that either axis may be set, but the agent must infer when and in what combination.

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

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

No annotations are provided, so the description carries the full burden. It discloses the whole-table-vs-single-cell fallback and the pt unit, but says nothing about persistence (whether the file is written to disk), permission requirements, or how unspecified edges interact with the schema defaults.

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

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

Two tight sentences: purpose first, scoping rule second. No filler, though it could be marginally more structured by grouping the parameter semantics.

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

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

An output schema exists so return values needn't be described, but this is an 8-parameter mutation tool with zero annotation coverage and zero schema descriptions. The description covers only row/col scoping and units, leaving most parameters and mutation side effects undocumented.

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% across 8 parameters, so the description must compensate and largely does not. It clarifies row/col semantics and the pt unit, but leaves top_pt/left_pt/right_pt/bottom_pt, file_path, and table_index unexplained, and never states the default padding values.

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

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

States a specific verb+resource: setting a cell's internal padding/margin, with the unit (pt) given. It clearly differs from siblings like set_cell_shading_docx or set_cell_alignment_docx by naming the exact formatting attribute, though it never explicitly contrasts with 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?

It explains scoping behavior (a specific [row, col] cell, or the whole table when row/col are omitted), which is real usage guidance for the parameters. However there is no when/when-not guidance relative to alternatives and no prerequisites (e.g. table must exist, file must be writable).

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

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

No annotations are provided, so the description carries the full behavioral burden. It never states that this mutates/saves the document, whether the target file or table must already exist, or what happens when row/col are null versus specified (implied whole-table scope). For a write tool with zero annotation coverage this is a real gap.

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

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

A single front-loaded sentence with no filler; the action, scope, and the HEX format example are all packed efficiently.

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 5-parameter mutation tool with no annotations and 0% parameter documentation, one sentence is inadequate. Although an output schema exists (so return values need not be explained), the targeting semantics of row/col/table_index and the mutation/persistence behavior are missing.

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

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

Schema description coverage is 0% across 5 parameters. The description adds meaningful format detail only for color_hex ('E0E0E0' or '#E0E0E0') and hints that row/col/table_index select the scope, but leaves file_path, table_index indexing base, and the exact row/col null semantics unexplained.

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

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

States a specific verb (apply shading / background color) and resource (cell/row/column/table), so it is clearly distinguishable from neighbors like set_table_borders_docx or set_cell_alignment_docx. It does not explicitly name any sibling it must be chosen over, which keeps it just short of a 5.

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

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

Usage is implied by the action itself — apply shading when you want background color. There is no explicit when-to-use/when-not, and no routing guidance such as how it relates to set_table_style_docx or set_table_borders_docx, which an agent must infer.

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 behavioral burden, and it does not state that the document is modified in place, whether the file must already exist, whether changes are saved, or that row/col targeting affects which cells are changed. It conveys the visual effect of each direction but nothing about side effects or requirements.

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

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

A single front-loaded sentence with a compact parenthetical for the option values; little waste, though the rotation phrasing is slightly redundant.

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

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

For a 5-parameter mutation tool with no annotations and 0% schema coverage, the description is far short of complete: it explains direction values but not cell targeting (row/col) or persistence behavior. The output schema exists, so return values need not be described.

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

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

Schema description coverage is 0%, so the description must compensate. It clarifies only the 'direction' parameter (one of five), and even then gives no enum constraint on the schema. The nullable row/col targeting and file_path/table_index semantics are entirely undocumented.

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

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

States a specific verb+resource ('Mengatur arah orientasi teks sel' = set cell text orientation) that is clearly distinct from siblings like set_cell_alignment_docx or set_cell_shading_docx. It also enumerates the direction values, though it does not explicitly contrast itself against any sibling.

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 when-to-use guidance, no prerequisites, no alternatives named. The description only explains the direction values, leaving the agent to infer context on its own.

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

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

No annotations are provided, so the description carries the full behavioral burden. It notes different_first_page, unlink section, and presets, but never states whether the operation is destructive to existing headers/footers, whether it requires the file to be closed/locked, whether changes are reversible, or what the response contains (even though an output schema exists, the mutation's side effects on existing content are undisclosed).

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 well-formed sentences that front-load the core action and then enumerate capabilities. No padding or redundant restatement of the name.

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 16-parameter mutation tool with no annotations and zero schema descriptions, the description is far too thin: it omits parameter behavior, side effects, authorization/file-state prerequisites, and preset semantics. The presence of an output schema excuses return-value explanation, but the input-side gaps remain severe.

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 there are 16 parameters, so the description must compensate heavily. It explains only a handful of concepts (different_first_page, unlink section, preset names, page number fields) and says nothing about target values (header vs footer), header_footer_type, alignment, section_index, or the formatting params. Most parameters remain opaque.

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

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

States a specific verb (Mengatur/Menyisipkan) and resource (Header/Footer, nomor halaman) on .docx files, and enumerates the features it supports. It clearly distinguishes itself from the sibling get_header_footer_docx (read vs write) and from general formatting tools, though it doesn't explicitly name those alternatives in the description itself.

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 purpose but gives no explicit when-to-use, when-not-to-use, or sibling alternatives. An agent cannot tell from this text whether to prefer this over set_page_setup_docx for page numbering or when to use the preset versus manual parameters.

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

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

With no annotations provided, the description carries the full behavioral burden. It never states that this is a mutating operation, whether it edits the whole document or a single section, whether existing settings are overwritten, whether it requires the file to already exist, or how failures are surfaced. For a 30-parameter mutation tool this is a substantial gap.

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

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

A single dense sentence, but it is front-loaded with the primary attribute (paper size) and groups related settings coherently. The comma-list is efficient, though it is long enough that the section_index behavior deserved its own clause.

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

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

An output schema exists, so return values need not be explained. Still, for a tool with 30 parameters, zero schema descriptions, and no annotations, the description leaves important gaps: which section is targeted by default, unit/format expectations for page dimensions, and whether header/footer distance settings are covered.

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 is the only source of meaning, and it does add real value: accepted paper sizes (A4, Letter, F4/Folio, Legal), accepted units (cm/inci), and margin presets (normal, narrow, skripsi). However, it omits roughly half the parameters — section_index, page_width/height, header/footer distance, page_number_format, and different_first_page_header_footer — leaving them entirely undocumented.

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

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

Names a specific verb (set/set up) and resource (page setup), and enumerates the concrete attributes it controls: paper size, orientation, margins, gutter, columns, page numbering, mirror margins. The distinction from the sibling get_page_setup_docx is implied by the set/get pairing, but never stated explicitly, so it falls short of a 5.

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

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

There is no statement of when to reach for this tool versus siblings (e.g. get_page_setup_docx to read current values first, or add_section_docx when a new section is needed). The mention of presets ('normal, narrow, skripsi') hints at intended scenarios but is not framed as usage guidance.

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

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

No annotations are provided, so the description carries the full behavioral burden. It never states that this mutates and saves the document, whether the change is reversible, what happens for an invalid table_index, or any file-access requirements. Only the allowed alignment values are disclosed, leaving the mutation contract largely unstated.

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

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

A single front-loaded sentence with no filler; the core action comes first and the allowed values are parenthesized at the end. It is efficient, though it is arguably too terse given the undocumented parameters.

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

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

An output schema exists, so return values need not be explained. However, for a 3-required-parameter mutation tool with zero annotation and zero schema-description coverage, the description leaves the meaning of table_index and the file-handling behavior unaddressed, which is not enough for correct invocation.

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

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

Schema description coverage is 0% for all three required parameters, so the description must compensate. It clarifies the alignment values ('left', 'center', 'right' – which the schema does not even encode as an enum), but says nothing about file_path or table_index: notably whether the index is 0-based and how tables are ordered.

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

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

States a specific verb+resource: setting the page-level alignment of a table ('Mengatur perataan posisi tabel di halaman dokumen'). The phrase 'posisi tabel di halaman' implicitly distinguishes it from the sibling set_cell_alignment_docx, but no sibling is named. One caveat: the description is in Indonesian while the tool names, siblings and schema are English, which adds a small comprehension cost.

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 scope qualifier ('on the document page' vs. cell-level) implies the correct context, so it is not entirely guidance-free. But there is no explicit when-to-use, no prerequisites (file must exist and be a .docx), and no reference to the obvious alternative set_cell_alignment_docx for cell content.

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

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

No annotations are provided, so the description carries the full behavioral burden. It implies a destructive mutation of the document's table borders but says nothing about permissions needed, whether changes are reversible, how the target table is located, or that calling it rewrites the file on disk.

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

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

A single compact sentence that front-loads the action and the customization options, with no filler. It is efficient, though the brevity partly reflects the missing detail noted elsewhere.

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

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

An output schema exists so return values need no explanation, but for an 11-parameter mutation with 0% schema coverage the description is far too thin. It omits how sides are toggled, how the target table is identified, and what happens to unspecified sides.

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% across 11 parameters, and the description only clarifies three concepts (color as HEX or 'auto', size as thickness, val as style). The eight per-side booleans (top/left/right/bottom/inside_h/inside_v), file_path, and table_index receive no explanation anywhere, leaving most parameters semantically opaque.

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

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

States a specific verb and resource ('Mengatur border tabel') and scopes it to a per-side custom border, which separates it from siblings like set_table_style_docx or set_cell_shading_docx. It also names the configurable attributes (color, size, style), but does not explicitly contrast itself with the nearest sibling.

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?

There is no when-to-use or when-not-to-use guidance. Nothing tells the agent how this differs in practice from set_table_style_docx or set_cell_shading_docx, nor that a file_path and table_index must already exist before calling.

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

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

No annotations are provided, so the description carries the full behavioral burden, and it does not disclose that this mutates the document file, whether changes are persisted, or any error conditions. It only restates the two option semantics, which belongs under parameter meaning rather than 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?

One compact sentence with the resource stated first and the two options enumerated after. No filler, though it could be slightly clearer on parameter types.

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

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

An output schema exists, so return values need not be described. However, for a mutation tool with zero annotations and 0% parameter coverage, the description leaves behavioral and one-parameter-type gaps that an agent would need to infer.

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 usefully explains repeat_header_rows (repeat header each page) and cant_split (prevent row splitting), which the bare schema does not. It does not clarify that repeat_header_rows is an integer count or the default behavior of cant_split=true.

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

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

States a specific verb+resource ('Mengatur opsi cetak/pagination tabel') and names the exact behaviors controlled. An agent can distinguish it from siblings like set_table_style_docx or set_table_borders_docx. No explicit sibling differentiation, but the purpose is unambiguous.

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

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

The description says what is configured but gives no when-to-use guidance, no prerequisites, and no alternatives. With ~40 sibling tools on tables, the agent gets no help deciding when pagination settings apply versus other table operations.

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

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

No annotations are provided, so the description carries the full burden, and it is silent on behavioral traits: whether the style is overwritten, whether a missing style errors or is ignored, permission requirements, or that the file must already exist. 'Mengubah' implies mutation but nothing else is disclosed.

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

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

A single front-loaded sentence with zero padding; the resource comes first and the examples follow. It earns its length, though it is arguably too terse for a 3-parameter mutation tool.

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

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

A mutation tool with no annotations, three fully required undocumented parameters, and 0% schema coverage needs considerably more than one sentence. An output schema exists, so return values need not be explained, but input semantics and the effect of the style change are missing.

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

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

Schema description coverage is 0% across three required parameters. The examples partially compensate for style_name by naming valid built-in values, but file_path and table_index are entirely unexplained in both schema and description, leaving an agent to guess indexing conventions.

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

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

States a specific verb (Mengubah/mengubah) and resource (template style bawaan Word untuk tabel), and the parenthetical examples ('Table Grid', 'Light Shading', 'Normal Table') pin down exactly what a 'style' is. It is distinguishable from siblings like set_cell_shading_docx or set_table_borders_docx, though it never names them. Clear, but no explicit sibling differentiation.

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

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

There is no when-to-use, when-not-to-use, or alternative guidance. It never says to prefer this over set_table_borders_docx or set_cell_shading_docx when an agent wants a different look, nor does it state any prerequisite (e.g., that the table must already exist).

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 behavioral burden for a mutation tool. It conveys that visible=False yields a transparent/borderless table, but says nothing about required file access, whether the setting is reversible, how table_index is resolved, or what happens on failure.

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

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

A single compact sentence that front-loads the action and then the key parameter meaning. No wasted words, though the brevity comes partly from omitting necessary information.

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

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

For a mutation tool with zero annotations and zero schema description coverage, the description leaves significant gaps: two of three parameters are unexplained and the relationship to set_table_borders_docx is undefined. An output schema exists, so return values need not be described, but that alone does not make the definition 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 for all three parameters. It usefully explains the semantics of visible (True/False meaning, which the bare boolean schema does not convey), but file_path and table_index are left completely undefined.

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

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

The description states a specific verb and resource ('Mengatur visibilitas border tabel' – sets table border visibility) and clarifies the effect of the visible flag. It is clear on its own, but does not explicitly distinguish itself from the closely named sibling set_table_borders_docx, leaving the agent to infer the split between 'visibility toggle' and 'border 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?

No when-to-use guidance is given, and the near-identical sibling set_table_borders_docx is never mentioned as the alternative. The parenthetical only explains the boolean values, which is parameter semantics rather than routing guidance.

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

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

No annotations are provided, so the description carries the full behavioral burden. It does not disclose that this is a mutating operation that rewrites the .docx file, whether changes are saved in place or reversible, whether table formatting/styles survive the split, or any permission/file-state requirements.

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

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

A single tight sentence with the key operation front-loaded and the critical indexing convention appended. No filler, though it is terse enough that behavioral detail is omitted rather than trimmed.

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

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

An output schema exists, so return values need not be explained. However, for an unannotated document-mutating tool with three undocumented parameters, the description omits the file-modification semantics, error conditions, and indexing scope that an agent would need.

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% across three required parameters. The description usefully clarifies that split_row_index is 0-indexed, but leaves file_path and table_index (notably how tables are indexed when multiple exist) entirely undefined, so it only partially compensates for the coverage gap.

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

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

States a specific verb (split/'Membagi') and resource (table), and identifies the exact insertion point via split_row_index. It is clearly distinguishable from sibling operations like merge_cells_docx or resize_table_docx, though it doesn't explicitly contrast itself with 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?

There is no statement of when to use this tool versus alternatives, no prerequisites (e.g. the table must exist and have enough rows), and no note about what happens if split_row_index is out of range or at row 0. Usage is only implied by the operation name.

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