Skip to main content
Glama

generate video

generate_video
Destructive

Create one independent billable Studio task. All creation tools use input with original model parameters, reference_files and explicit file_bindings. Read list_models.defaults for the default model of this tool, then get_model_schema for the complete schema. generate_task requires model; shortcuts may omit it. Explicit model selects that public task model. Set the documented mode in input; no mode, model fields, defaults or voice choices are inferred or injected. Flat model parameters and legacy reference_images/reference_audio are not accepted. Backend validation is authoritative. Use session_title for a new topic, session_id to continue, and session_id plus base_run_id for a version. Preserve returned model/task_id/session_id/run_id/media_type. Never automatically resubmit or change model/session after rejection or an unconfirmed submission. In user-facing replies, omit technical identifiers by default, including user/profile IDs, task_id, session_id, run_id, base_run_id, voice_id, and file IDs. Retain the exact returned identifiers for tool arguments, task queries, session continuation, version appends, and voice reuse; never redact, regenerate, or guess these references. Show an identifier only when the user explicitly asks for it or a specific troubleshooting step requires that exact value, and show only the reference needed. Prefer plain-language status, model names, result previews/download links, and Studio links built from the returned session_id. This changes reply presentation only; tool result fields remain available for the workflow.

Input Schema

NameRequiredDescriptionDefault
inputYesFollow the complete get_model_schema.schema for model parameters, including nested objects and arrays. Values pass unchanged to backend validation; no plugin field or mode whitelist. Use direct media URLs or reference_files with explicit file_bindings, without mixing them. Routing, identity and session overrides are not model inputs. Metadata does not prove content or access.
modelNoOmit to use this tool's default from list_models.defaults. Supply a canonical ID or exact slug to select another task model; read its complete schema first.
session_idNoUse a returned or user-provided Studio session ID to add related work to that project. Never guess a session ID.
base_run_idNoTo revise a specific work, pass its returned run_id and the same session_id. Omit to create an independent work in the project.
file_bindingsNoUse paths declared in schema.mcp.attachments. Replace [] with an explicit input array index, e.g. elements[0].image_urls; provide parent objects and their metadata in input. Bind every file once using zero-based file_indices in intended order. Never overwrite direct URLs or guess fields or ordering.
session_titleNoRequired for a new Studio topic: 1-255 characters after trimming. Ignored when session_id is provided.
reference_filesNoChatGPT files in original order. file_id is metadata, never a URL or permission proof. Temporary download URLs are used only in this call. Do not invent MIME, byte size, dimensions or duration.

Output Schema

NameRequiredDescriptionDefault
errorYes
modelYes
stateYes
run_idNo
task_idYes
progressYes
voice_idYes
created_atYes
media_typeYes
session_idNo
completed_atYes
preview_urlsYes
text_outputsNo
download_urlsYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

B3.4/5.0
Behavior4/5

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

Beyond the annotations, the description discloses billable task creation, authoritative backend validation, no automatic inference of mode/model/voice defaults, and a strong rule against resubmitting or changing model/session after rejection. It also explains which identifiers must be preserved. The only gap is that it does not further explain the destructive/billable consequences signaled by destructiveHint=true.

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

Conciseness2/5

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

The description is long and front-loads generic creation-tool language rather than video-specific purpose. It repeats identifier-handling guidance in two places ("Preserve returned..." and "Retain the exact returned identifiers...") and includes substantial user-facing reply-presentation instructions that do not directly help invoke the tool.

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

Completeness4/5

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

For a complex 7-parameter creation tool with an output schema and full schema description coverage, the definition covers the key workflow: model/default lookup, session continuation, versioning, file binding, validation authority, rejection behavior, and identifier retention. It lacks video-specific context and sibling-tool routing, but the workflow mechanics are otherwise well covered.

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

Parameters4/5

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

Schema coverage is already 100%, but the description adds meaningful semantics: model can be omitted to use list_models.defaults, session_title is for new topics and ignored with session_id, base_run_id revises an existing run, file_bindings use declared attachment paths, and flat legacy parameters are rejected. This goes beyond the schema text and clarifies how parameters interact.

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

Purpose3/5

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

The description gives a specific verb and resource ("Create one independent billable Studio task"), but it never states that this tool generates video and does not distinguish it from sibling creation tools such as generate_image, generate_music, or generate_task. An agent can tell it is a creation workflow, but not clearly why it should choose this tool over the other generate_* tools.

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?

It gives explicit guidance for session_title, session_id, and session_id plus base_run_id, and points to list_models and get_model_schema for model/default/schema discovery. However, it does not say when to use generate_video versus generate_image, generate_music, generate_speech, or generate_task, so the core tool-selection guidance is implied rather than stated.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources