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

Adds real context beyond the annotations by disclosing that the call consumes Kreavo credits and where to check pricing and balance — something the destructiveHint/idempotent flags cannot convey. It does not state whether credits are charged on failure, nor that the result is an async job needing status polling, which are the remaining behavioral unknowns.

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 the credit-spend warning ahead of the purpose statement, then compresses params into one clause with no filler. The dense parenthetical citations make it slightly telegraphic but nothing is wasted.

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 six-param generative tool with no output schema, the description covers cost, inputs and the ambiguous enum-like field. The notable omission is that nothing tells the agent this produces a job to be tracked via kreavo_check_video_status, which is required for correct use given sibling tools exist for polling.

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 carry the load; it does list all six params and clarifies that background_source takes 'character|reference', which the schema does not express as an enum. image_url, reference_video_url, resolution and aspect_ratio get no explanation of format or accepted values, so the compensation is partial.

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?

Names a specific verb and resource ('Generate a video with motion from a reference video applied to a character image'), which is clearly distinct from plain kreavo_generate_video or kreavo_generate_product_video. It stops short of naming the sibling it differs from, so the differentiation is inferred rather than stated.

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 useful preconditions by pointing at kreavo_list_models for cost and kreavo_get_credits for balance, which tells the agent to budget before calling. It never says when to prefer this over kreavo_generate_video or kreavo_generate_product_video, so the main selection decision is left implicit.

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