Reads the body of an HWPX document and converts it to Markdown, useful for referencing or checking existing files.
HWPX 문서의 본문을 Markdown 으로 읽는다(참고 자료·기존 문서 확인용).
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | HWPX 파일 경로 |
Changes observed during successful MCP inspections.
v2.0.0Does 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.