Google

Generate videos in Gemini CLI

One httpUrl entry, and your terminal renders video. Renderly runs a hosted MCP server, so Gemini CLI renders from the templates you already built - and previews cost nothing.

5 free credits · no card · hosted MCP, nothing to install

Gemini CLIexample session

You

villas.json has 12 new properties from the feed. Render the Villa Listing spot for each one.

renderly_list_projects
Finds Villa Listing in your library
1 match, 16:9, 32 seconds, 24 variables
renderly_get_variables
Reads what the spot actually accepts
24 fields; sleeps and bedrooms are separate

Your feed has one capacity field, but the template wants sleeps and bedrooms separately. I will split it and preview the first villa for free.

renderly_preview_render0 credits
Checks villa 1 at no cost
previewUrl plus ?mode=grid sheet, resolved 24/24, no warnings

The contact sheet reads correctly. All 12 come to 12 credits, 1 each for 32 seconds. Shall I render?

renderly_create_render12 credits
Queues all 12 after you confirm
12 jobs accepted, 1 credit each, job ids returned
renderly_get_render_status0 credits
Checks the batch a few minutes later
12 of 12 complete, MP4 links ready to download

1 preview, charged nothing12 credits spent, on the render alone

Gemini CLI runs in your terminal, beside the files you already work with: a CSV of properties, a folder of photographs, a JSON feed you pulled from a PMS ten seconds ago with curl. It reads all of that happily. Video is the one output it has no way to produce on its own. Renderly's hosted MCP server supplies it, and supplies it with one field of JSON: an httpUrl pointing at https://renderly.video/api/mcp. Nothing runs on your machine, and there is no package to add to the repository. After one browser round trip, Gemini CLI can list the templates and projects you already designed in Renderly, read the variables each one exposes, fill them from whatever sits on disk, and check the result before a single credit moves. Two details make this comfortable to live with. The per-request timeout is expressed in milliseconds and defaults to 600000, which is ten minutes, so a real render usually finishes inside one tool call. And gemini mcp add writes to project scope by default, so the repository that holds the feed can hold the render setup too, and everyone who clones it gets the same one.

Renderly is the rendering engine, not the publisher. It hands back a finished MP4 at a URL - where that file goes next is up to you or one of our no-code integrations. The same engine and the same credits drive the REST API, so nothing about a render differs because Gemini CLI asked for it.

The free preview loop

Gemini CLI can check its work before you pay for it

An agent filling in a template will get something wrong - a mistyped variable name, a headline too long for its line. Renderly gives it a way to find out for nothing. A preview takes the same arguments as a real render and resolves them exactly the same way, but produces no video and costs no credits.

Preview0 credits
Fix, preview again0 credits
Once more0 credits
Rendercredits charged

It can look at the frames

Append ?mode=grid and the preview page draws a labelled contact sheet spanning the whole video, as ordinary images. Any agent that can open a page and screenshot it can then see a collided caption or a wrong colour - the failures no validator catches.

?mode=grid

Or one exact moment

Append ?frame=N to check a specific instant, where N is the second you care about multiplied by the frame rate. The page publishes its own rate, so the agent works it out rather than guessing from the nearest tile on the grid.

?frame=N

And fix it in place

Pass the previewId back with corrected values and the same preview updates. The link never changes, so the agent reloads and looks again. A revision counter goes up each time, which is how it knows it is seeing its own latest attempt and not a cached earlier one.

previewId

The warning that saves the most credits. If a variable name does not match, Renderly ignores it silently and renders the authored default instead - so the video comes back looking fine and carrying the wrong text. A preview returns a resolved map of what actually applied plus an UNKNOWN_REPLACEMENT warning, which is how Gemini CLI catches that before it becomes a charge.

Setup

Connect Renderly to Gemini CLI

Gemini CLI can register a remote MCP server from the shell or from a settings.json file. Both write the same entry, so pick whichever you prefer.

Any terminal

gemini mcp add --transport http renderly https://renderly.video/api/mcp

