wps_word_add_comment

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 core behavior (adds a comment, find_text behavior), but it doesn't mention side effects (e.g., whether the document is saved, whether view changes), permissions required, or what happens if find_text is provided but not found. This is adequate but not thorough for a mutation 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 extremely concise—only two sentences. The first sentence states the purpose, and the second clarifies the parameter behavior. No wasted words; every sentence contributes essential information. This is excellent conciseness.

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 only 2 parameters, no output schema, and no annotations, the description covers the basic usage and the key parameter interaction. However, it lacks details expected for a mutation tool: error handling (what if find_text not found?), where the comment appears in the UI, and whether the comment is visible to others. It is minimally complete but could be more robust.

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% (both text and find_text have descriptions in the schema), so the baseline is 3. The description adds value by explaining the relationship between find_text and the comment placement (if omitted, comment goes to document start), which goes beyond the schema's '要批注的目标文字（可选）'. This extra context justifies a point above 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 clearly states the tool adds a comment ('添加批注') and explains the two modes: with find_text to apply the comment to a specific text occurrence, without it the comment is placed at the first character of the document. This is a specific verb+resource and helps distinguish from sibling tools like wps_word_get_comments and wps_word_delete_comment, though it loses a point for not naming those siblings 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 description implicitly notes when to use each parameter (with find_text for targeted comments, without for document-start comments), but it does not explain when to choose this tool over alternatives such as wps_word_insert_text or wps_word_replace, nor does it mention prerequisites like needing a document to be open. Guidance is functional but not complete regarding alternatives.

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