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

With no annotations, the description carries the full behavioral burden. It discloses the four operations and their argument shapes, but says nothing about what reset actually clears, whether highlight is additive or replacing, permission needs, or side effects. For a 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?

Two dense, front-loaded clauses: the resource definition first, then the per-action signatures. No filler, and the most routing-relevant information (action names and args) is compact and scannable.

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 7-parameter tool with a nested CharProps object, no output schema, and no annotations, the description covers the operations but leaves the props vocabulary open-ended ('…') and omits return/effect semantics. Adequate but not complete for the tool's complexity.

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

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

Schema coverage is 71%, and the description adds meaningful value by mapping each action to its required parameters, which the schema alone does not express for a discriminated action enum. It does not elaborate on CharProps contents, but the action-parameter mapping is the key missing semantics and is supplied.

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 the resource precisely (character appearance: font, size, color, bold, underline) and implies a clear contrast with the sibling para_format. The action signatures (set/highlight/reset/copy) reinforce what the tool operates on, though it never explicitly states the character-level vs paragraph-level distinction.

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

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

The action signatures act as an implicit routing guide by showing which parameters each action takes (set→range+props, highlight→range+color?, reset→range, copy→from+to). However, there is no guidance on when to choose this tool over para_format or style, nor any stated prerequisites.

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

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

No annotations are provided, so the description carries the full behavioral burden, and it discloses almost nothing: no side effects, no indication that insert mutates a live document, no note that delete is destructive/irreversible, no permission or handle prerequisites. Only the verb choice hints at mutation.

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 compact and front-loads the resource name, with zero filler words. But the density tips into under-specification: a single run-on signature line is the entire description, leaving no room for the operational context a 13-parameter tool needs.

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

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

For a 13-parameter tool with nested objects, no output schema, and no annotations, the description is far too thin. It omits data format expectations, the meaning of handle, return behavior, and error/edge conditions, so an agent has significant gaps to fill by guesswork.

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 only 38% (at, frame, margin, handle, target are documented in the schema), so the description is expected to compensate. It lists parameter names grouped by action—adding the useful action-scoping the schema lacks—but gives no meaning for data, style, caption, the boolean flags, or the type enum, and never explains handle, at, or target semantics.

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

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

The description opens with only the resource name ("차트" / chart) and then enumerates insert/update/delete actions, so the operation set is conveyed but there is no prose stating what the tool does or what a 'chart' object is. It is essentially a signature restatement rather than a purpose statement, and it does not differentiate itself from siblings like table or shape beyond the noun.

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 action-scoped parameter lists implicitly tell the agent which arguments each action needs (insert→at, update/delete→target), which is real routing guidance absent from the schema. However, there is no explicit when-to-use, no statement of preconditions (e.g. requiring an open document handle), and no mention of alternatives among the 22 sibling tools.

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

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

With no annotations, the description carries the full behavioral burden. It mentions the Hangul engine, hinting at a runtime dependency, but says nothing about whether the target file is overwritten by default, what happens when out_path is omitted, failure behavior for unsupported files, or permissions. For a file-writing 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?

Extremely short and front-loaded: the conversion pair comes first, the call shape second. Nothing is wasted, though the extreme terseness borders on under-specification.

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 4-parameter conversion tool with no annotations and no output schema, the description omits default behavior, output location semantics, and error handling. An agent could invoke it, but not confidently predict the side effects.

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

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

Schema coverage is 50% (path and out_path documented, action and overwrite bare), so the description must compensate somewhat. The inline signature usefully marks out_path and overwrite as optional, but adds no semantics for overwrite's default or out_path's fallback behavior.

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 (convert) and both resources (.hwp → .hwpx), plus the engine used (한글 엔진), so an agent knows exactly what operation this performs. It does not explicitly distinguish itself from the many sibling tools, but the format-pair makes its niche clear.

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 siblings (read, document, render, etc.) or when conversion is unnecessary. The only usage cue is the inline call signature, which shows how to call it, not when.

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

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

With no annotations, the description carries the full burden. It does disclose one real behavioral trait — that batch() runs the listed calls sequentially inside a single transaction — and the force/discard/overwrite parentheticals hint at consequence-bearing flags. It says nothing about handle lifetime, permission requirements, error behavior, or what happens to unsaved edits on close, which is a substantial gap for a heavily 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?

