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

No annotations are supplied, so the description carries the full burden. It usefully discloses the output shape (structure list + reusable skeleton Markdown), which is more than a bare 'analyze' would give, but it never states that the operation is read-only / non-mutating and mentions no auth, size, or failure 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, and the enumerated outputs are packed efficiently. The parenthetical list is dense but every item earns its place by telling the agent what comes back.

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 single-parameter, no-output-schema, read-only analysis tool, the description covers the essential return content (structure and skeleton Markdown), which compensates for the absent output schema. Missing only the safety/read-only assurance and sibling disambiguation.

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 one parameter at 100% schema description coverage, the schema already documents template_path fully, and the description adds no format, extension, or path-resolution detail beyond it. This matches the baseline for schema-driven params.

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 (분석) and resource (HWPX 서식), and enumerates what it extracts (표지·소제목·표·박스·글머리·서식 종류) plus the skeleton Markdown it emits. However, it does not differentiate itself from near-neighbors like hwpx_read or hwpx_preview, so an agent must still infer which one to 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?

There is no when-to-use guidance, no prerequisite (e.g. must the file be a .hwpx template rather than converted .hwp), and no mention of the sibling tools that overlap with this one. The agent gets a purpose but no routing signal.

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, and it does disclose meaningful behavior: automatic layout inspection/correction and template-reproduction checking, plus dual HWPX/PDF output. However it omits failure behavior, overwrite semantics, permission requirements, and what the tool returns, which matters for an unannotated build tool.

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

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

Two compact sentences, front-loaded with the purpose and output formats before the parenthetical detail and the content-format note. Every clause earns its place with no filler.

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, 3-required build tool with no annotations and no output schema, the description covers the core purpose and the auto-check behavior but leaves gaps: it never says what is returned (e.g., output file paths) nor how the required template_path/content/output_dir interact or fail.

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

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

Schema description coverage is 100%, so the schema already documents all five parameters. The description restates the content parameter's accepted forms (Markdown/JSON string or file path) but adds no meaning beyond the schema, making the baseline 3 appropriate.

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

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

The description names a specific verb (만든다/makes) and its resources (HWPX and PDF) plus the inputs it composes them from (template + content), so an agent can distinguish it from read/convert/analyze siblings. It stops short of explicitly naming which sibling to use instead, so it is clear but not fully differentiated.

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

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

There is no when-to-use or when-not-to-use guidance and no mention of alternatives such as hwpx_convert_hwp or hwpx_preview. The generation purpose is implied, but nothing tells the agent under what conditions this tool should be preferred over its 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?

With no annotations, the description carries the full disclosure burden. It does add real value by stating the Windows + Hangul dependency and that it returns the result path, but it omits what happens on failure, whether an existing target is overwritten, and whether conversion is lossy or reversible.

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

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

Two short clauses, front-loaded with the core action and followed immediately by the environment constraint and return value. Every sentence earns its place with no filler.

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 single-parameter tool with no output schema, the description covers the essential items: what it does, the environment prerequisite, and that it returns the result path. Only failure/mutation behavior is left 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?

Only one parameter, and the schema already documents it at 100% coverage ('.hwp 파일 경로'). The description adds no syntax, format, or path-resolution guidance beyond the schema, so the baseline of 3 applies.

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

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

States a specific verb ('변환한다') and resource pair (옛 .hwp → .hwpx), which is precise and unambiguous. No sibling tool performs conversion, so explicit differentiation isn't needed, but the description also doesn't situate itself against the rest of the hwpx_* family.

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 '(Windows + 한글 필요)' gives an environment prerequisite, which is useful context for deciding whether the tool can run at all. However, there is no explicit when-to-use guidance, no mention of when-not to use it, and no pointer to alternatives such as hwpx_build or hwpx_read for other workflows.

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 implies a read-only probe but never states whether it mutates anything, whether it can be slow or trigger engine installs, or what a successful versus failed diagnosis looks like.

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 identifying the inspected components with zero filler. Nothing is repeated from the name or removable.

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 zero-parameter diagnostic with no output schema, the description should at minimum say what the check reports (pass/fail per engine, install hints, remediation). It names the inspected targets but not the deliverable, leaving a meaningful gap for an agent deciding whether to call it.

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

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

