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

Goes well past the annotations: discloses that nothing is generated or charged, that a paid tool lacking a preflight or an undeterminable price rejects the entire quote by name, that nothing is ever estimated, and that angebot_id is valid 24h and bound to this exact workflow/inputs/project. readOnlyHint=false is consistent with creating a persisted quote record, so there is no contradiction.

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 the usage trigger and the core promise, and almost every sentence carries substantive constraints. The final sentence about `preis_folgt` is a long run-on that buries the operator instruction, costing some readability.

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 fully covers the return contract: angebot_id, the total, one line per node, the balance and remaining cap allowance. It also covers the tricky partial case (`preis_folgt: true`, excluded from the total) and what to tell the user, so an agent can call it and report results without further sources.

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%, yet the description adds real meaning for the nested `workflow` object: schema v1 semantics, `lab.tool` nodes calling FilmLab tools by name, `{{node_id.field}}` data passing, supported `parallel`/`condition`, and unsupported `foreach`/`workflow.invoke`. That is exactly the information needed to build a valid workflow argument, which the schema does not convey.

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 precise verb+resource: price/quote a whole Flow (Pipeline) before it runs, with an explicit scope (every node, checked against balance and cost cap). It is clearly distinguishable from siblings like lab_flow_starten, lab_flow_fortsetzen and lab_flow_status, and it explicitly declares the negative (nothing generated, nothing charged).

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?

Opens with an explicit trigger ('Use when the person wants a saved flow... priced... BEFORE anything runs'), which cleanly separates it from the execution tools. It also names the hand-off for the deferred-price case (lab_flow_fortsetzen), but never explicitly contrasts with lab_flow_starten as the 'actually run it' alternative.

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