One dense line: purpose summary first, then an action-by-action signature list. Nothing is wasted, though the packed semicolon syntax is terse and could be hard to scan for a nine-parameter 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?

Given nine parameters, nested call objects, no annotations, and no output schema, the description covers purpose and per-action arguments but omits the handle lifecycle that ties this tool to every sibling, plus any indication of what list()/info() return. Adequate as a routing label, incomplete as an operating manual.

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 only 44%, but the description compensates by mapping parameters to the specific action that accepts them (new(target_version), open(path), save(force), save_as(path, overwrite), close(discard), batch(calls), meta(set)), a relationship the flat schema does not express. Only the handle parameter is left entirely to the schema.

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

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

The description names concrete verbs (open, create, save, close, info) on the document resource and enumerates all ten actions of a multiplexer tool, so an agent knows this is the document-lifecycle entry point. It implicitly separates itself from sibling content tools (page, table, image, style), though it never states that relationship 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?

Listing each action with its parameter signature implies when each applies (e.g. open pairs with path, save_as with path/overwrite), but there is no explicit ordering guidance such as 'open/new first to obtain a handle, then pass it to editing tools', and no when-not-to-use or alternative routing.

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

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

With no annotations, the description carries the full burden. It adds real behavioral value by mapping each action to its accepted parameters, which the schema does not express. But it is silent on destructive/reversible behavior of delete, permissions, or side effects on the document — significant omissions for a mutation 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 dense line, front-loaded with the resource identity followed by the action/parameter map. No wasted prose, though the parameter enumeration is compact to the point of being a schema restatement.

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 15-parameter tool with nested objects and no output schema or annotations, the action-to-parameter mapping covers the most important gap (which params apply where). But key semantics for script/latex/display and mutation behavior remain undocumented, so it is only adequately complete.

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

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

Schema coverage is only 40% across 15 parameters, so the description must compensate. It does group parameters under the action that accepts them, adding meaning beyond the flat schema, but it explains no parameter semantics (script vs latex, display, number, baseline) and leaves the nested frame/margin objects to the schema.

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

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

The description names the resource (수식/equation, in Hangul script or LaTeX form) and enumerates the four distinct operations (insert, update, delete, convert_latex), so an agent can tell what the tool does without opening the schema. It does not differentiate itself from siblings like image, shape, or chart, which also create document objects.

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?

Listing the parameter set per action (e.g., update takes target; delete takes target; convert_latex takes latex) is genuinely useful routing guidance for choosing an action. However, it gives no when-to-use vs when-not guidance, no prerequisites, and no indication of when to prefer script vs latex input.

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 largely does not. It never states side effects (e.g. whether remove deletes the field permanently – only the keep_text parameter hints at it), whether edits are saved, what authorization or handle context is needed, or what non-read actions return.

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

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

Extremely compact and front-loaded: one short resource clause followed by the action menu. The dense signature notation is efficient, though its terse style makes it slightly harder to parse than plain prose would be.

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

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

For a 6-action, 11-parameter dispatcher with no annotations and no output schema, the description covers the action surface and per-action parameter mapping, which is the core need. It still omits return behavior, error cases, and the meaning of several parameters, so it is adequate but not full.

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 only 27% across 11 parameters, so the description must compensate and partly does: it maps each parameter to its action and marks optionality with '?' (e.g. set(value, name?, target?), remove(name, keep_text?)). However, it never explains what values, guide, or memo actually contain, leaving key semantics 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 names the resource (누름틀·셀 필드, i.e. form/click-here fields) and its purpose (양식 채우기, form filling), then enumerates the six actions. That is enough to know roughly what the tool does, but it is essentially an API signature dump, and nothing distinguishes it from siblings like table, text, or document beyond the resource noun.

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 action list hints at per-action usage (get by name, set by value), but that is schema-level enumeration rather than selection guidance for the agent.

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 discloses nothing: no permission requirements, no note that delete/replace are destructive or irreversible, no mention of what happens to the target on overwrite, and no return-value description for extract. It is a bare signature.

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 compact with no filler sentences, but the single run-on signature string is hard to parse and largely duplicates information already in the input schema, so its density buys less than it costs.

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 21-parameter tool with no annotations and no output schema, the definition omits too much: the 'handle' parameter tying it to document.new/open is unexplained, extract's output/return is not described, and no action's side effects 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?

