rhino_text_dot

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

Annotations only declare readOnlyHint=false, which is consistent with the 'Add' verb, so no contradiction. The description adds the valuable behavioral detail that the resulting object is camera-facing, but does not disclose other useful traits such as the object being persisted in the document, undo implications, or whether an active document is required.

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 11-word sentence with zero waste: verb first, resource second, distinguishing behavior last. The 'in Rhino' fragment is mildly redundant given the tool namespace, but it does not detract from the crispness.

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 simple creation tool with an output schema, the description conveys the core behavior adequately. Gaps remain: it never states that text and location are required inputs, gives no indication that doc_id can target a specific document, and offers no guidance distinguishing it from the related annotation siblings. It is workable but not complete.

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 0% for the top-level args parameter, and the description says nothing about parameters. The nested property titles (text, location, layer, doc_id) are somewhat self-explanatory and doc_id/x/y/z carry inline descriptions, but the tool description itself does not compensate for the coverage gap as required at this low coverage level.

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?

Uses a specific verb ('Add') with a resource ('small label') and a distinguishing trait ('always faces the camera'), which is exactly what separates a text dot from plain text/annotation tools among the many siblings (rhino_text, rhino_add_text, rhino_add_text_object). An agent can tell what this does and when it differs without opening the schema.

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 'always faces the camera' trait implies the use case: choose this when a view-independent/camera-facing label is needed. However, there is no explicit when-to-use or when-not-to-use guidance, and the sibling list contains highly similar tools like rhino_add_dot and rhino_text whose boundaries are left entirely to inference.

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