generate_video

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

No annotations are supplied, so the description carries the full burden, and it does disclose the most consequential behavior: video consumes credits and a cost ceiling gates execution with a pre-generation refusal. It omits other traits an agent would want for a video job — expected latency/async behavior, what the response returns, and error handling after the quote passes.

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?

Three short sentences, front-loaded with the purpose, then the credit risk, then the input shape — no filler. Capitalized emphasis on COSTS CREDITS and FLOW_MAX_COST is the only styling and it correctly flags the blocking information.

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 annotations and no output schema, the description does the heavy lifting on the one risk that matters (credit spend and the refusal gate) and states the input modality and format choice. For a paid long-running generation tool, a note on where the result lands or that the call may be slow is the remaining 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 description coverage is 100%, so the schema already documents all five parameters including the aspect enum, and the description only restates 'pick an aspect (16:9 or 9:16)'. It adds no meaning for out_dir, basename, or out_file, notably not how the extension in out_file interacts with format selection.

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?

Sentence one gives a specific verb (generate) plus resource (video) plus destination behavior (save to disk) and names the provider (Google Flow/Veo). Sentence three further narrows scope to text-to-video with an aspect choice, and the 'UNLIKE images' clause separates it from the sibling generate_image without the agent needing to open another 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?

It states a concrete precondition for invocation: the tool only runs when FLOW_MAX_COST is raised above the quoted cost, and otherwise refuses before generating — that is real when-to-use/when-it-will-fail guidance. It also implicitly routes image work elsewhere, though it never names generate_image or explains when a still image is preferable.

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