With 62% schema coverage and 21 parameters, the schema alone does not say which parameters belong to which action. The description's per-action parameter lists (e.g. insert takes at/path/data/frame..., replace takes only target/path/data) add real conditional-applicability meaning the flat schema cannot express. It stops short of explaining individual parameter semantics.

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

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

The description opens with '그림' (picture) and enumerates five action verbs (insert/update/replace/delete/extract) against the 'image' resource, so the general domain is clear. However it is essentially a signature dump that restates the schema rather than stating purpose, and it draws no boundary against siblings like shape, chart, or table.

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

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

There is no guidance on when to choose insert vs update vs replace, no prerequisites (e.g. that update/delete need an existing target), and no mention of alternative tools. The action list implies usage but never states a condition for selecting one.

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 shows an 'op' parameter (add/update/remove) per action but never states that these operations mutate the document, whether removal is reversible, what permissions or document state are needed, or what 'list' returns. For a mutation-capable tool this is a significant disclosure 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 line that front-loads the resource list and then the per-action signatures. Nothing is padded, and the action:signature format is scannable. It leans on terse abbreviations (op?, url?) but stays compact.

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

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

For an 11-parameter, four-action tool with no annotations, no output schema, and only 36% schema coverage, the action-to-parameter mapping is the most valuable thing the description could provide and it does provide it. It remains incomplete on handle usage, mutation/return behavior, and parameter meaning, so it is adequate rather than thorough.

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

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

Schema description coverage is only 36% across 11 parameters, so the description must compensate. It does add genuine value by mapping which parameters belong to which action (e.g. cross_ref takes at, show, target, bookmark, hyperlink), which the flat schema cannot express. However, it omits 'handle' entirely and gives no meaning for url, name, or op beyond their names.

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

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

The description names the three resources it governs (hyperlink, bookmark, cross-reference) and enumerates four concrete actions, so an agent knows this is the link/bookmark/cross-ref manipulation tool. It is clear and specific, though it never explicitly contrasts itself with unrelated siblings like field or toc (which could plausibly overlap with cross-references).

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 action list implies what each subcommand does structurally, but there is no guidance on when to choose hyperlink vs cross_ref vs bookmark, no prerequisites, and no mention that a document handle from an open document is required. The agent must infer selection entirely from the parameter signatures.

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 disclosure burden, yet it only implies mutation via add/update/delete. It omits whether operations require specific permissions or an open document handle, what delete destroys, and whether results are returned or confirmed.

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 very compact and front-loads the resource name before the action breakdown, which is efficient. The telegraphic action-signature style is dense and borderline under-specified rather than wasteful.

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 tool with no output schema, no annotations, and two undocumented parameters, the description is not complete enough. It covers the action-to-parameter mapping but omits handle usage, target/range semantics, and any return or error 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 coverage is only 33%, so the description must compensate, and it does add value by mapping which parameters each action consumes (add: range/text/author, update: target/text, delete: target). But the 6th parameter 'handle' is never mentioned in the description, and 'target' semantics are left 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 names the resource (메모/memo) and enumerates the four supported actions (add/update/delete/list) with their parameter signatures, so the general purpose is inferable. However it never states what a 'memo' actually attaches to or does within the document, and it gives no contrast with the closely-named sibling 'note', so the boundary remains ambiguous.

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 explicit when-to-use, when-not-to-use, or alternative-selection guidance. The action signatures imply usage but nothing tells the agent when memo is preferable to the sibling 'note' tool or what prerequisite state (open document) is required.

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 conveys that insert/update/delete/settings are mutations, but says nothing about permissions, the role of the handle parameter in targeting a document, side effects on numbering/references, or what happens on failure. For an unannotated 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?

Extremely compact and well front-loaded: resource name first, then a clean action-to-parameter list. It wastes no words, though the telegram-style syntax sacrifices readability and 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?

For an 18-parameter mutation tool with no output schema and no annotations, the description is too thin. It omits how the target document is identified (handle), whether any of the many settings fields are mutually exclusive, and any indication of success/failure behavior, leaving the agent to infer far too much.

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 only 39% across 18 flat parameters, so the description needs to compensate. It does add real value by grouping parameters under each action (e.g. settings takes format/start/restart/placement/separator/spacing/prefix/suffix), which the schema does not express, but it never explains the meaning or expected format of any individual parameter.

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

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

The description opens with the resource (각주·미주 = footnote/endnote) and enumerates the four operations, so an agent immediately knows this tool manages footnote/endnote objects and is distinct from siblings like memo, field, or toc. It is a terse noun-plus-signatures form rather than a full verb+resource sentence, 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?

By mapping each action to its parameter set (insert uses at/kind/text, update uses target/text, etc.) it implies which action to pick for a given intent, but it never states when to choose footnote vs endnote or when this tool is preferable to memo or field. Usage is inferable rather than explicit.

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

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

No annotations are provided, so the description carries the full disclosure burden, and it does little: only 'remove(range)' hints at destruction, with no statement about what gets destroyed, reversibility, permission requirements, or side effects of applying/updating definitions. For a mutation-capable tool with zero annotation coverage 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?

It is short and front-loads the domain, and the signature notation is compact. But the notation is cryptic and terse to the point of under-specification, so brevity here trades away clarity rather than earning it.

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 12-parameter tool with a nested 'levels' object, no output schema, no annotations, and 33% schema coverage needs more than a signature list. Missing behavioral context (definition lifecycle, error cases, how def/handle interact) leaves the definition incomplete for reliable 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?

With only 33% schema coverage across 12 parameters, the description partially compensates by mapping parameters to actions and marking optionals with '?' (e.g. apply(range, kind, def?, level?)), which the flat schema does not convey. However, the semantics of many parameters (at, set, delta, start, handle, levels) are left to the sparse schema descriptions.

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

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

