Skip to main content
Glama
nikships

Gemini Omni MCP

by nikships
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

generate_video

Create or edit MP4 videos from text, images, or existing clips with Gemini Omni Flash, including extend and reference-based generation.

Instructions

Generate or edit MP4 videos with Gemini Omni Flash (gemini-omni-1.1-flash).

Capabilities:

  • text_to_video: prompt-only video with generated audio.

  • image_to_video: one reference image plus motion and camera direction.

  • reference_to_video: multiple reference images for subjects, style, or props.

  • edit: use previous_interaction_id or input_video_path to edit existing video.

  • extend: continue a video from previous_interaction_id or an uploaded MP4, appending a 3-10 second seamless continuation (repeat up to 40s total).

Parameters:

  • prompt: Describe the scene, motion, camera movement, lighting, mood, and audio.

  • task: text_to_video, image_to_video, reference_to_video, edit, or extend. If omitted, inferred. Prefer omitting it for edit and extend: the API rejects an explicit task together with previous_interaction_id, so multi-turn edit/extend are prompt-based (e.g. "Extend this video").

  • aspect_ratio: 16:9 landscape or 9:16 portrait.

  • resolution: 360p, 720p (default), 1080p, or 4k. Values above 720p are upscaled.

  • reference_image_paths: Up to 6 local images. Use , , or tags in the prompt for control.

  • input_video_path: Local MP4 (10s or less) to upload and edit or extend through the Files API.

  • delivery: uri is recommended for generated MP4 files; inline is supported for smaller payloads.

  • previous_interaction_id: Continue editing or extending a prior generated video.

  • enhance_prompt: Optional, default false. For edits, simple prompts usually work better.

Prompt tips:

  • By default Omni generates a few different shots with cuts, crafting a narrative from the prompt. Ask for "single continuous shot, no scene cuts" when you want one unbroken scene.

  • Stage your own cuts with timing language: "Every 2s cut to a new frame", rapid-fire sequences, or timecode lines like [0-3s], [3-6s], [6-10s].

  • Include explicit audio direction such as "gentle ambient room tone, no dialogue".

  • For edits, keep prompts simple and say "Keep everything else the same".

  • When extending, 0s in timecodes refers to the start of the extended part, and you can cut to a new scene with the same characters ("Show the same characters in the next scene").

  • For first/last-frame interpolation, pass two images and use tags.

Limitations:

  • Output is MP4, 3-10s clips at 24fps (360p/720p/1080p/4k), SynthID-watermarked.

  • System instructions, temperature, top_p, stop sequences, negative_prompt, voice edits, YouTube sources, and multi-video reasoning are unsupported.

  • Uploaded-video editing and extension are unavailable in some regions.

Returns JSON including video.path, interaction_id, task, aspect_ratio, resolution, delivery, size, and URI metadata. After success, open video.path with the native OS video viewer.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
taskNo
promptYes
deliveryNo
resolutionNo
aspect_ratioNo
enhance_promptNo
input_video_pathNo
reference_image_pathsNo
previous_interaction_idNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv2.0.3
    • removedInput schema / properties / duration_seconds
      Removed value: -{
-  "anyOf": [
-    {
-      "type": "integer"
-    },
-    {
-      "type": "null"
-    }
-  ],
-  "default": null
-}
    • addedInput schema / properties / resolution
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null
+}
  2. First observedv1.0.2

TDQS

A4.5/5.0
Behavior5/5

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

With no annotations, the description carries the full behavioral burden and does so: it discloses that outputs are MP4 3-10s at 24fps, SynthID-watermarked, that resolutions above 720p are upscaled, that unsupported parameters (temperature, top_p, negative_prompt, voice edits, YouTube sources) will not work, and that uploaded-video editing is region-restricted. It also explains the task-omission interaction with previous_interaction_id, which is a non-obvious API constraint an agent would otherwise hit as an error.

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?

Well organized under Capabilities, Parameters, Prompt tips, Limitations, and Returns headings, with the purpose front-loaded in sentence one. It is long, and the Prompt tips section is arguably beyond the minimum needed to invoke the tool, but for a generative tool with many modes that guidance is largely load-bearing rather than filler.

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?

Given 9 parameters, zero schema descriptions, no annotations, and a rich output schema, the description is complete: it covers all inputs, the behavioral constraints, and the failure modes, and it defers return-value detail to the output schema while still noting the key fields (video.path, interaction_id). Nothing an agent needs to call this correctly is missing.

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

Parameters5/5

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

Schema description coverage is 0% across 9 parameters, so the description must compensate entirely, and it does: every parameter is explained with meaning, defaults, and accepted values (task modes, 16:9/9:16, 360p/720p/1080p/4k, up to 6 reference images, delivery uri vs inline, enhance_prompt default false). It even supplies prompt-syntax guidance (<FIRST_FRAME>, <LAST_FRAME>, <IMAGE_REF_N> tags) that the bare string-typed schema cannot express.

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?

The opening sentence names a specific verb pair (generate or edit), the resource (MP4 videos), and the exact backing model (gemini-omni-1.1-flash), then enumerates the five distinct modes. This is unambiguous about what the tool does. It loses the top mark only because it never differentiates itself from the sibling tool batch_generate.

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

Usage Guidelines4/5

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

It gives clear per-mode selection guidance (text_to_video vs image_to_video vs reference_to_video vs edit vs extend) and an explicit when-not rule: omit task for edit/extend because the API rejects an explicit task alongside previous_interaction_id. That is strong intra-tool routing, but no alternative tool is ever named, so the cross-tool decision (this vs batch_generate) is left to inference.

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

Deploy Server

Other Tools