图像视频生成与编辑MCP服务

Gemini Media MCP

Plan, generate, compose, and edit images and video with Gemini image models, Veo 3.1, and Gemini Omni, with a cost estimate before every call and an optional Gemini 4 Argon director that checks each take against your notes.

What it does

• Plan: plan_generation ranks tool and model options for an intent with costs, and generates nothing.
• Generate: images with Gemini, video with Veo 3.1, fast video with Omni.
• Compose: storyboards, multi-beat reels, transitions between stills, bridges between clips.
• Edit and extend: conversational video edits, seamless scene extension, loop and extend.
• Direct: optional director_notes have Gemini 4 Argon turn your notes into checks, review each take, and retake on a clear fail.
• Cost-aware: any call runs dry_run for a quote; real runs report metered cost and its pricing source.

Quick start

uvx gemini-media-mcp setup

The setup wizard walks you through the whole onboarding flow end-to-end:

1. Pick a credential mode: Gemini API (images + Omni video, easier to set up) or Vertex AI (images + Veo and Omni video, adds GCS output and Vertex-only features).
2. Enter your API key, or your Google Cloud project plus a service account JSON (file path or inline paste).
3. Choose where generated media should be written (defaults to ~/gemini-media).
4. Optionally set a VIDEO_GCS_BUCKET for large video output, and auto-populate GCS_ALLOWED_BUCKETS.
5. Validate your credentials with a live check (constructs a Google GenAI client and lists models to confirm the key/credentials actually authenticate). Validation failures are non-fatal — you can continue anyway.
6. Print a ready-to-paste Claude Desktop JSON block. On macOS, the wizard can also merge the block directly into ~/Library/Application Support/Claude/claude_desktop_config.json (existing servers are preserved and the prior file is backed up to .bak).

For scripted use, all prompts can be supplied via flags:

uvx gemini-media-mcp setup --non-interactive --mode=gemini --api-key=AIzaSy...

If you prefer to configure everything by hand, the manual steps are below.

Setup

Prerequisites

