Skip to main content
Glama

agent-media

generate_video

Render a video clip from YOUR prompt on the model YOU choose, in one of three MODES that follow from the fields you pass: TEXT (prompt only), IMAGE-TO-VIDEO (first_frame: an https still that becomes frame one, optionally last_frame to end on; the clip animates the still) or REFERENCE (refs: https images such as a portrait, a character sheet from list_characters or a product photo whose identity/look is kept; video_refs: clips whose motion or framing is followed; audio_refs: a voice or sound to carry; address them in the prompt as @image1, @video1, @audio1). Frames and refs cannot be mixed. Write the shot like a director: who is in frame, where, what happens, camera, and the exact spoken words in quotes if anyone talks. HEBREW: the video models cannot speak Hebrew, so Hebrew words in quotes are never left to them: Gemini speaks the line and OmniHuman 1.5 lip-syncs a front-facing still to it (your first_frame, or a keyframe made from the prompt and refs). 9:16 or 1:1, up to 35 s, no video_refs or audio_refs; priced as the voice + the keyframe + 26 credits per lip-sync second instead of the model's rate (call quote); voiceover sets the voice (sulafat, achird) or the gender. Models: seedance-2.0, seedance-2.5, wan-3.0-prime (default seedance-2.5; call list_models for each model's modes, limits, prices and recent results; or pass model:"auto"). Aspect: 9:16 default, also 16:9, 1:1, 4:3, 3:4, 3:2, 2:3, 21:9, adaptive where the selected model supports it. Quality: 480p, 720p, 1080p, or 4k where the selected model supports it; omit for the selected model's default. The price per second follows the model and quality (seedance-2.5: 60 credits/s at 480p, 125 credits/s at 720p, 225 credits/s at 1080p; call list_models for the full table). Reference clip seconds are billed like output seconds. Call quote first if the user cares about cost. Returns a job id, then call get_run_status until it is done and hand the user the URL.

When the user wants to provide a product photo, portrait, screenshot, or image reference, check tools/list. If open_upload_panel is available, offer it first: call open_upload_panel with {}, show its inline panel or returned browser link, and wait for the user to finish. Then call get_uploads with the returned session_id and use the exact ready image_url in refs, first_frame, last_frame, or the matching skill image field. Do not start a reference-dependent generation until the required images are ready. The panel accepts still PNG, JPEG, and WebP, up to 10 images and 25 MB each. Images expire 24 hours after the panel is created; show the returned expiry, request a new upload if expired, and never make a permanent copy. Uploading uses no generation credits. Do not ask the user for base64, shell commands, or a public hosting service; do not continuously poll while waiting for them. Only call these tool names when discovered. If they are missing from the connected tool catalog, call upload_image with {} to open the same panel; use the returned panel: upload_key with upload_image to retrieve images after the user finishes. If that reports the panel is unavailable, use upload_image only for an already accessible file or URL. Do not build an upload page or request a local folder as a substitute for the existing panel. Never invent access to a chat attachment: if you cannot read it, explain that and offer the panel when available. Browser fallback works without inline UI support; do not promise an inline panel in every client. Inspect the native image previews returned with retrieved uploads before describing them or writing image-specific prompts. Never infer what the image shows from an email domain, account metadata, or filename. Use the original URLs for generation, not preview bytes. If the session ID was lost, call get_uploads with {} to list recent sessions, or upload_image with {"upload_key":"panel:recent"} for cached catalogs; retrieve the matching session before asking for re-upload. Account-wide recent uploads may belong to other conversations, so clarify ambiguous selection. Uploading stores an image; it does not attach it to a generation automatically. If the user already requested a generation with these images, continue that request using the returned URLs; do not stop at "upload complete" or ask again whether to use them. If make_ugc fits the requested outcome, pass a person photo as image or a product photo as product_image, then call quote_ugc before spending. Otherwise compose the direct generators: for generate_image, put the relevant image_url values in refs; for generate_video, use refs for product/person/appearance references, or first_frame for animating a still (last_frame only for an explicitly requested ending frame), and never combine refs with frame fields. Preserve the user's intended image roles and model limits; ask only if the role or selection is unclear. Include the URL in the tool arguments, not only in the prompt. Do not substitute a newly generated image for the uploaded reference. If the request was upload-only, report readiness and wait for a generation request; uploading alone does not authorize spending credits. After submitting, poll get_run_status and return the result.

IMAGES: pass an https URL. If you only have raw bytes or a data: URL, call upload_image FIRST and pass the URL it returns. Never paste base64 into these arguments, the client prints tool arguments in the conversation, so a base64 image becomes a wall of text for the user and is re-sent on every retry.

