Read the video path

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

The annotations already declare readOnlyHint=true, so the read-only nature is covered. The description adds value by disclosing the unit conventions (cm, degrees, m/s) and the structure of what's returned. No contradiction with annotations, but the behavioral detail is thin — it doesn't say whether the path is current or default, or how rows are ordered.

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 compact at two short clauses, but the dense format notation '{fps,speed,secs,rows [i,x,y,z,yaw,pitch,fov]}' is telegraphic and hard to parse at a glance. It's efficient but at the cost of clarity — a tradeoff that lands mid-range.

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?

An output schema exists, which covers return-value structure. The description covers units and fields but is cryptic about semantics like whether fps is a range or a fixed value, what 'secs' bounds are, or how many rows are typical. For a simple read tool it's adequate but not complete — an agent would need to consult the output schema and guess at the format meaning.

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 tool has 0 parameters, so the baseline is 4 per the rubric. The description's format explanation (fps, speed, secs, rows with per-row i,x,y,z,yaw,pitch,fov) meaningfully describes what the output will contain, which compensates for the absence of a parameter list.

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 title 'Read the video path' states a clear read verb and resource, but the description itself is cryptic — it describes the data format ({fps,speed,secs,rows...}) rather than the tool's action. It implies reading the video camera path but never explicitly says 'reads' or 'returns the current path'. The format detail helps but the primary purpose is only implied.

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 points to edit_video as the sibling for modification and rendering ('Change it and render it with edit_video'), which provides useful routing. However, it doesn't differentiate from cameras or edit_cameras, which are also siblings that could overlap in domain. Guidance is partial.

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