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

Adds substantial behavior beyond the annotations: it is free and generates nothing itself, refuses with 409 if a start image is not accepted, must choose the smallest duration covering the slot to avoid off-beat drift, is repeatable, and reports open items and undersized videos left as stills.

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-loaded with purpose, then workflow, then constraints, with every sentence carrying weight. It is dense and mixes German/English labels, which slightly reduces readability, but there is little true redundancy.

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 two-mode, dependency-heavy tool with no output schema, the description fully covers the workflow, the shape of the returned `jobs`, the stated failure mode (409), and the reporting behavior an agent needs to chain calls correctly.

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 baseline is 3, but the description adds genuine semantic value: it explains the plan/einsetzen aktion split in workflow terms and the constraint that the `tool` model must be the smallest duration that still covers the slot. It does not add anything for `resolution`, so it stops short of a 5.

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+resource+scope: turning still-image clips of a sequence into beat-snapped video clips that exactly fill their slots. The beat-length framing and the two-phase aktion model distinguish it cleanly from generic siblings like lab_animate or lab_add_clip.

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 sequencing: run lab_beatgrid and lab_apply_rhythm BEFORE plan, then pass returned jobs to lab_animate_batch (get_cost first, then run), and use aktion einsetzen once videos are done. Names alternatives and prerequisites with no inference left to the agent.

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