This defaults to project scope and writes .gemini/settings.json in the current directory. Add -s user to install Renderly globally instead.

~/.gemini/settings.json

{
  "mcpServers": {
    "renderly": {
      "httpUrl": "https://renderly.video/api/mcp"
    }
  }
}

mcpServers stays at the top level, even after the v0.3.0 nesting changes. Do not put it inside the separate mcp key, which only holds serverCommand, allowed and excluded.

Optional, same file

{
  "mcpServers": {
    "renderly": {
      "httpUrl": "https://renderly.video/api/mcp",
      "timeout": 900000,
      "excludeTools": ["renderly_create_render"]
    }
  }
}

Only if you want to change the defaults. timeout is milliseconds, so 900000 is fifteen minutes. excludeTools here hides the one tool that spends credits, which is a useful setting on a shared or unattended checkout.

Run the add command, or paste the JSON block into ~/.gemini/settings.json if you want Renderly available in every directory.
Start gemini. On the first Renderly tool call the CLI meets our 401, reads resource_metadata out of the WWW-Authenticate header, discovers the WorkOS authorisation server, registers itself, opens a browser and caches the tokens in ~/.gemini/mcp-oauth-tokens.json.
Run /mcp list to confirm the connection. A healthy Renderly server reports ten tools. Do not rely on a silent startup meaning success: MCP errors are quiet by default, and all you get is one hint reading "MCP issues detected. Run /mcp list for status."
Ask it to list your Renderly projects, then preview one before you render anything. Previews are free and return a shareable /p/ link.

Sign-in only - an API key will not work here

Leave the auth alone and it works. Give Gemini CLI only the httpUrl, and on the first Renderly call it meets our 401, reads resource_metadata out of the WWW-Authenticate header, discovers the WorkOS authorisation server, registers itself through dynamic client registration with PKCE, opens a browser and caches the tokens in ~/.gemini/mcp-oauth-tokens.json. No oauth block is needed, and authProviderType already defaults to dynamic_discovery. That handshake needs a local browser and a redirect on http://localhost, which the documentation is explicit about: it does not work on a headless box, in a container without browser support, or over plain SSH without X11 forwarding. Run the CLI where a browser can open, then use /mcp auth renderly to repair a stale grant.

How this was checked. Server verified live on 2026-08-19: an unauthenticated POST returns 401 with an RFC 9728 challenge, WorkOS AuthKit advertises Dynamic Client Registration, and all ten tools are registered. The setup below was confirmed against Google's current MCP documentation and survived an independent adversarial recheck on the same date. Nobody here drove Gemini CLI end to end. Google’s documentation

The surface

Ten tools Gemini CLI gets

You never call these by hand. Gemini CLI picks the right one from what you asked for. They are listed because it is worth knowing which of them can cost you money - and that seven of the ten cannot.

They are thin wrappers over the same service layer the public REST API uses, so the two surfaces cannot drift apart.

Renderly MCP tools, what each does, and whether it costs credits
Tool	What it does	Cost
`renderly_whoami`Connect	Confirms the connection and reports your credit balance	free
`renderly_list_projects`Find	Lists your own projects that have something to personalise	free
`renderly_list_templates`Find	Lists the public system templates	free
`renderly_get_variables`Find	Reads which fields a template or project accepts, and their current values	free
`renderly_preview_render`Check	Resolves your values exactly as a render would, without producing a video - returns a public preview link, what actually applied, a credit quote and any warnings	free
`renderly_create_render`Render	Renders the video. Annotated as not read-only, so clients ask before calling it	credits
`renderly_get_render_status`Track	Polls the job and returns the finished video URL	free
`renderly_generate_captions`Add AI	Transcribes audio into word-synced captions you can drop straight onto a layer	credits
`renderly_generate_voiceover`Add AI	Turns a script into narration saved to your media library	credits
`renderly_get_ai_job`Add AI	Polls a captions or voiceover job for its result	free

Why Gemini CLI

