docx_list_content_controls

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

No annotations are provided, so the description bears full responsibility. It correctly states 'Read-only' and enumerates the data returned. However, it does not disclose potential errors (e.g., file not found), performance considerations, or any other behavioral traits such as file locking or auth requirements. For a tool with no annotations, this is minimally adequate but incomplete.

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 concise: one sentence that communicates the core purpose and return attributes. It is front-loaded with the 'Read-only' flag. Every word is informative without redundancy. However, it could benefit from a slightly more structured enumeration of attributes.

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?

Given the tool has 2 parameters with no descriptions in the schema, no output schema, and a large set of sibling tools, the description should provide more context. It does not explain the parameters, describe the output format (array, object?), or specify the required file path. While it lists the return fields, crucial details for correct usage are missing. The tool's simplicity (list with basic fields) partially compensates, but completeness is still lacking.

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 schema has 0% description coverage, meaning the parameters docx_path and max_preview have no descriptions in the schema. The tool description does not explain what these parameters represent or how to use them. The agent must infer that docx_path is the file path and max_preview controls preview length. This is insufficient for correct invocation, especially since docx_path is required.

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 lists content controls and specifies the returned attributes (tag, alias, id, preview, text hash, complexity). However, it does not explicitly differentiate from sibling tools like docx_read_content_control, which likely reads a single content control. The verb 'list' sufficiently implies its function but lacks explicit exclusion.

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 begins with 'Read-only', which implies safe usage without modifications. However, it does not provide guidance on when to use this tool versus alternatives like docx_read_content_control or other listing tools. There is no mention of prerequisites or conditions under which it is appropriate to call.

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