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

Annotations already establish readOnly/idempotent/non-destructive, so safety is covered; the description adds genuinely new behavioral context by describing the payload shape (including a preview video) and stating that Kelpo recognises the move's `value` without English translation. It does not cover catalog size, pagination, or what happens when no move matches, which keeps it below a 5.

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?

Front-loads what the tool returns, then the propose/don't-propose rule, then the consumption instructions — a sensible ordering with no filler. It is somewhat run-on and compressed into a couple of long sentences, but every clause carries information the agent needs.

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 correctly compensates by naming the returned fields, and it closes the loop by specifying how the returned value/id is consumed downstream. Minor gaps remain (no catalog size, no behaviour when a requested movement is absent), but an agent can call and use this correctly from the description alone.

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?

Reported schema coverage is 0% (the nested `query` object itself carries no description), so the description has to compensate — it does so with a concrete example payload showing both client_id and lang, plus the note that lang controls names/descriptions in the account language. It stops short of explaining the empty/default behaviour for lang, which the schema covers but the description does not reinforce.

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 (Kelpo's camera movements catalog) and enumerates the returned fields: id, name, description in account language, and a short preview video. The parenthetical examples (selfie, slow orbit, push-in, follow) make it immediately distinguishable from the sibling catalogs (actor, outfit, operations).

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?

Gives an explicit conditional: propose one only when the person wants a particular movement, otherwise the agent picks itself. It then names the two concrete downstream paths with exact arguments — set_camera {"mode": "custom", "description": <value>} and kelpo_expert_prepare {"mode": "move", "move_id": <id>} — so the agent knows both when to consult this and what to do with the result.

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