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

Goes well beyond the thin annotations: discloses that the tool is free and generates nothing, that it refuses with 409 if a start image is not yet accepted, that it is repeatable, and that it reports what remains open plus any video shorter than its slot (left as a still). What it does not state is what exactly happens to the original image clip on einsetzen beyond 'replaces' — e.g. whether that replacement is recoverable — which is the one behavioral detail an agent would still want.

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 core purpose in one sentence and then organizes the two modes with explicit 'aktion plan'/'aktion einsetzen' markers, so it is scannable despite its density. Some phrasing is clunky — mixed German jargon and a few run-on clauses in the plan paragraph — but almost every sentence carries operational information rather than filler.

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?

No output schema exists, and the description compensates by telling the agent that `jobs` is the return value from plan, that it must be passed unchanged to lab_animate_batch, and that einsetzen reports open items and undersized videos. The workflow is complete end to end; only the exact shape of the plan/report payload is left implicit.

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 coverage is 100%, so the baseline is 3; the description earns above that by giving each aktion mode real semantics ('build the animate jobs' vs 'put finished videos into the timeline') and by explaining the tool/model parameters' defaults and their 1-second grid implication. The critical constraint on duration ('the SMALLEST duration the model can deliver that still covers the clip's timeline duration') is stated, though the resolution tier is left entirely to the schema.

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?

Opens with a specific verb and resource: 'Turn the still-image clips of a sequence into video clips that exactly fill their beat-snapped slots', then clarifies it generates nothing itself. The two modes (plan builds jobs, einsetzen installs finished videos) are each stated in a single clause, and the tool is clearly separable from lab_animate_batch, lab_beatgrid and lab_apply_rhythm in the sibling list.

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?

Explicit ordering: run lab_beatgrid and lab_apply_rhythm BEFORE plan; pass the returned jobs unchanged to lab_animate_batch after get_cost; then switch to aktion=einsetzen once videos exist. It also states the repeatability and the 409 refusal case, so the agent knows when the tool cannot be used at all.

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