Gemini Omni MCP
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| OUTPUT_DIR | No | Directory for output videos | ~/gemini_omni_videos |
| GEMINI_API_KEY | Yes | Your Google Gemini API key | |
| MAX_BATCH_SIZE | No | Maximum batch size for batch generation | |
| REQUEST_TIMEOUT | No | Timeout for API requests | |
| DEFAULT_DELIVERY | No | Default delivery method (uri or inline) | |
| FILE_POLL_TIMEOUT | No | Poll timeout for file operations | |
| FILE_POLL_INTERVAL | No | Poll interval for file operations | |
| DEFAULT_ASPECT_RATIO | No | Default aspect ratio for videos | |
| DEFAULT_DURATION_SECONDS | No | Default duration in seconds |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
| logging | {} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| extensions | {
"io.modelcontextprotocol/ui": {}
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| generate_videoA | Generate or edit MP4 videos with Gemini Omni Flash (gemini-omni-1.1-flash). Capabilities:
Parameters:
Prompt tips:
Limitations:
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. |
| batch_generateA | Generate multiple Gemini Omni Flash videos in conservative parallel batches. Use for storyboards, aspect-ratio or resolution comparisons, or reference-guided variations. Batch size defaults to configuration and is capped at 4 because video jobs are long. The JSON response includes per-prompt video.path, interaction_id, metadata, and errors. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| continuous_cinematic_scene | Single-shot cinematic scene prompt for generate_video. |
| image_to_video_motion | Reference-image motion prompt for generate_video. |
| timed_sequence | Timed 10-second sequence prompt. |
| edit_instruction | Simple video-edit prompt for previous_interaction_id workflows. |
| batch_storyboard | Storyboard prompt list for batch_generate. |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 2 tools
generate_video and batch_generate have clearly separable purposes (single vs. parallel-batch generation), so an agent can pick between them. The main ambiguity is internal to generate_video, which bundles five task modes behind one tool name, but that is parameter-level rather than a collision between two tools.
Both names use snake_case and are immediately readable. The only minor deviation is the ordering convention: generate_video is verb_noun while batch_generate is qualifier_verb, but this is a trivial and understandable variation.
Two tools is thin for a video generation server; the entire surface collapses into one overloaded mega-tool plus a batch wrapper. It is defensible because the mega-tool is explicitly scoped, but the count sits in the borderline range flagged by the rubric.
The core lifecycle is covered: text/image/reference-to-video generation, editing, extension, and batching, with interaction_id chaining for multi-turn work. There is no dedicated job-status or retrieval/download tool, which is a minor gap for long-running batch jobs.