Skip to main content
Glama

generate_video

Launches asynchronous text-to-video jobs from a prompt, persists progress, and optionally generates audio while enforcing paid-generation and cost limits.

Instructions

Inicia text-to-video de forma assíncrona e persiste o job. generate_audio é opcional: omitido deixa o fornecedor decidir; HeyGen Video 1 exige áudio. Geração exige allow_paid=true.

Input Schema

NameRequiredDescriptionDefault
modelNo
promptYes
dry_runNo
durationNo
filenameNo
allow_paidNo
output_dirNo
resolutionNo
aspect_ratioNo
max_cost_usdNo
generate_audioNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

B3.1/5.0
Behavior3/5

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

With no annotations, the description carries the full burden, and it does disclose three meaningful traits: the operation is asynchronous, a job record is persisted, and paid generation requires allow_paid=true. It still omits cost implications (max_cost_usd exists but is unexplained), what a failed/queued job looks like, and how the job is later retrieved via get_video_status.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three compact sentences with the core operation front-loaded and no filler. Dense, though the model-specific constraint is packed into a sentence alongside the audio semantics, slightly blurring the focus.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For an 11-parameter, no-output-schema, no-annotation mutation tool, the description leaves most of the surface unexplained. An agent cannot infer valid values for resolution, aspect_ratio, duration, model, or the cost guard from either the schema or the description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% across 11 parameters, so the description must compensate and largely fails. It explains only generate_audio, allow_paid, and a model-specific constraint (HeyGen Video 1), leaving prompt, duration, resolution, aspect_ratio, max_cost_usd, dry_run, filename, and output_dir entirely undocumented.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Inicia text-to-video') plus the async persistence behavior, so the agent knows exactly what is produced. It does not distinguish itself from siblings like animate_image (which also produces video) or generate_image, so it stops short of a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives real conditional guidance: generate_audio is optional and omission delegates to the provider, and allow_paid=true is a hard prerequisite for generation. However, it never says when to choose this over animate_image or generate_variations, nor when dry_run should be preferred.

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