obsbot_tail2_track_speed

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

No annotations are provided, so the description carries the full behavioral burden. It adds useful provenance ('verified by readback on hardware') and a cross-model caveat, but says nothing about whether tracking must already be enabled, whether the setting persists across sessions, or what happens with 'customized' — meaningful gaps for a mutation tool with zero annotation coverage.

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?

Single sentence, front-loaded with the verb and the enum, with the differentiator placed where it is read first. The 'verified by readback ... 2026-09-26' clause is provenance rather than instruction and is slightly expendable, but overall there is little waste.

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 mutation tool with no annotations and no output schema, the description covers the core enum well but omits the 'camera' parameter, preconditions, and the effect of the setting. It is adequate but leaves real gaps an agent would have to probe elsewhere.

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 enumerates and gives semantic flavor to the 'speed' values (superLazy through crazy) beyond the bare schema enum, but the second parameter, 'camera', is never mentioned anywhere, and 'customized' is left unexplained.

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 specific verb and resource ('Set a Tail 2's tracking follow speed') and pins the exact enum it accepts. It also distinguishes itself from a near-miss sibling family by noting this is Tail 2's six-value enum, not the Tiny 2's standard/sport pair, so an agent can separate it from obsbot_tail2_gimbal_speed and obsbot_ai_track_speed.

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?

Usage is implied by the device/model scoping (Tail 2 only, and explicitly not Tiny 2), but there is no explicit when-to-use statement, no prerequisite (e.g. AI tracking must be active), and no routing to an alternative tool. It gives enough to infer context but leaves selection partly to the agent.

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