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

Annotations declare readOnlyHint=false and destructiveHint=false, so the write/read profile is already given; the description adds real context beyond it: the tool plans and checks but never generates and never charges, returns findings graded hart (fix before anything costs) plus ready runs in stuecke[].lauf, and every run is a low-resolution draft. That said, it does not say what a plan call actually persists (does it book jobs? does it mutate the project?), which is the key behavioural question for a non-read-only tool.

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 purpose is front-loaded and almost every sentence carries operative information, but the whole definition is one dense block of roughly 350 words mixing workflow, pricing policy, splitting rules and a five-case retry playbook. The retry remedies and the aktion variants would be far easier to act on as separated clauses or bullets; as written the agent must parse a wall of prose to find the branch it 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?

For a complex, multi-mode tool with no output schema, the description covers what is returned (findings plus stuecke[].lauf), the pricing mode, the splitting-at-shot-boundaries behaviour with zusammensetzen, and even the failure taxonomy with a single concrete retry per failure mode. Nothing an agent needs in order to call this correctly is 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?

Schema coverage is 91%, so the baseline is 3, but the description compensates for the few thin spots and adds real meaning: original_kamera must be described in physical words so the prompt can forbid it, neighbouring shots must differ in size and cover the clip without gaps, preis: true returns pricing plus an upscale estimate, and zusammensetzen uses lengen_s/video_ids in matching order. This is meaning beyond the field labels, not a restatement of them.

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 (re-shoot one clip from new camera angles) and immediately pins down the scope with a positive/negative contrast: same people, words, timing and place, only the camera changes. That framing is distinctive against the many generation siblings (lab_generate, lab_animate, lab_reference_motion) and an agent can identify it 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?

Gives an explicit prerequisite chain (lab_bilder at exact seconds, lab_wortzeiten for lines, one question to the person), names the alternative for scale (lab_auto_lauf with a cap when there are more than a handful of runs), and states when to hand off to lab_reference_motion and lab_upscale. It also specifies an exclusion by implication — upscale only what the person likes, retry only once.

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