bounding_boxes

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

Annotations declare readOnlyHint=false, destructiveHint=false, and idempotentHint=false, so the mutation/non-destructive profile is already covered. The description adds real value with "Temporary visual aid" and "Nothing to put in code," telling the agent the boxes are ephemeral and not source artifacts, but it does not say how they are cleared or how long they persist.

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?

Two short sentences, front-loaded with the bracketed [DEBUG VISUAL] tag and immediately followed by the caveat and the action. Efficient and easy to scan, though the tag-plus-caveat occupies half the text for framing rather than capability.

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 an 8-parameter, all-optional debug overlay with full schema coverage and no output schema, the description conveys enough to call it correctly: it is temporary, not code, and toggles bounding-box visuals. The only minor gap is not clarifying the clear/enabled interaction, which the schema already handles.

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%, so all eight parameters (name, uuid, clear, color, limit, enabled, recursive, onlyVisible) are already documented in the schema, including defaults. The description contributes no additional parameter meaning, so the baseline 3 applies.

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 states a specific verb+resource ("Show/hide bounding boxes") and adds a concrete purpose ("debug frustum culling and object bounds"), which separates it from siblings like toggle_wireframe or highlight_object. However, it never names those siblings explicitly, so differentiation relies on the reader inferring scope.

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?

It gives an implied usage context ("debug frustum culling and object bounds") and frames itself as a debug aid, which hints when to reach for it. There is no explicit when-not, no prerequisites, and no alternative tool named among the many overlay/highlight siblings.

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