RETRY SAFETY: set request_id to a fresh UUID for a new generation. Reuse the exact same request_id and inputs only to recover a lost response; that returns the original job without another charge. A deliberately new generation needs a new request_id. Keep the returned job_id and poll get_run_status. Never invent a refund.

Input Schema

NameRequiredDescriptionDefault
refsNoREFERENCE-TO-VIDEO: image references (https URLs): a portrait, a character sheet from list_characters, a product photo. The model keeps that identity/look. Address them in the prompt as @image1, @image2...
seedNoOnly for models whose mode lists seed support (none of the live Seedance modes). Refused elsewhere.
audioNoRender native audio when the model supports an audio toggle (speech from the quoted words, ambience). false = silent clip on models that support silence.
modelNoA live video model id from list_models, or "auto" to let agent-media pick from recent results. Omit for the default. Call list_models for what each model is good for, its modes, limits and price.
aspectNo9:16 (default for text and reference), 16:9, 1:1, 4:3, 3:4, 3:2, 2:3, 21:9, or adaptive (follows the first frame or reference; the default and the only option in image mode on seedance-2.5).
promptYesThe shot, as a director would say it: who (age, look), where (setting, light), what happens, camera (phone framing), and, if anyone speaks, the exact words in quotes. About 2.3 words per second. With references, address them as @image1, @video1, @audio1.
qualityNoOne of 480p, 720p, 1080p, 4k where the selected model supports it. Omit for the model default. Price per second differs; see list_models.
secondsNoClip length in seconds (the model sets the range; seedance 2.0: 4 to 15, seedance 2.5: 4 to 30). Credits = seconds x the per-second rate at the chosen quality.
captionsNoOptional: burn word-timed captions in this style into the finished clip (a second step after the render, the subtitle price added). Leave out for no captions.
voiceoverNoSpeech in a language the video models cannot speak (Hebrew): the line is spoken by Gemini TTS and a front-facing still (first_frame, or a keyframe made from the prompt and refs) is lip-synced to it by OmniHuman 1.5. Hebrew lines in quotes get this automatically. 9:16 or 1:1, up to 35 s; not with video_refs or audio_refs. Priced as the voice + the keyframe (when there is no first_frame) + the lip-sync seconds, not the model's per-second rate.
audio_refsNoReference audio (https wav/mp3): a voice or a sound the clip should carry; @audio1... in the prompt.
last_frameNoOptional with first_frame: the image the clip ends on; the model animates from first to last.
request_idNoUnique request identity (prefer a UUID). Reuse with identical inputs to recover the same job after a lost response; choose a new identity only for an intentionally new generation.
video_refsNoReference clips (https mp4/mov) whose motion, framing or look the model should follow; @video1... in the prompt. Their seconds are billed like output seconds.
first_frameNoIMAGE-TO-VIDEO: an https image that becomes frame one of the clip (a still you want animated, a product shot, a portrait). Cannot be combined with refs, video_refs or audio_refs on Seedance.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Annotations only flag non-read-only, open-world, non-idempotent, non-destructive. The description adds real behavioral context beyond that: credit pricing per second by model/quality, the Hebrew path with its restrictions and alternate pricing, retry safety via request_id reuse without double charge, and the post-submit get_run_status polling loop.

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

Conciseness3/5

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

The core generation contract is front-loaded and well organized with caps-labeled sections, but roughly half the text is an upload-panel and tool-discovery procedure that duplicates open_upload_panel/upload_image/get_uploads guidance and is not needed to invoke this tool. It bloats the definition and dilutes the video-specific instructions.

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

Completeness5/5

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

For a 15-parameter, nested-object tool with no output schema, the description covers modes, per-model limits, pricing, the Hebrew special path, return handling (job id then get_run_status), and retry semantics. An agent can call it correctly and knows what comes back.

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 100%, so parameters are documented; the description nevertheless adds cross-field semantics the schema can't express well, such as mode selection following from which fields are populated and the rule that frames and refs cannot be mixed. The remaining per-enum details (aspect/quality support matrix) are deferred to list_models, which is reasonable but leaves some inference.

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

Purpose5/5

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

States a precise verb+resource (render a video clip) and immediately enumerates the three operational modes derived from which fields are passed, which is exactly the distinction an agent needs. It also names sibling boundaries implicitly (generate_image, make_ugc) by routing image-only or UGC outcomes elsewhere.

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

Usage Guidelines5/5

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

Explicit when-to-use rules: call `quote` first if cost matters, call list_models for per-model modes, use make_ugc when it fits the requested outcome, otherwise compose the direct generators. It also gives when-not rules (never mix refs with frame fields; don't start a reference-dependent generation before images are ready).

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