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

Annotations only declare readOnlyHint=false / destructiveHint=false; the description adds substantial context beyond that — synchronous blocking execution, LLM-heavy latency variance, the 504 timeout ceiling, upstream context injection, and a non-obvious discovery trick. It does not say whether module output is persisted to the project or what happens on re-run, which is the main remaining behavioral gap 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?

Four tight sentences, front-loaded with the core action and scope, then execution characteristics, then the fallback, then the discovery trick. No filler, no repetition of the schema.

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 at least states that the tool returns the module output, and it covers sync/timeout/call-shape concerns thoroughly. A brief note on what that output contains (text, structured artifact, or job handle) or whether it mutates project state would close the last gap.

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 adds real value on the 'module' parameter by teaching how to enumerate valid keys (send an invalid one) and clarifies that 'message' is the user turn in the module chat, plus notes project_id provenance. It stops short of anything beyond that.

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: 'Run ONE pipeline module for a project', and immediately qualifies it as synchronous and LLM-heavy with context injected from upstream modules and crew agents. This is clearly distinguishable from sibling tools like lab_run_proposal or lab_generate, which the description implies are different operations.

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 when-to-use/when-not: light modules are fine, but heavy modules exceeding ~55s will 504 and should be run in the FilmLab web app instead. It also gives a discovery path — pass an invalid module name to get the list of valid module keys — which removes any need to guess or ask.

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