The tool takes zero parameters, which is the baseline-4 case; there are no parameter semantics to compensate for. The empty schema is consistent with a simple environment probe.

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 (점검한다 / inspects) and a concrete resource (PDF conversion engines — Hangul/LibreOffice/built-in — plus Hangul automation status). An agent can tell it is a diagnostic tool rather than a conversion or build tool, though it does not explicitly name or contrast with 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 guidance on when to run this check versus simply attempting a conversion, and no mention of prerequisites or expected failure conditions. The diagnostic intent is implied by '점검' but the agent gets no when/when-not signal relative to siblings like hwpx_convert_hwp or hwpx_build.

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

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

No annotations provided, so the description carries full burden. It implies a read-only reference lookup but never states that it performs no mutation, requires no inputs, or returns static documentation content. The only behavioral hint is '돌려준다' (returns), which is minimal.

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

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

Single efficient sentence that front-loads what is returned. Appropriately sized for a zero-parameter reference tool, though it could be slightly more explicit about the tool's role.

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 zero-param, no-output-schema reference tool is simple, but in a 10-tool family the description doesn't clarify its role relative to hwpx_start_here or when an agent should reach for it. Adequate but leaves a real gap around usage context.

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?

Zero parameters, so baseline is 4. There is nothing to document and the description correctly implies no input is needed.

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

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

States a specific return ('내용 작성 문법' - content authoring syntax, Markdown extension / JSON block). However, it's a guide/returns-syntax tool whose purpose is largely tautological in a tool list ('format guide returns format syntax'). Doesn't clearly distinguish from sibling hwpx_start_here, which likely also covers authoring guidance.

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 vs alternatives. With siblings like hwpx_start_here, hwpx_build, and hwpx_convert_hwp, an agent needs to know this is a reference/lookup tool, not an action tool, and when to invoke it. None of that is 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 exist, so the description carries the full behavioral burden. It hints that numbered overview images are produced but never says whether files are written to disk, where, or whether the operation is read-only or has side effects – a meaningful gap for a tool that appears to generate image artifacts.

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 resource first and the return shape second; nothing is wasted. Slightly dense with a colon clause, but appropriately sized for the tool's simplicity.

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

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

With no output schema, the description must carry the return contract, and it does so only in outline (time-sorted list plus numbered image paths). Combined with the missing side-effect disclosure, it is minimally complete for a 1-parameter tool but not fully reassuring.

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

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

Schema description coverage is 100% for the single 'folder' parameter ('사진 폴더 또는 파일 경로'), so the schema already does the documentation. The description confirms the folder-or-file duality but adds no format or path-convention detail beyond that.

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 (사진 폴더 또는 파일), and even the shape of the result (촬영 시각 순 목록, 번호가 붙은 한눈에 보기 이미지 경로). This is enough for an agent to distinguish it from generic read tools. It does not, however, explicitly contrast itself with the closely related hwpx_photo_sheet 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?

Usage is only implied – an agent can infer 'call this when you want an overview of photos in a folder,' but no when/when-not conditions or alternatives (e.g., hwpx_photo_sheet, hwpx_preview) are named. Adequate but leaves routing to 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 burden. It discloses the dependency that the image is produced by hwpx_photos, but says nothing about the return format (path, URL, inline image), what happens if hwpx_photos has not been run, or whether the operation is a pure read.

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

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

One sentence, front-loaded with the return value and followed by a usage cue in parentheses; nothing is padded. Slightly terse 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?

