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

Beyond the readOnly/idempotent annotations, it discloses that the result arrives as a native image the agent must interpret, and crucially that 'Kelpo does not judge the pictures of a take for you' — a behavioral fact an agent could not infer from annotations or schema. It also flags the downstream approval gate before a retake.

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 core idea (contact sheet image) is front-loaded and most sentences earn their place by covering use and next steps. It is dense, and the `times` remark adds a small amount of unexplained detail rather than trimming.

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?

With no output schema, the description carries the return-value burden well by stating the result is a native image, plus it covers the judgment expectation and the retake follow-up path. Nothing essential for correct invocation appears to be missing.

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 description explains that `frames` produces still frames laid out in time order (left to right, top to bottom) and the argument example shows `path` as the job id, adding meaning beyond the sparse schema. The stray reference to a `times` key that is not present in the input schema slightly muddies the picture.

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 concrete verb and resource — a contact sheet of a finished video or shot take delivered as ONE image — and its scope (frames in time order) separates it from whole-video siblings like kelpo_video_download. An agent can identify what it gets back without opening the schema.

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 clearly states the intended use (look at the image yourself and judge the take, then tell the user plainly) and routes the redo path explicitly to kelpo_retake_shoot followed by kelpo_answer_offer after the user's explicit yes on price. It does not, however, contrast itself against nearby read tools such as kelpo_get_shoot.

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