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

The description discloses that the operation is sparse measurement, not continuous playback, returns a cached temporal profile, and remains available later. Annotations already mark readOnlyHint=true, and the description adds context about what is returned (frames, project identity, temporal profile) without contradicting annotations. It does not mention potential errors or limits, but overall it is transparent.

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 long and uses heavy capitalization for emphasis, which can be noisy. It front-loads key info about project scoping and the core action, but many sentences could be trimmed without losing meaning. It is organized but not concise, earning a mid score.

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?

Given the tool's complexity (7 parameters, no output schema), the description covers purpose, usage, and some behavior, but leaves gaps: it does not explain the format of 'one labeled picture' beyond a grid, the structure of the temporal profile, or the meaning of start/end and question parameters. It is incomplete for an agent to call it correctly without further inference.

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 only 29% (only project_id and native_resolution have descriptions). The description explains the 'times' parameter conceptually ('pass times=[...]') but does not clarify start, end, question, or asset_key beyond what the schema gives. It adds some meaning for times but fails to fully compensate for the low schema coverage, leaving several parameters ambiguous.

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 clearly states the tool's purpose: to view frames of an uploaded asset (clip/image or render) for selecting splice points or verifying work. It differentiates itself from look_at by being asset-scoped and mentions the same contract, which helps distinguish it from that sibling. However, the heavy use of emphasized phrases and references to 'same contract as look_at' may slightly reduce clarity for an agent unfamiliar with look_at.

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 provides explicit usage scenarios: choosing a moment to splice and checking renders at exact times. It also implies when not to use (not continuous playback) and references list_assets for obtaining storage_key. It does not explicitly name an alternative tool to use instead, but the context is strong enough for an agent to infer appropriate use.

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