With no output schema, the description should characterize the returned artifact; it does say it returns an image, but omits return format and failure behavior for a tool whose sole purpose is producing a derived asset.

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 parameter with 100% schema description coverage, so the schema already documents the folder path. The description adds no meaning beyond that, which is the expected baseline when the schema does the work.

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 (returns) and resource (the numbered photo-overview image produced by hwpx_photos), so an agent can distinguish it from the sibling hwpx_photos that generates the underlying data. It does not explicitly contrast with hwpx_preview or hwpx_read, but the resource is specific enough.

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 "사진 내용을 파악할 때 사용" gives an implied when-to-use (inspecting photo contents), and the reference to hwpx_photos implies a prerequisite ordering. However, it names no alternatives and no explicit when-not condition, leaving the agent to infer the choice against hwpx_photos/hwpx_preview.

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 convey that the output is an image rather than text, which is the key behavioral fact. It omits the return encoding/format, whether multiple pages are returned, size limits, and any note that the operation is a harmless read.

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 primary action first and the usage hint second; nothing is wasted and there is no filler.

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

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

The tool returns an image and has no output schema and no annotations, so the description should ideally state the return shape (e.g. image content/encoding) and confirm read-only behavior. It covers the essence but leaves those gaps for an agent that must handle the result.

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

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

Schema description coverage is 100%, so dpi, page, and pdf_path are already documented in the schema. The description adds no parameter-level detail (e.g. default page, dpi effect) beyond that baseline.

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 concrete verb and output ('PDF 한 쪽을 이미지로 돌려준다') and adds the intent (visual verification), so the agent knows exactly what comes back. However, the tool name is hwpx_preview while the description talks only about PDF pages, and no sibling (e.g. hwpx_photos, hwpx_photo_sheet) is named to disambiguate.

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 '결과를 눈으로 확인할 때 사용' gives a usage context, which is more than nothing. But it offers no when-not guidance and never distinguishes this from the image-producing siblings hwpx_photos or hwpx_photo_sheet.

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 output format (Markdown) and scope (body text), but says nothing about read-only safety, required permissions, handling of missing files, or what portion of the document is included.

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 that front-loads the core action and appends the usage context. 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?

For a single-parameter read tool with no output schema, the description covers the essential operation and return format. It could say more about Markdown fidelity or document scope, but nothing critical for invocation is missing.

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

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

Schema description coverage is 100% and the single required path parameter is already documented as 'HWPX 파일 경로'. The description adds no syntax, format, or constraint details beyond the schema, so baseline 3 applies.

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

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

States a specific verb and resource: reads the body of an HWPX document, and names the output format (Markdown). That is clear enough to distinguish it from build/convert/preview siblings, but it never explicitly contrasts itself with hwpx_analyze or hwpx_preview.

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 a use case—checking reference or existing documents—so usage is hinted at. There is no explicit when-to-use versus alternatives or when-not-to-use guidance, leaving the agent to infer routing among 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 what the call yields (the usage order and rules of the toolset), which is exactly the behavioral information an orientation tool needs to convey. With zero parameters there is no mutation or auth risk to disclose, so the remaining gap is minor.

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

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

Two short sentences with zero filler, and the directive (call first) is front-loaded ahead of the explanation of what it returns. 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?

For a parameterless, annotation-free orientation tool with no output schema, the description supplies what an agent needs: it is the first call and it returns ordering rules. It could be slightly richer by hinting at the sequence of the sibling tools, but nothing essential is missing.

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

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

The tool takes no parameters, so there is nothing for the description to clarify beyond the schema; baseline 4 applies. The description correctly avoids inventing arguments that the empty schema does not support.

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 function: this is the entry-point tool that returns the toolset's usage order and rules. It is distinguishable from siblings like hwpx_format_guide because it frames itself as the mandatory first call rather than a topic-specific guide. It stops short of naming any sibling explicitly, so it lacks the sharper differentiation a 5 would need.

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?

"가장 먼저 호출" (call this first) is an explicit when-to-use directive that an agent can act on without inference. It does not, however, say when NOT to call it or how it relates to the other nine tools beyond ordering.

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