hwp_draw_param_action

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

No annotations are provided, so the description carries full responsibility for behavioral disclosure. It explains what parameter sets are supported but does not disclose whether the action mutates the document, what side effects occur, whether permission or an open document is required, or what errors may result. This is a significant gap for an execution 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?

The description is front-loaded with the core purpose, then uses a scannable bullet list that earns its length by documenting many valid param sets. There is no filler or redundant restating of the schema, and the structure makes it easy for an agent to locate the relevant param set properties.

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 is complex, with free-form params and no annotations, and the description does a good job enumerating param sets. However, it does not explain the relationship between action_name and param_set_name, does not list valid action_name values, and gives no examples or prerequisites beyond doc_id. An agent could understand the param set vocabulary but would still struggle to confidently invoke the correct action.

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 0% schema description coverage, the description compensates well by enumerating all supported param_set_name values and listing key properties plus enums/type hints. doc_id and params are also described. However, action_name allowed values are not provided, and the property lists are labeled as 'key' rather than exhaustive, which leaves some ambiguity for free-form 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?

The description clearly states the tool executes an HWP action using draw/shape-related HParameterSet objects. It differentiates from table/file/style param actions by enumerating HDraw* param sets. However, it slightly overlaps with sibling hwp_shape_param_action, since both involve shape-related functionality, so it is not perfectly distinctive.

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

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

Usage is implied: use this tool when draw/shape-related HParameterSet operations are needed, and param_set_name must be one of the listed values. It does not explicitly state when not to use it, nor does it name alternatives like run_hwp_action or hwp_shape_param_action, leaving some routing to inference.

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