• For images and video with the simplest setup: a Gemini API key (setup instructions). Video on the Gemini API runs on Gemini Omni (generate_video_omni); Google switched off Veo 3.1 there on October 22, 2026, and the Veo tools refuse on that backend and name the alternatives.
• For images and video with Veo, GCS output and Vertex-only features (e.g. controllable audio: include_audio maps to Veo's generate_audio config): a Google Cloud project with the Vertex AI API enabled and a service account with Vertex AI permissions (setup instructions)

Environment Variables

For Vertex AI (images + video, GCS output, Vertex-only features):

export GOOGLE_GENAI_USE_VERTEXAI=true
export GOOGLE_CLOUD_PROJECT=your-project-id
export GOOGLE_CLOUD_LOCATION=us-central1
export GOOGLE_APPLICATION_CREDENTIALS=/path/to/service-account.json

→ See Vertex AI Setup for detailed instructions

Alternatively, for the Gemini API (images, plus video through Gemini Omni; Veo needs Vertex AI):

export GEMINI_API_KEY=your-api-key

→ See Gemini API Setup for detailed instructions

Optional security hardening:

# Restrict gs:// fetches and output_gcs_uri to specific buckets.
# If unset and VIDEO_GCS_BUCKET is not set, gs:// fetches log a warning.
export GCS_ALLOWED_BUCKETS=bucket-a,bucket-b

Other variables the server reads:

CLI flags

gemini-media-mcp [--log-level LEVEL] [--host HOST] [--port PORT] [--mount-path PATH] [stdio|sse|streamable-http]

• --log-level: DEBUG, INFO (default), WARNING, ERROR, CRITICAL
• --host / --port: bind address and port for sse / streamable-http (default port 8000)
• --mount-path: mount path for the sse transport (e.g. /custom). streamable-http ignores it and always serves /mcp.

--host, --port and --mount-path are also accepted after the transport subcommand, which is the only form a docker run entrypoint can produce. --log-level must come before it.

Local file:// and bare-path inputs are always restricted to DATA_FOLDER. HTTP(S) fetches reject hosts that resolve to private, loopback, link-local, or metadata IPs, and downloads are capped at 50 MB.

Claude Desktop Configuration

Add to your Claude Desktop config (~/Library/Application Support/Claude/claude_desktop_config.json on macOS):

{
  "mcpServers": {
    "gemini-media": {
      "command": "uvx",
      "args": ["gemini-media-mcp"],
      "env": {
        "GOOGLE_GENAI_USE_VERTEXAI": "true",
        "GOOGLE_CLOUD_PROJECT": "your-project-id",
        "GOOGLE_CLOUD_LOCATION": "us-central1",
        "GOOGLE_APPLICATION_CREDENTIALS": "/path/to/service-account.json"
      }
    }
  }
}

Or using Docker (note: DATA_FOLDER must be set to the host path, with matching volume mount):

{
  "mcpServers": {
    "gemini-media": {
      "command": "docker",
      "args": [
        "run", "--rm", "-i",
        "-e", "GOOGLE_GENAI_USE_VERTEXAI=true",
        "-e", "GOOGLE_CLOUD_PROJECT=your-project-id",
        "-e", "GOOGLE_CLOUD_LOCATION=us-central1",
        "-e", "GOOGLE_APPLICATION_CREDENTIALS=/credentials.json",
        "-e", "DATA_FOLDER=/Users/yourusername/gemini-output",
        "-v", "/path/to/service-account.json:/credentials.json:ro",
        "-v", "/Users/yourusername/gemini-output:/Users/yourusername/gemini-output",
        "cxoagi/gemini-media-mcp"
      ]
    }
  }
}

This writes files to your host path and returns paths like /Users/yourusername/gemini-output/images/abc.png that Claude Desktop can open directly. The DATA_FOLDER directory will contain images/ and videos/ subdirectories.

Available Tools

Every generation tool supports dry_run: true — it returns the cost estimate for the exact call that would run (rerouted model, snapped duration, bridges counted) and generates nothing. Real runs report the metered cost in the response and the sidecar manifest. generate_clip is the one to always price first: 3 beats at 8s is $2.40 on the fast tier and $9.60 on standard.

Virtual director

generate_image, generate_video and generate_video_omni take optional director_notes: what the shot must get right, in plain words. Without them nothing changes: no extra call and no extra cost.

With notes, the tool:

1. Turns the notes into checks with Gemini 4 Argon. Each check quotes the words of the notes it came from, and a check that quotes nothing in the notes is dropped as invented. Notes that cannot be checked by looking, such as file format or delivery, are listed under skipped_notes.
2. Renders the take exactly as it would without notes, then has Argon review it against every check. The reviewer is also shown the images the render was given: always the image being edited and the first and last frames, and the first three of image_uris and of reference_image_uris. Each is named for what it is, and lists are numbered in your order, so in the notes "reference 1" is reference_image_uris[0] (on omni, <IMAGE_REF_0> works too) and "input image 1" is image_uris[0]. Each take lists what the reviewer was shown under references_shown; anything it was not shown is named in a warning, and a check that needs it comes back unsure. Each check comes back pass, fail, unsure or not_applicable, with where in the image or when in the clip the problem is. Clips are sampled at 4 frames a second. A fail that does not say where counts as unsure.
3. When a check fails and max_retakes allows (0 to 2, default 1), renders again with your prompt, unchanged, plus a "Director's notes for this take" list made from the failed checks' fix instructions, and reviews that take. The notes say they win wherever they conflict with your prompt. A check that particular text appears (a headline, a label) is a text check carrying the literal the notes asked for and, where the notes say it, a target such as "the smaller line under the headline". Its fix note is always <Target> must read exactly: "<literal>", written by the server, because a model-written fix puts how to compare the text ("with no trailing period") after it and the next render prints that too; a target that is long, quotes anything, names the text itself or uses a comparison word falls back to "The text". How the text is compared stays in the check, which only the reviewer reads. A text check is not judged by the reviewer but transcribed by it: the reviewer copies out the text it sees, and the server compares that with the literal character for character, with runs of whitespace collapsed and curly quotes straightened; no transcription is unsure. Image models tend to add a trailing period to a short line, so write the literal the way the copy is actually set rather than against the model's habit.

It returns the first take that passes, or else the take with the fewest fails (on a clip, then the least time showing them), and says which. A retake can fix one check and break another, so it is never assumed to be better: every take is reviewed, and the take returned can be an earlier one. The top-level prompt is always the one you sent; when the returned take is a retake, effective_prompt is the text that rendered it. The response's director block lists the checks, every take with its prompt, media, verdict, per-check results and costs, chosen_take, and retakes_used. A retake that never rendered is listed too, with verdict not_rendered, its error and its prompt, so the fix notes can be read either way. Each omni take carries its own interaction_id, so a retake that was not returned can still be continued or reconciled. review_attempts counts the review requests; when it is 2, retried_after says why: quota (a 429, which is not billed) or transient (a server error, which may be, and a warning says so). cost covers everything the call billed: every take and every director call. Each take's sidecar manifest records its review under director_review, together with your notes, the checks and the director model, so the manifest can be read without the response.

What holds throughout:

• No confidence number. The reviewer is never asked how sure it is, and none is reported. A model's own certainty is not calibrated; the states have to be compared with human labels before a number means anything.
• A clip is judged second by second. A check that must hold for the whole clip (steam throughout, no hands in frame) is a throughout check: the reviewer answers y, n or ? for each second, and the server decides. Any n is a fail with the exact seconds as evidence; any ?, or a list shorter than the clip, is unsure. A clip is judged in whole seconds, its length rounded to the nearest one (a 6.04 s clip is six seconds; an 8.6 s clip is nine, the last covering 8.0–8.6 s), so a gap shorter than a second fails that whole second.
• The media cannot steer its own retake. Text inside a render is assessed, never followed, and retake notes are built only from the fix instructions derived from your notes plus time ranges, never from what the reviewer wrote about the media.
• The render always lands. A review that hits a 429 or a server error is retried once after a short wait, if its time budget allows. The call that turns notes into checks is also retried once after a timeout (derive_attempts, derive_retried_after); on the video tools only while at least half of timeout_seconds stays free for the render. A render the service turns away with a 429 or a server error is tried again after 10 s and then 30 s, or after the wait the 429 asked for, each time only when the time left fits the wait, a render and a review (render_attempts, render_retried_after, render_retry_waits; a retry that cannot fit says reason: "budget"). A render that was already submitted is never sent again. Image quotas can allow only a few renders a minute and recover over tens of seconds, so a retake is often refused seconds after the take before it. One that still cannot run (quota, timeout, a safety block, a clip over 14 MB inline) is recorded as abstained with a reason, and the take is still returned. An unsure review stops instead of paying for a retake.
• No judgments about people. Checks never assess a person's identity, likeness, age, sex or gender, race or ethnicity, health, emotion, attractiveness or body.

The kinds of thing a review catches: a line set in capitals when the notes asked for title case, a footer the prompt never mentioned, a size annotation printed on a label, hands entering the frame at 00:01–00:04, a clip with no steam for its first second.

On the video tools, timeout_seconds bounds the whole directed call, because MCP hosts cancel long calls and a cancelled call has already billed its renders. Each take renders in the time left; a review that could not finish is skipped (abstained, reason deadline), and a retake is not started when the previous take shows it would not fit. Raise timeout_seconds, and your host's limit, to leave room for retakes.

A dry_run with notes quotes the worst case: every take rendered and reviewed, each review at its output cap, no cache hits. Three charges cannot be priced in advance and are left out: an image render's input tokens (generate_image quotes output only), a director request that fails without reporting its usage, and a render that fails with a server error or a timeout and is tried again, which may bill for the failed attempt; a warning names either of the last two if it happens. A retake that fails is listed with submission saying how far it got: submitted (it may still bill, and its quote is counted where the tool gives one), unknown (it may have reached Google, so cost is a lower bound) or none (nothing billed). Inputs are validated by the tool's own dry run before the first director call is paid for, and checks derived for the same notes, prompt and model earlier in the server's life are reused rather than derived again; checks_source says compiled, cache, or failed when the notes could not be turned into checks, and a cached set adds no derive cost. Director calls use gemini-4-argon ($2 / $10 per 1M input / output tokens through 2026-11-30, then $4 / $20); set DIRECTOR_MODEL=gemini-3.8-flash for about a third of that. On Vertex AI they go to the global endpoint, one of the three locations that serve Argon.

{
  "prompt": "A ceramic mug on a walnut table, morning light",
  "model": "gemini-3.1-flash-image",
  "director_notes": "The label reads GOLDEN HOUR in serif capitals. No people or hands in the shot. The handle faces right.",
  "max_retakes": 1
}

plan_generation

Start here when you are not sure which tool or model to use. Describe what you want in plain language and get back ranked, ready-to-call plans — which tool, which model, which parameters, why that model won, what each option costs, and which models were ruled out and for what reason.

It generates nothing, costs nothing, and is instant: pure rule-based routing over this server's capability tables, not a model call. It never replaces the explicit generate_* tools — it tells you how to drive them.

Parameters:

• intent (required): plain language, e.g. a 3-beat vertical reel about coffee, a poster with the words GRAND OPENING
• Optional overrides (these always beat what's inferred from the text): budget (cheap/balanced/best), media_kind, aspect_ratio, image_size, duration_seconds, num_beats, needs_text_rendering, needs_4k, needs_audio, needs_extension, num_reference_images, wants_gcs_output, is_draft, pinned_model

Returns: ranked routes (tool, model, ready-to-use params, score, rationale, caveats, cost), rejected models with reasons, conflicts, a suggested multi-step workflow, and notes.

It catches requests that cannot work before you pay for the failure — 4K on a 1K-only model, Veo on the Gemini API, GCS output on the Gemini API — and reports each as a conflict with a fix.

Capability beats budget by design. Ask for legible text on a cheap budget and it still recommends gemini-3-pro-image: a cheap image that fails the brief isn't cheap.

generate_storyboard

The missing step between an idea and generate_clip. Renders one keyframe per shot, then composes them into a real, readable storyboard — numbered panels with slug lines, prompts, camera notes and duration badges — instead of a bare list of image URLs.

Two artifacts come back, because MCP clients render inline images but do not execute HTML:

1. A composited contact-sheet PNG — written full-resolution to disk (sheet_url) and returned inline as a downscaled preview. The preview is the thing you look at in chat; open sheet_url when a panel needs a closer read. It is downscaled because the full board runs past a megabyte from about a dozen shots up, and an MCP client drops a result that large outright.
2. A self-contained HTML page written to disk (file:// URL) with full-size frames, complete prompt text and cumulative timecode. Fully offline: images embedded as data URIs, no external requests.

Parameters:

• shots (required): ordered specs — {prompt, caption?, duration_seconds?, notes?}. caption is a slug line, notes are camera/lighting notes. Capped at 24 shots per call, because every shot is a billed image
• title, subtitle: drawn on the board
• model, aspect_ratio, image_size: keyframe generation settings (9:16 gives vertical panels)
• theme: dark (default) or light
• dry_run: price the whole board without generating

A failed shot does not abort the board — it renders as a clearly marked panel showing the actual error, so a partial storyboard stays reviewable, and it isn't billed. The shots list is designed to be fed straight into generate_clip as beats once the board reads well.

generate_image

Generate images using Gemini image models.

Parameters:

• prompt (required): Text description of the image

• model (required — there is no default; name one explicitly): Pick by use case. GA (stable) — preferred in production:

  • gemini-3.1-flash-image (Nano Banana 2) — the general-purpose choice; fast, up to 4K output, up to 14 reference images
  • gemini-3-pro-image (Nano Banana Pro) — 4K, reasoning, thought_signature for multi-turn editing
  • gemini-3.1-flash-lite-image — cheapest, but 1K output only (2K/4K are unsupported)

  Retired IDs are rerouted, not failed. The models below no longer exist (or are about to). Requesting one still returns an image: the server substitutes the replacement Google published rather than letting the call 404. They are accepted only as compatibility aliases — request a GA model directly.

  Retired ID	Gone since	Served by
  gemini-3-pro-image-preview	2026-06-25	gemini-3-pro-image
  gemini-3.1-flash-image-preview	2026-06-25	gemini-3.1-flash-image
  imagen-3.0-generate-002	2025-11-10	gemini-3.1-flash-image
  imagen-3.0-capability-001, imagen-3.0-capability-002, imagen-3.0-fast-generate-001, imagen-3.0-generate-001, imagen-4.0-fast-generate-001, imagen-4.0-generate-001	2026-08-17	gemini-3.1-flash-image
  imagen-4.0-ultra-generate-001	2026-08-17	gemini-3-pro-image
  gemini-2.5-flash-image	2026-10-02 (scheduled)	gemini-3.1-flash-image

  Imagen Ultra is the top Imagen tier, so it reroutes to the top Gemini image model rather than dropping to flash — gemini-3-pro-image is billed at a materially higher rate than gemini-3.1-flash-image. Price the call with dry_run before running it.

  Every substitution is announced on three channels so it cannot go unnoticed: a warnings entry in the response JSON, an MCP warning-level log notification to the client, and a WARNING record in the server log.

  If you hold Provisioned Throughput on a discontinued Imagen model, move that order yourself — Google does not stop it automatically at retirement.

• image_uri: Input image URI for image-to-image generation

• image_base64: Base64 encoded input image

• aspect_ratio: Output aspect ratio (e.g. 1:1, 16:9, 9:16)

• person_generation: Policy for generating people — dont_allow, allow_adult, or allow_all (some regions restrict these values)

• dry_run: Return only the cost estimate and the resolved model/parameters — generates nothing, free and instant

• director_notes, max_retakes: Have the virtual director check the image against your notes and retake on a fail

Every real run reports usage (the token counts the API metered) and cost derived from them, and writes both into the sidecar manifest. A dry run prices the call that would actually be issued: ask for imagen-4.0-generate-001 at 4K and it quotes gemini-3.1-flash-image; ask gemini-3.1-flash-lite-image for 4K and it quotes its 1K default and tells you why.

Gemini 3.x Image Parameters (for gemini-3-pro-image, gemini-3.1-flash-image, gemini-3.1-flash-lite-image):

• reference_image_uris: List of up to 14 reference image URIs for multi-image composition
  • Up to 6 object images for high-fidelity inclusion
  • Up to 5 human images for character consistency across scenes
• image_size: Output resolution (1K, 2K, 4K) - must use uppercase K. gemini-3.1-flash-lite-image supports 1K only; asking it for 2K/4K drops the parameter and returns a warning rather than failing the request.
• media_resolution: Input image processing quality (MEDIA_RESOLUTION_LOW, MEDIA_RESOLUTION_MEDIUM, MEDIA_RESOLUTION_HIGH)
• thought_signature_url: For multi-turn editing workflows — pass back the thought_signature_url from a previous response to continue editing the same image. (The parameter is the file URL; passing a thought_signature key is silently ignored by MCP.)

generate_video

Generate videos using VEO models, which run on Vertex AI only. Vertex AI also provides GCS output and Vertex-only features such as include_audio. Google switched off Veo 3.1 on the Gemini Developer API on October 22, 2026; on a server using a Gemini API key this tool refuses before quoting anything and points to generate_video_omni (gemini-omni-1.1-flash, Google's named replacement) or Vertex AI.

Parameters:

• prompt (required): Text description of the video
• model (required — there is no default; name one explicitly):
  • veo-3.1-generate-001: Highest quality, 4/6/8s duration, audio support
  • veo-3.1-fast-generate-001: Faster generation with audio support
• aspect_ratio: 16:9 (default) or 9:16
• resolution: Output resolution, 720p, 1080p, or 4K
• duration_seconds: Video duration (4/6/8s), default 8.0 — the longest and most expensive option. Omitting it on veo-3.1-generate-001 bills a full 8s render (from $3.20 at 720p/1080p); pass 4 explicitly when a short beat will do.
• include_audio (default false): Enable audio generation
• person_generation: Policy for generating people — allow_adult or allow_all (some regions restrict these values)
• audio_prompt: Audio description
• negative_prompt: Things to avoid in the video
• seed: Random seed for reproducibility
• image_uri: First frame image URI for image-to-video generation
• timeout_seconds (default 210): Overall deadline for the render. Common MCP hosts cap one tool call at roughly four minutes; a render that outlives the host's limit is cancelled by the host — the caller sees a bare "Tool execution failed" with no message, cost or operation name, and the Veo operation completes and bills anyway (a 4K render did exactly this). Under the host ceiling the server answers first: a timeout returns a structured error naming the generation_mode, the attempted_cost, the operation_name to reconcile in the console, and submission: submitted (the render may still complete and bill), unknown (the submit call itself ran out of time, so it may have reached Google) or none (nothing was sent). Raise it if your host allows a longer call; 4K is the slowest tier.
• draft (default false): When true, routes the request to gemini-omni-1.1-flash for a fast 720p draft instead of Veo. Iterate fast, then re-run with draft=false to finalize on Veo. At 720p this buys speed, not savings (omni is $0.10136/s against Veo Fast's $0.10/s) — add draft_resolution="360p" and it buys both. See Fast drafts vs. high-fidelity.
• draft_resolution: Resolution for a draft=true pass. Naming one renders the draft on gemini-omni-1.1-flash, the model that has a resolution parameter; 360p is about a third of the 720p price and the cheapest render this server can issue. Unset keeps the preview model's fixed 720p.
• director_notes, max_retakes: Have the virtual director check the clip against your notes and retake on a fail

Additional Parameters:

• last_frame_uri: Last frame image URI for first+last frame control
  • When combined with image_uri, generates smooth transitions between frames
• reference_image_uris: List of up to 3 reference image URIs for subject preservation
  • Preserves the appearance of a person, character, or product in the output video
  • Note: Only supports 8-second duration (automatically enforced)
  • Cannot be used together with first/last frame inputs
• extend_video_uri: URI of existing VEO-generated video to extend
  • Extends the final second of the video and continues the action
  • Can be chained multiple times for longer videos (up to ~148s total)
  • Note: Cannot be used together with other image inputs

Generation Modes (automatically selected based on inputs):

• text_to_video: Text-only prompt
• image_to_video: First frame image input
• first_last_frame: First and last frame control
• reference_to_video: Reference images for subject preservation (8s only)
• extend_video: Extend existing video

generate_video_omni

Fast conversational video generation through Google's Omni models (Interactions API). This is the fast path — ideal for drafts and rapid iteration — and the only family with multi-turn conversational editing. See Fast drafts vs. high-fidelity.

Two models, selected with omni_model:

Neither is the cheap path at 720p: both bill $0.10136/s, a hair above Veo Fast's $0.10/s. What 1.1 adds is a genuinely cheap draft tier — resolution="360p" is about a third of that, and Google says it renders up to 60% faster.

gemini-omni-1.1-flash is now the default. It was the preview model, on the reasoning that flipping it would move existing callers without asking — but the preview endpoint is switched off on 2026-10-22, so defaulting to it meant defaulting new callers onto a model with weeks to live. Since that date, pinning omni_model="gemini-omni-flash-preview" is refused before any quote or call, naming gemini-omni-1.1-flash instead.

The two backends are on different tracks. 1.1 is generally available on the Gemini Developer API. On Vertex AI / Gemini Enterprise Agent Platform it is still Preview, published as gemini-omni-1.1-flash-preview (translated automatically), and preview video models there are allowlist-gated with near-zero default quota — a 429 naming the base model means an allowlist and quota request to your Google Cloud account team, not a wait. Set GEMINI_API_KEY to use the GA path, which is also the only backend with the Files API the uploaded-source path needs.

Parameters:

• prompt (required): Text description of the video. Timecodes work in plain language ("[0-3s] a person walks"), as does audio direction ("include calm background music"). If you write your own role tags (<FIRST_FRAME>, <IMAGE_REF_0>, [# Sources ...]) they are passed through untouched; otherwise the declarations are generated from the media arguments and echoed back as effective_prompt
• omni_model: gemini-omni-1.1-flash (default) or gemini-omni-flash-preview (switched off 2026-10-22). Arguments the chosen model cannot honor are refused, never dropped — a 4K request on the preview model is an error, not a 720p render billed as 4K. Pass the Gemini-API spelling on either backend: Vertex AI publishes 1.1 as gemini-omni-1.1-flash-preview and the translation is automatic, with the canonical ID reported back and the served one alongside it as served_model
• omni_backend: auto (default; the server's OMNI_BACKEND applies), vertex, or gemini_api. On a Vertex server that also has a GEMINI_API_KEY, auto sends omni to the Gemini Developer API; pass vertex to keep the call in the Vertex project. An unsatisfiable choice is refused, as is one that contradicts the backend a previous_interaction_id was minted on. The response's backend and backend_reason say which backend served the call and why.

Omni on Vertex AI is Preview and may require access to be requested for the project. A call that is refused there says so, and names the Gemini Developer API as the alternative — where the Interactions API is GA.

• image_uris: Image URIs whose role the model infers — one is a starting frame, several are subject references (optional; at most 8 images total — more is rejected, since each is buffered in memory)
• first_frame_uri / last_frame_uri (1.1): Keyframe interpolation. last_frame_uri requires first_frame_uri; the same URI for both makes a seamless loop
• reference_image_uris (1.1): Subject/style references, bound to <IMAGE_REF_0>, <IMAGE_REF_1>, … in order
• reference_video_uris (1.1): Up to 3 clips of up to 3s each, bound to <VIDEO_REF_0>, … for character or object likeness. Audio in a reference clip is ignored
• input_video_uri: A video to edit (optional). On 1.1 a clip too large to inline is uploaded through the Files API automatically (which needs a Gemini API key — Vertex has no Files API)
• resolution (1.1): 360p, 720p (default), 1080p or 4K. 1080p and 4K are upscaled from the base render
• aspect_ratio: 16:9 (default) or 9:16 — not sent when the request is an edit (an input_video_uri or a previous_interaction_id makes it one); the API rejects it on an edit task
• duration_seconds: Video duration, 3–10 (default 6) — likewise not sent on an edit, and the rendered length is then chosen by the service: a measured 3s source edited with duration_seconds=4 came back at 10.01s. On an edit the response reports duration_seconds: null and the quote uses omni's 10s maximum as an upper bound
• previous_interaction_id: Continue editing a prior omni result (optional)
• timeout_seconds: Overall deadline for create + polling (default 600). A render typically takes over a minute; raise it for long queues
• director_notes, max_retakes: Have the virtual director check the clip against your notes and retake on a fail. Each take is a fresh render, not a conversational edit

Notes:

• No seed or negative_prompt on either model — put negatives in the prompt ("no dialogue", "no extra sound effects")
• Large outputs. A render above 720p, or any extension, exceeds the API's 4 MB inline response limit. On the Gemini API those are requested with delivery="uri" and downloaded here automatically (the response says so in a warning); on Vertex AI, pass output_gcs_uri to have the service write straight to a bucket you control
• The response includes an interaction_id for multi-turn editing and extension (pass it to edit_video, extend_video_omni, or back into previous_interaction_id)
• All output carries SynthID watermarking

Pricing note for the new resolutions. Google publishes exactly one Omni output-video rate — 5,792 tokens per second of 720p video at $17.50/1M tokens. So: 720p is quoted from the pricing page; 360p is quoted at the one-third ratio stated in the launch post, which is not a pricing page; and 1080p/4K are quoted at the published 720p rate because no separate rate exists for an upscaled render. Every estimate says which of those it is in its source_note.

edit_video

Conversational edit of a previously omni-generated video. Because omni holds the video context server-side (background interactions are retained ~14 days on Vertex AI; longer on the paid Gemini API), you describe only the change — no need to re-supply the source video.

Simple instructions edit best: "Make this video anime", "Make the phone invisible. Keep everything else the same." Over-describing the scene changes parts you meant to keep.

Parameters:

• previous_interaction_id (required): The interaction_id from a prior generate_video_omni response
• prompt (required): The edit instruction (e.g. "make the sky stormy")
• omni_model: Must be the model that produced previous_interaction_id — the interaction's video context lives with it, so an edit cannot switch models mid-conversation
• resolution: gemini-omni-1.1-flash only; the resolution to render the edit at
• aspect_ratio: accepted but never sent — the API rejects it on an edit task, so it does not change the output
• duration_seconds: accepted but never sent, and it does not set the output length. The service picks the rendered length, and it is predictable from neither this value nor the source video: a measured 3s source edited with duration_seconds=4 rendered 10.01s. The response reports duration_seconds: null; a real run bills the length measured from the rendered file, and dry_run quotes omni's 10s maximum so a pre-flight never under-states
• timeout_seconds: Overall deadline for the edit render (default 600)

extend_video_omni

Append a seamless continuation to an existing video (gemini-omni-1.1-flash only). Extension is neither editing nor a fresh render: the model reads the last 10 seconds of the source as context and generates what happens next, keeping motion, characters and audio coherent across the join. Some of the source's final frames are altered so the transition is invisible.

Two sources, with different rules:

• previous_interaction_id — a clip this server already rendered. The video context lives on the service, nothing is uploaded, and spoken dialogue may be added in the continuation.
• input_video_uri — a clip of your own. It must be 10 seconds or shorter on the Gemini API, 30 on Vertex AI (the two backends document different ceilings; checked locally against the right one before anything is uploaded), it cannot gain new dialogue if someone is talking in it, and uploading a video to be extended is unavailable in the EEA, Switzerland and the UK.

Each turn appends up to 10s, to a cumulative 40s. times chains that many turns, threading each result into the next.

Parameters:

• prompt (required): How the scene continues — "Extend this video", "Continue the scene: the camera pans across the mountains". Describe the audio if it should change, and say so if you want a cut to a new scene. In a timecode, 0s is the start of the new footage, not of the source
• previous_interaction_id or input_video_uri (exactly one required)
• times: How many extension turns to chain (default 1, maximum 4). Turns run on the backend that minted the interaction, so a chain never drifts between Vertex AI and the Gemini API mid-way
• omni_model: An interaction cannot change models mid-conversation, so continuing one created on another model is refused rather than sent as a plain edit and billed as an extension
• resolution, reference_image_uris, reference_video_uris, output_gcs_uri, timeout_seconds, dry_run — as for generate_video_omni. References ride along on the first turn, which is where a new character is introduced

Returns: JSON with the last turn's video_url, the interaction_id to keep extending from, billed_seconds, assembled_seconds, appended_seconds, completed_turns, one segment record per turn, and the summed cost. Each turn's video_url supersedes the previous one — they are not segments to join. If a turn fails part-way through a chain, the turns that already rendered are still returned with their interaction_id, alongside an error telling you where to resume — they were billed.

⚠️ Extension cost grows quadratically

A turn renders the whole assembled clip, not the 10s it appends. Measured: a 3.01s source extended once returned 13.01s. Omni bills per second of output, so every turn re-bills all the footage before it:

times	billed	new footage	cost @360p	cost @720p
1	13s	10s	$0.44	$1.32
2	36s	20s	$1.22	$3.65
3	69s	30s	$2.33	$6.99

Two documented sources pointed the other way — the API reference calls duration "the length of the generated video files" with a 3–10s range, and Vertex's sample response bills 28,832 video tokens (4.98s) — and neither survived a real render. Always dry_run a chain before running it.

A dry_run needs the source's length to be right, and gets it from the sidecar of a prior interaction or by measuring an uploaded clip. When it has neither it assumes the documented maximum, because assuming a shorter source is the one direction a quote may not err in. It reports turn_output_seconds, billed_seconds, assembled_seconds and planned_turns separately, since those are four different numbers.

loop_extend

Convenience wrapper that extends a Veo-generated video multiple times in one call. Each Veo extension adds ~7s, and can be chained up to 20 times. This is the Veo extension path; extend_video_omni is the Omni one, and they are not interchangeable.

Parameters:

• video_uri (required): The Veo-generated video to extend
• prompt: What the video continues with (default: "continue the action")
• times: Number of ~7s extensions to apply, 1-20 (default: 1)
• model: Veo model to use (default veo-3.1-generate-001)
• aspect_ratio: 16:9 (default) or 9:16 — must match the source video
• include_audio: Generate audio on the extended sections (default true)
• output_gcs_uri: GCS URI for output (required, or set VIDEO_GCS_BUCKET)

Notes:

• Veo 3.1 / Veo 3.1 Fast, on Vertex AI
• 720p

generate_clip

Generate a multi-beat short clip — the building block for a reel or short. Each beat is rendered in order, and the tool returns an ordered manifest a cutting MCP (e.g. vfx-mcp) can splice into a finished clip.

This is the highest-leverage tool in the server: one call produces a whole sequence instead of N round-trips.

Parameters:

• beats (required): Ordered list of beat specs. Each accepts {prompt, duration_seconds?, seed?, first_frame_uri?, negative_prompt?, audio_prompt?}
• aspect_ratio: Default 9:16 for vertical social clips
• model: VEO model applied to every beat (default veo-3.1-fast-generate-001)
• include_audio (default true): Audio per beat (Vertex only)
• beats are capped at 20 per call — each is a billed Veo render, and add_bridges nearly doubles that. Split longer sequences into several clips
• add_bridges: Generate a transition between consecutive beats using the last frame of beat N and the first frame of beat N+1. Requires local (file://) beat outputs
• animatic: Render every beat with gemini-omni-1.1-flash (fast 720p) for a storyboard preview of the whole reel before committing to full Veo renders. Bridges and Veo-only controls (seed, negative_prompt) are ignored in this mode
• animatic_resolution: Resolution for the animatic pass. Naming one renders it on gemini-omni-1.1-flash; 360p is a third of the 720p price, which is what turns the preview from roughly the cost of the delivery render into a real saving on a long reel
• output_gcs_uri: GCS URI for all outputs

Partial failure is non-fatal. A failed beat is recorded in the manifest's errors list and the run continues; bridges that would have used the failed beat are skipped.

Returns: a clip manifest — {kind, aspect_ratio, segments[], total_duration_seconds, errors[]}.

Suggested flow: run once with animatic: true to preview the whole sequence fast, then re-run with animatic: false once the beats read well.

generate_transition

Generate a transition video between two still frames using Veo 3.1's first+last-frame mode. Pair with a cutting MCP that extracts the last frame of clip A and the first frame of clip B.

Parameters:

• first_frame_uri (required): Starting still (gs://, https://, file://)
• last_frame_uri (required): Ending still
• prompt: Transition motion and style (default: smooth cinematic transition between the two frames)
• model: Veo model — default veo-3.1-fast-generate-001
• duration_seconds: 4/6/8s, snapped to nearest
• aspect_ratio, include_audio, audio_prompt, negative_prompt, seed, output_gcs_uri

generate_bridge

Same primitive as generate_transition, but takes two clips instead of two stills: it decodes the last frame of from_clip_uri and the first frame of to_clip_uri for you, so no frame extraction step is needed.

Parameters:

• from_clip_uri (required): Clip whose last frame starts the bridge
• to_clip_uri (required): Clip whose first frame ends the bridge
• prompt: Transition motion and style (default: smooth cinematic cut between the two clips)
• model, duration_seconds, aspect_ratio, include_audio, audio_prompt, negative_prompt, seed, output_gcs_uri — as above

Returns: JSON with video_url, sidecar_url, and the source clip URIs.

Fast drafts vs. high-fidelity

There are two video paths, and you choose based on where you are in the workflow:

• gemini-omni-flash-preview (switched off) — 720p, 24fps, conversational multi-turn editing. No seeds, no negative prompts, no first/last-frame control. Switched off on 2026-10-22; pinning omni_model="gemini-omni-flash-preview" is now refused before any quote or call. The draft and animatic paths no longer route here.
• gemini-omni-1.1-flash (fast, and far more controllable) — everything above plus 360p/1080p/4K output, first/last-frame interpolation, video references, native audio and scene extension. Still no seeds and no negative prompts. Reached by passing omni_model="gemini-omni-1.1-flash" to generate_video_omni or edit_video, and by extend_video_omni.
• Veo 3.1 / Fast (high-fidelity, Vertex AI only) — up to 1080p/4K, seeds for reproducibility, first/last-frame control, reference images, and extension. The path for final renders. Reached via generate_video (default) and loop_extend.

Typical workflows (plan_generation recommends these as ordered workflow steps, with both figures quoted):

• cheap draft → finalize: run generate_video_omni(omni_model="gemini-omni-1.1-flash", resolution="360p") for a preview at roughly a third of the 720p price, then re-run at 720p/1080p/4K — or on Veo — once the shot is right. The equivalent shortcuts are generate_video(draft=true, draft_resolution="360p") and generate_clip(animatic=true, animatic_resolution="360p").
• two stills → interpolation: give generate_video_omni a first_frame_uri and a last_frame_uri on 1.1 and it renders the motion between them — the same job generate_transition does on Veo, and the planner now offers both. The same URI for both loops the clip.
• draft → finalize: run generate_video(draft=true) to preview quickly on omni, then re-run the same prompt with draft=false to render the final on Veo.
• animatic → final: run generate_clip(animatic=true) to render each beat via gemini-omni-1.1-flash as a fast storyboard preview of the whole reel, then re-run with animatic=false (the default) to commit to full Veo renders.

Note: generate_clip's new animatic parameter (default false) renders each beat through gemini-omni-1.1-flash instead of Veo, so you can preview an entire reel quickly before committing to full Veo renders (price parity with the fast tier; the saving is real only against the standard tier).

Google Vertex AI and Gemini Access

Vertex AI Setup

Vertex AI gives you images and video plus GCS output and Vertex-only features. If you only need images and video without those extras, the Gemini API is simpler to set up.

Step 1: Create a Google Cloud Project

1. Go to the Google Cloud Console
2. Click the project dropdown at the top of the page
3. Click "New Project"
4. Enter a project name and click "Create"
5. Note your Project ID (you'll need this later)

Step 2: Enable Vertex AI API

1. In the Cloud Console, go to "APIs & Services" > "Library" (or visit API Library)
2. Search for "Vertex AI API"
3. Click on "Vertex AI API" in the results
4. Click the "Enable" button
5. Wait for the API to be enabled (this may take a minute)

Step 3: Create a Service Account

1. Go to "IAM & Admin" > "Service Accounts" (or visit Service Accounts)
2. Click "Create Service Account" at the top
3. Enter a name (e.g., "gemini-media-mcp") and description
4. Click "Create and Continue"
5. In the "Grant this service account access to project" section:
   • Click the "Select a role" dropdown
   • Search for "Vertex AI User"
   • Select "Vertex AI User" role
   • Click "Continue"
6. Click "Done" (you can skip the optional "Grant users access" section)

Step 4: Download Service Account Key

1. In the Service Accounts list, find the account you just created
2. Click the three dots (⋮) in the "Actions" column
3. Select "Manage keys"
4. Click "Add Key" > "Create new key"
5. Select "JSON" as the key type
6. Click "Create"
7. The JSON key file will automatically download to your computer
8. Important: Move this file to a secure location and note the path (e.g., ~/credentials/gemini-media-service-account.json)
9. Security Note: Never commit this file to version control or share it publicly

Step 5: Update Configuration

Use the following values in your configuration:

• GOOGLE_CLOUD_PROJECT: Your Project ID from Step 1
• GOOGLE_CLOUD_LOCATION: us-central1 (or your preferred region)
• GOOGLE_APPLICATION_CREDENTIALS: Full path to the JSON key file from Step 4

Gemini API Setup

The simplest way to generate both images and video:

1. Visit Google AI Studio
2. Sign in with your Google account
3. Click "Create API Key"
4. Copy your key (starts with AIzaSy...)
5. Set the environment variable: export GEMINI_API_KEY=your-api-key

Note: On the Gemini API, video runs on Gemini Omni. Google switched off Veo 3.1 there (all tiers, including Lite) on October 22, 2026, so Veo needs Vertex AI, which also adds GCS output and Vertex-only features such as controllable audio.

Contributing

Development Setup

uv sync

Running Tests

uv run pytest

Code Quality

# Type checking
uv run basedpyright src/ tests/

# Linting and formatting
uv run ruff check src/ tests/
uv run ruff format src/ tests/

# Pre-commit hooks
uv run prek

Building Docker Image

docker build -t gemini-media-mcp .

# With specific version
docker build --build-arg VERSION=1.0.0 -t gemini-media-mcp:1.0.0 .

License

MIT