What this client is good at

Gemini CLI declares the transport in the field name itself. You write httpUrl, not url, and that one choice is what puts you on Streamable HTTP at /api/mcp rather than SSE at the legacy endpoint. It is patient by default too: timeout is in milliseconds and starts at 600000, ten minutes, so a render normally completes inside a single tool call instead of being cut off mid-job. Because gemini mcp add defaults to project scope, Renderly ends up versioned in .gemini/settings.json next to the property feed, the CSV and the scripts that produce them, so a teammate who clones the repo already has it. The CLI also carries its own repair kit: gemini mcp list from the shell, /mcp list and /mcp auth renderly inside a session, and gemini mcp disable renderly when you want the tools out of the way for a while.

Questions people actually hit

Why does the Renderly block use httpUrl instead of url?

Because in Gemini CLI those two fields select different transports. httpUrl is the HTTP streaming transport, which is what https://renderly.video/api/mcp speaks. url means SSE, and would push the connection onto our legacy /api/sse endpoint. At least one of command, url or httpUrl must be present, and if you set several the documented order of precedence is httpUrl, then url, then command, so a stray url is harmless but pointless. There is no type field to set; the field name is the declaration. Running gemini mcp add with --transport http writes httpUrl for you.

I ran gemini mcp add and Renderly works in one folder but not others. What happened?

gemini mcp add defaults to project scope, so it wrote .gemini/settings.json inside whichever directory you were standing in. Pass -s user to put Renderly in ~/.gemini/settings.json and get it everywhere. A system file also exists for machine-wide policy: /etc/gemini-cli/settings.json on Linux, C:\ProgramData\gemini-cli\settings.json on Windows, /Library/Application Support/GeminiCli/settings.json on macOS, plus a system-defaults.json alongside each. Wherever you edit by hand, keep mcpServers at the top level. Do not nest it under the separate mcp key, which only carries serverCommand, allowed and excluded.

How do I tell whether Gemini CLI actually connected to Renderly?

Run /mcp list inside the CLI, or gemini mcp list from your shell, which prints one line per server with its URL, transport and connection state. This matters more here than with some clients, because a failed MCP connection is quiet at startup: you get a single hint, "MCP issues detected. Run /mcp list for status." Detailed diagnostics come back once you run an interactive /mcp command, call a tool from that server, or start with --debug, where F12 opens the debug console. Folder trust does not muddy the picture either, since that gates stdio servers rather than a remote one like Renderly. If the OAuth grant went stale, /mcp auth renderly redoes it.

What happens to a long render if I close the terminal or the session ends?

The render keeps going. It runs on Renderly's queue, not inside your CLI process, and renderly_create_render exists to start jobs rather than sit on them. Gemini CLI is generous anyway: the request timeout is in milliseconds and defaults to 600000, ten minutes, so most single renders resolve inside one call. For a long batch, keep the job ids that renderly_create_render hands back and ask for renderly_get_render_status later, in this session or the next one. Previews are instant and free, so do your iterating there.

Can I call the server something other than renderly?

You can, but keep underscores out of the alias. Gemini CLI gives every discovered tool a fully qualified name built from the mcp_ prefix and your server alias, and the documentation warns that the policy engine parses that name at the first underscore after mcp_, so an alias containing one makes it misidentify the server and your wildcard rules and security policies can fail silently. Stick to renderly, or another single word, or a hyphenated one. Once named, you can set trust: true on the server to skip per-call confirmations, or narrow the surface with includeTools and excludeTools. Bear in mind renderly_create_render is marked as not read-only, and trusting the server removes that prompt.

The same server, in every other client

One endpoint, one account, one credit balance. Only the wrapper changes.

Using something not listed? Any client that speaks remote MCP over Streamable HTTP can connect to https://renderly.video/api/mcp - these pages exist because the setup differs, not the server.

Let Gemini CLI render the next one

Build a template once, then describe what you want. Previews are free, so the first thing you spend a credit on is a video you have already seen.