obsbot_tail2_hdr

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

With no annotations, the description carries full behavioral burden, and it usefully discloses the dual read/write mode via the optional parameter. It does not state persistence, whether the change is reversible, permission requirements, or what a read returns, leaving real gaps for a mutation-capable 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?

A single efficient sentence with the read/write distinction front-loaded and no wasted words. Appropriately sized for a simple toggle.

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 two-parameter toggle with no output schema and no annotations, the description covers the set case adequately but leaves the camera parameter and any return information unaddressed, so it is not fully self-sufficient.

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%, so the description must compensate. It clarifies the meaning of "enabled" (set the HDR) but says nothing about the "camera" parameter, which is entirely undocumented in both schema and description.

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?

States a clear verb and resource: read or set the Tail 2's HDR. The resource is easily distinguished from siblings like wb, exposure, and image_adjust. It stops short of explicitly differentiating from the sibling obsbot_image_hdr, but the purpose itself is unambiguous.

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?

"Read (bare call) or set (enabled)" tells the agent which invocation form to use (omit enabled to read, supply it to write), which is genuine usage guidance. However, it offers no guidance on when to choose this tool over related siblings such as obsbot_image_hdr or exposure settings.

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