Generate a video with your own account

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

With no annotations, the description carries the full burden and does disclose the key behavior: both providers spend credits, the cap is a hard cap, and if the real cost exceeds it nothing is generated. It omits what happens to partially spent credits, whether existing files are clobbered by overwrite, and any auth requirements.

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 tight sentences, each doing distinct work: provider selection, the credit-cap procedure, and the confirm_spend exception. The most consequential rule (call video_quote first) is front-loaded rather than buried.

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 10-parameter spend tool with no annotations and no output schema, the description covers the money-safety story well but leaves the file story — output_path and overwrite — unaddressed. An agent could call it correctly but might silently overwrite an existing video.

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 only 30% across 10 parameters, and the description compensates for provider, max_credits, and confirm_spend, while the schema itself documents model and duration. Overwrite, output_path, aspect, and quality are explained in neither place, leaving the destructive overwrite and the output destination ambiguous.

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?

The description states a clear verb and resource — it generates video, and spells out the two provider backends (flow vs. higgsfield) with their model families. It doesn't distinguish itself from the sibling video_edit, but it does route to video_quote as a prerequisite, so an agent can place it in the workflow.

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 gives an explicit sequencing rule: call video_quote first, tell the user the cost, then pass max_credits. It also restricts confirm_spend to cases where the user has already agreed in chat, which is a real when/when-not condition. It stops short of saying when to prefer this over video_edit or image_generate.

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