The description names the resource domain (문단 번호·글머리표·개요 번호 — paragraph numbering, bullets, outline numbering) but supplies no clear verb for the tool as a whole; it is a topic label followed by an action inventory. An agent can infer this is the numbering-management tool versus siblings like para_format or style, but the overall purpose is implied rather than stated.

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 action signatures hint at what each operation does (define, apply, level, restart, remove, update), but there is no guidance on when to choose this tool, when not to, or how to pick between actions for a given task. No alternatives or prerequisites are named.

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 does not meet it. It never states that every action mutates the document, that a valid handle is required (the schema's handle description hints at this but the description does not), what happens to existing settings when an action is re-applied, or how header/footer op=remove behaves.

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 but front-loaded block: the topic comes first, then the action signatures. Given 10 actions and 40 parameters, this is a compact representation with essentially no filler sentences. It could be more scannable if the action list were broken out line by line, but 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?

For a high-complexity dispatcher (10 actions, 40 params, nested objects, no output schema, no annotations), the description provides only the action-to-parameter map. It omits return/effect information, error conditions, whether actions are idempotent, and the handle lifecycle. An agent could pick an action but not reliably predict the outcome.

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 only 35% across 40 parameters, so the description should compensate more than it does. Its real contribution is the per-action parameter grouping, which the flat schema with additionalProperties=false cannot express — the agent learns that page_number takes side_char but columns takes separator. However, several parameters (items, fill, widths, hide_first, side_char) remain undocumented in both schema and description, and no enum value meanings are added.

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

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

The leading clause names the resource domain concretely (paper, margins, columns, page numbers, headers/footers, breaks, borders, master page), and the action list enumerates the concrete operations. An agent can tell this is the page/section-layout tool rather than char_format or para_format. It stops short of explicitly contrasting itself with siblings such as style or section-adjacent tools.

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 action names imply use cases (setup, header, footer, break), but the agent is left to infer which action to pick and when a page-level tool is preferable to a paragraph- or section-level sibling.

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 disclosure burden. It does add genuinely behavioral content — which parameters each action consumes — but it never says what 'reset' reverts to (theme default vs. document default), whether the operation is destructive/reversible, or what permissions or document state are required.

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

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

Two compact lines, front-loaded with the domain statement followed by the action signature block — no filler or restatement of the title. The heavy abbreviation and parenthetical ellipsis in the props list cost it the top mark, since brevity shades into under-specification.

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 no annotations and no output schema, the definition is only partly sufficient: the nested 'props' object has no enumerated keys, so the agent must infer the ParaProps fields from the parenthetical list (정렬·여백·줄 간격·탭·테두리). The per-action mapping is helpful, but return behavior and prop key names remain unknown.

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 83%, so the baseline is 3, and the description earns above it by supplying per-action parameter bindings the flat schema cannot express (set→range+props, reset→range, copy→from+to). It also flags that 'props' is a ParaProps object accepting numeric or '12pt'/'20mm' lengths and '#RRGGBB' colors.

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: paragraph formatting covering alignment, spacing, line spacing, tabs, borders. The Korean gloss '문단 모양' clearly separates it from the sibling char_format, though that distinction is implicit in the wording rather than an explicit contrast. An agent can identify the domain without opening the schema.

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

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

The action signatures ('set(range, props); reset(range); copy(from, to)') implicitly tell the agent which mode to pick for which task, which is more than nothing. But there is no explicit when-to-use guidance, no statement of prerequisites (handle, active selection/cursor), and no routing to style/char_format alternatives.

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

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

No annotations are provided, so the description carries the full burden. The name and content imply a non-destructive read, but it never explicitly states read-only/safe behavior, permission or auth needs, or what pagination/offset semantics apply. The offset/limit params only hint at paging behavior without explanation.

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

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

Front-loaded with the purpose, then densely encodes five action signatures with no filler. Every token carries information. It is terse to the point of being cryptic, but 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?

With 12 parameters, 5 actions, and no output schema, the description explains parameter routing but not what each mode returns (outline vs text vs format vs find) or how 'handle' ties requests to a document. For a multi-modal dispatcher this leaves real gaps about the shape of results.

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

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

Schema coverage is only 25%, so the description must compensate, and it does: it maps each parameter to the action it belongs to (e.g., outline takes range/depth/offset/limit, find takes query/regex/case/whole_word/range/include_deleted/limit). That action-to-param mapping adds substantial value beyond the schema. It omits the shared 'handle' parameter, though the schema documents that one.

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

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

States a specific verb and resource (문서 읽기) and enumerates its five read modes: outline, text, node, format, find. An agent can understand the tool reads document content in multiple modes. However, it does not differentiate itself from overlapping siblings such as 'text', 'document', or 'page', which an agent might otherwise pick.

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, when-not-to-use, or alternative guidance is given. The action enumeration implies the modes exist but never says which to prefer or when to pick this tool over the sibling 'text'/'document' tools. Usage must be inferred entirely.

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 of behavioral disclosure. It mentions out_path for pdf and normalize, hinting at file writes, but does not describe permissions, side effects, reversibility, or output behavior for any action.

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

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

The description is a single compact line with no filler, and the capability list is front-loaded before the action-parameter mapping. It is terse to the point of being cryptic, but every token serves the dispatch purpose.

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

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

Given seven actions, nine parameters, no annotations, and no output schema, the description is too thin. It maps actions to parameters but leaves action semantics, return values, and behavioral constraints largely 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?

Schema description coverage is only 33%, so the description must compensate. It does add useful action-parameter mapping (e.g., pdf uses out_path and optional pages, page_image uses page and optional dpi), but it does not explain the meaning, format, or constraints of most parameters.

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

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

The description identifies the tool as a Hangul engine and lists seven operations (PDF, page image, check, layout, update_fields, view, normalize), but it does not state an overarching purpose in a clear verb+resource sentence. It also provides no differentiation from sibling tools such as convert, image, or page.

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

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

The description offers no explicit when-to-use guidance, no conditions for selecting this tool over alternatives, and no named alternatives from the sibling list. Usage is only implied by the action list.

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

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

No annotations are provided, so the description carries the full behavioral burden, yet it discloses nothing about permissions, whether delete/ungroup are reversible, how existing shapes behave on update, or what the call returns. It only names the mutation verbs.

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 dense signature dump rather than prose, but it is front-loaded with the domain, lists the actions in order, and wastes no words. For 21 parameters this is an efficient format, though it reads as machine-generated and lacks any sentence-level explanation.

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 a 21-parameter multi-action tool with no annotations and no output schema, the description covers the dispatch logic but leaves behavior, prerequisites, side effects, and response shape entirely unexplained. Adequate to start a call, incomplete for safe use.

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

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

With 62% schema coverage and 21 parameters, the key addition is the conditional mapping of parameters to actions (e.g. points only for insert/update, targets only for group, target only for update/delete). The schema cannot express this action-parameter coupling, so the description meaningfully compensates. It still omits syntax details such as locator formats and unit rules, which the schema partially covers.

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

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

The opening '도형·글상자·묶기' (shapes, text boxes, grouping) states the resource clearly, and the action list (insert/update/delete/group/ungroup) gives an agent an unambiguous verb set. It does not explicitly differentiate itself from sibling domain tools like table or chart, but within its own scope the purpose is precise.

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 per-action parameter signatures imply which action to pick for which goal, but there is no explicit when-to-use/when-not-to-use guidance and no comparison to alternatives such as text or table for placing content. Usage is inferable from the action names rather than 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 implies mutation via define/update/delete and hints that delete can cascade ('replace_with?'), but says nothing about reversibility, permissions, side effects on existing content, or what applying a style does to the target range. For a multi-action 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 dense, front-loaded line: purpose first, then action-by-action signatures with optional markers. No filler, though the compact signature syntax is terse enough that parsing it takes some effort.

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

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

For a 12-parameter tool with nested CharProps/ParaProps objects, no annotations and no output schema, the description covers the action surface but omits return info (e.g., what list returns), defaults, and the semantics of several params. It is not enough on its own 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?

With only 33% schema coverage the description must compensate, and it does add real value by mapping which parameters belong to which action (e.g., apply uses range+name, delete uses name+replace_with). However it does not explain the meaning of ambiguous params like base, next, or eng_name, leaving much semantic work undone.

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

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

The description opens with a specific verb+resource ('스타일 정의·적용' = style definition/application) and enumerates the concrete operations (list/define/update/apply/delete). An agent can tell this tool manipulates document styles, distinct from siblings like char_format and para_format. It stops short of explicitly naming those siblings as alternatives.

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

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

The action list implies usage but never states when to choose this tool over char_format/para_format/numbering, nor any prerequisites. There are no when-to-use or when-not-to-use conditions, only a signature enumeration.

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, yet it is purely an action-and-signature catalog. Destructive actions like delete_rows, delete_cols, and delete never warn about data loss, and there is no mention of permissions, reversibility, 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?

The description is dense and front-loaded with a Korean category summary before the action catalog. Every clause maps an action to its parameters with no filler, which is efficient for an 18-action omnibus tool, though the raw catalog form is heavy to parse.

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

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

For a tool with 18 actions, 46 parameters, no annotations, and no output schema, the description covers action-to-parameter mapping but omits behavioral guidance, destructive-action warnings, and any indication of return values. An agent can pick an action but not predict its effects or output.

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

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

Schema description coverage is only 33% across 46 parameters, so the description must compensate, and it partially does by mapping which parameters belong to each action (e.g., create takes at, rows, cols, data?, frame?...). However, it explains no parameter meaning or format (what keys, expr, or data accept), leaving semantics largely 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 states a specific resource (표/table) with the families of operations it covers: create, cell, merge/split, rows/cols, formatting, formulas, sorting. This clearly distinguishes it from siblings like char_format, para_format, and page, which operate on non-table 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?

It enumerates the available actions but gives no guidance on when to choose this tool versus siblings (e.g., document, text), nor any prerequisites or exclusions. The action list implies scope but never states selection conditions.

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

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

No annotations are provided, so the description carries the full disclosure burden, yet it says nothing about mutation semantics, reversibility/undo, permissions, or side effects of operations like replace_all across a range. For a 7-action write-oriented 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?

The action inventory is front-loaded and each action's signature is packed into a single dense line with no filler. It is terse rather than verbose, which is appropriate for a parameter-heavy dispatcher 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?

Given 7 actions, 15 flat parameters, no annotations, and no output schema, the description covers the action-to-parameter mapping but omits behavior, error modes, and return information an agent would need to invoke mutations safely. Adequate but clearly short of complete for this complexity.

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

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

Schema coverage is only 33%, so the description must compensate, and it does add real value by mapping which parameters belong to which action in a flat 15-property schema. However, several parameters (side_char, format, style, case, regex) get no semantic explanation beyond appearing in a signature, so the 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 names the exact operations (insert, delete, replace, replace_all, copy, move, insert_code) on text and lists each action's signature, so an agent knows the tool's scope despite the vague name 'text'. It does not, however, distinguish this tool from siblings like char_format or para_format, which handle adjacent concerns.

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?

Listing per-action parameter sets implicitly guides which action to pick, but there is no explicit when-to-use/when-not statement or routing to alternatives (e.g., formatting vs. editing). Usage is inferred rather than 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 none of it: nothing about what 'delete'/'rebuild' destroy, whether changes are reversible, permissions required, or that the 'handle' parameter (present in the schema) is mandatory in practice. The action-per-argument map is structural, not behavioral.

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

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

Extremely compact and front-loaded: the resource is named first, then each action with its argument set in a consistent semicolon-delimited form. Nothing is padded, though the compression is so aggressive that some semantic detail is sacrificed for brevity.

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

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

For a mutation tool with 11 parameters, no annotations, no output schema, and 18% schema coverage, the description leaves major gaps: the required handle/target relationships, mutation side effects, and return behavior are all unaddressed. An agent could not confidently invoke rebuild or delete from this text alone.

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 only 18% across 11 parameters, so the description must compensate, and it partly does by grouping parameters under the action that consumes them (?-marked as optional) — information the schema does not convey. It still omits meaning for handle, target, styles, include, and levels beyond their names, so it is helpful but incomplete.

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 terse '차례' (table of contents) plus an enumerated action dispatch — insert/rebuild/delete with their parameter signatures — tells an agent exactly what resource is manipulated and how each mode is shaped. It is not, however, distinguished from any sibling (style, numbering, page, field), 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?

The description enumerates the three actions and their arguments but never says when to choose insert vs rebuild vs delete, nor what preconditions exist (e.g., that a TOC must already exist for rebuild/delete). No alternatives are named. The only implied guidance is the action-per-shape listing.

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 does not meet it. It never states that accept/reject permanently mutate the document, whether the changes are reversible, what permissions are needed, or what the response contains; verbs like 'accept' imply mutation but nothing 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 dense line, front-loaded with the resource and then structured as action-plus-parameters, with no wasted words. It is arguably too compressed, but every token carries information.

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

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

For a 7-parameter tool with no annotations, no output schema, and 29% schema coverage, the description leaves major gaps: the document 'handle' requirement, the type/shape of 'ids', and the destructive semantics of accept/reject. An agent could not confidently call the mutating actions from this description alone.

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 only 29%, and the description partially compensates by mapping parameters to actions: 'on'/'author' for enable, 'range' for list, 'ids'/'all' for accept/reject. That mapping is real added value, but 'handle' (required in practice) and the untyped 'ids' parameter are never explained in either place.

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 resource ('변경 추적' = change tracking) and enumerates the four operations it supports (enable/list/accept/reject), so an agent knows this handles tracked revisions. It does not explicitly contrast itself with any sibling, but the operation set is distinct enough from document-element tools to be identifiable.

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 action list with parenthesized parameters implies which operation to pick and what each accepts, which is genuine usage signal. However, there is no explicit when-to-use guidance, no prerequisites (e.g., must a document be open first, as 'handle' hints), and no exclusions or alternatives named.

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 behavioral burden. It mentions patch operations including 'remove' and 'remove_attr' that are clearly destructive, but it does not disclose permissions, reversibility, side effects, or any response behavior, leaving the agent unable to assess safety.

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

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

The description is extremely concise and front-loaded: the core scope statement comes first, followed by a compact action signature list. Every token earns its place, and there is no filler or redundancy.

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

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

With 9 parameters, no annotations, no output schema, and only 11% schema description coverage, the description is not complete enough. It omits the 'handle' parameter's role, return values, error handling, and the semantics of key operations, leaving significant gaps for an agent to correctly invoke the 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 only 11%, so the description must compensate. It partially does so by grouping parameters by action (e.g., get uses part, xpath, optional limit; patch uses part, xpath, op, optional xml/name/value), but it does not explain what 'part' means, how xpath is interpreted, or what the op enum values do.

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 the tool is a general-purpose XML gateway for properties that lack dedicated semantic tools, and it enumerates the available actions (parts, get, patch) with their signatures. This gives a clear verb+resource purpose and implicitly distinguishes the tool from semantic siblings, 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?

The parenthetical '의미 도구가 없는 속성' implies the tool should be used as a fallback when no semantic tool exists, which is useful implied guidance. However, it does not state when not to use the tool, nor does it name or contrast any specific sibling alternatives.

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