Manage document revisions: enable, list, accept, or reject changes in Hangul HWPX/HWP files for review.
변경 추적. action: enable(on, author?); list(range?); accept(ids?, all?); reject(ids?, all?)
| Name | Required | Description | Default |
|---|---|---|---|
| on | No | ||
| all | No | ||
| ids | No | ||
| range | No | Locator(글 범위: s0/p3:5-12, s0/p2..s0/p9, find:"…") | |
| action | Yes | ||
| author | No | ||
| handle | No | document.new/open이 준 handle |
Changes observed during successful MCP inspections.
v0.1.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 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.