Cline

Generate videos in Cline

One remote server entry, and Cline can render video. Renderly runs a hosted MCP server, so Cline renders from the templates you already built - and previews cost nothing.

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

Clineexample session

You

products.csv has 18 SKUs dropping Friday. Render the Product Drop video for each row.

renderly_list_projects
Finds Product Drop in your Renderly library
1 match - 24 seconds - 7 dynamic variables
renderly_get_variables
Reads the variable contract for that project
sku_name, price, badge, hero_shot, colourway, drop_date, cta

Your CSV calls the price column msrp, and there is no drop_date at all. I will map msrp to price, use Friday's date for every row, and preview the first SKU before spending anything.

renderly_preview_render0 credits
Checks SKU 1 for free, no video produced
resolved 6/7 - warning UNKNOWN_REPLACEMENT: badge_text

The variable is badge, not badge_text, so the sale flash never applied. Fixing it and updating the same preview in place.

renderly_preview_render0 credits
Updates the same preview, revision 2
resolved 7/7 - no warnings - quote 0.5 credits per video

Grid view looks right at every frame. 18 SKUs at 0.5 credits each is 9 credits. renderly_create_render is not in your autoApprove list, so Cline will stop and ask before it spends.

renderly_create_render9 credits
Renders all 18 once you approve
18 jobs queued - 0.5 credits each
renderly_get_render_status
Polls the batch until every job lands
18/18 complete - MP4 links written to drops/friday/

2 previews, charged nothing9 credits spent, on the render alone

Cline runs in the VS Code sidebar with read and write access to the repository you have open, plus a terminal it can drive. That covers two of the three things a product-drop video needs: the catalogue file, and the means to loop over it. The missing third is a renderer. Renderly's hosted MCP server supplies one as a single remote entry in cline_mcp_settings.json, a URL and a transport type, with nothing to install and nothing running on your machine. Once it is connected, Cline can list the projects in your Renderly library, read which overlays you marked dynamic, fill them from a products.csv sitting three folders away, and check the result before a credit moves. The part that matters for a tool that spends money is Cline's autoApprove array. It is a per-server list of tool names, so you can write renderly_list_projects, renderly_get_variables and renderly_preview_render into it, leave renderly_create_render out, and get a run where every free step passes silently and the paid one stops in the sidebar for you to approve.

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 Cline asked for it.

The free preview loop

Cline 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 Cline catches that before it becomes a charge.

Setup

Connect Renderly to Cline

Cline reads remote MCP servers from one settings file that the VS Code extension, the cline CLI and the SDK all share. Three routes reach it: the Remote Servers tab in the panel, the cline mcp CLI, or the JSON itself. The Remote Servers tab has no field for headers, so if you authenticate with an API key you will finish in the JSON or on the command line anyway.

~/.cline/data/settings/cline_mcp_settings.json - with an API key

{
  "mcpServers": {
    "renderly": {
      "type": "streamableHttp",
      "url": "https://renderly.video/api/mcp",
      "headers": {
        "Authorization": "Bearer rnd_..."
      },
      "disabled": false,
      "autoApprove": [
        "renderly_list_projects",
        "renderly_get_variables",
        "renderly_preview_render"
      ],
      "timeout": 900
    }
  }
}

In this file type must be the camelCase literal streamableHttp. timeout is in seconds, not milliseconds: the default is 60 and any number you give is clamped into the range 1 to 3600, so a copied 60000 becomes an hour rather than a validation error.

~/.cline/data/settings/cline_mcp_settings.json - with OAuth instead

{
  "mcpServers": {
    "renderly": {
      "type": "streamableHttp",
      "url": "https://renderly.video/api/mcp",
      "disabled": false,
      "autoApprove": []
    }
  }
}

No headers at all, and that is a hard requirement: Cline refuses to start OAuth for a server that already has a static Authorization header. Renderly answers the first call with a 401, and Cline runs the WorkOS AuthKit flow in your browser.

Any shell - the CLI surface

# Interactive wizard: prompts for name, transport type and URL
cline mcp

# Prefill the same wizard for Renderly (needs a real TTY)
cline mcp install renderly --transport http https://renderly.video/api/mcp

# Scripted, no TTY: --yes writes the entry straight to the settings file
cline mcp install renderly --yes \
  --transport streamableHttp \
  --header "Authorization: Bearer rnd_..." \
  https://renderly.video/api/mcp

# Confirm what is registered
cline config mcp --json

The --transport flag accepts http, streamable-http or streamableHttp and normalises all three to streamableHttp. The settings file is stricter, and only the camelCase literal works there. One more difference worth knowing: install writes the nested shape, { "transport": { "type": ..., "url": ... } }, which Cline reads alongside the flat shape shown above.

Any shell - locating the settings file

# Default, shared by the extension, the CLI and the SDK
~/.cline/data/settings/cline_mcp_settings.json

# Overrides, highest precedence first
CLINE_MCP_SETTINGS_PATH=/abs/path/to/cline_mcp_settings.json
CLINE_DATA_DIR=/abs/path/to/data
CLINE_DIR=/abs/path/to/cline

Ignore ~/.cline/mcp.json if a docs page offers it. No Cline code reads that file, which is what open issue cline/cline#11671 is about.

In the Cline panel, click the MCP Servers icon in the top toolbar, then open the Remote Servers tab.
Enter Server Name renderly and Server URL https://renderly.video/api/mcp, set Transport Type to Streamable HTTP rather than SSE (Legacy), and click Add Server.
Switch to the Configure tab and click Configure MCP Servers. That opens whichever cline_mcp_settings.json your installed build actually uses, which is the most reliable way to find it.
Paste in the headers block if you are using an API key, or leave headers out and let the first 401 start the OAuth flow. Prefer the terminal? Run cline mcp install renderly --yes --transport streamableHttp --header "Authorization: Bearer rnd_..." https://renderly.video/api/mcp, then cline config mcp --json to check the entry.
Leave Use MCP servers switched off in Auto Approve for now, and ask Cline to list your Renderly projects. If your own project names come back, the server is live.

Either a browser sign-in or an API key

Both work here. The route Cline's own remote-server example shows is a static key in the headers object: we accept an rnd_ key as a plain Bearer token, so there is no browser round trip and the entry behaves the same in a headless CLI run. The alternative suits anyone who dislikes keys in files. Omit headers and Cline's MCP OAuth takes over on our 401, doing PKCE with S256 and dynamic client registration against WorkOS AuthKit. The two do not mix: Cline stops the OAuth flow with an error if the server entry already carries an Authorization header, so pick one. Note also that the Remote Servers tab has no header field, so the key path always ends in the JSON file or in cline mcp install.

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 Cline's current MCP documentation and survived an independent adversarial recheck on the same date. Nobody here drove Cline end to end. Cline’s documentation

The surface

Ten tools Cline gets

You never call these by hand. Cline 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 Cline

What this client is good at

Cline's approval controls are granular in a way that suits a tool with a price attached, and they work in two layers. The Auto Approve menu carries a single "Use MCP servers" permission, and each server entry in the JSON carries its own autoApprove array naming individual tools. List the three free Renderly tools there, omit renderly_create_render, and exploration runs unattended while every render waits for a human. The second reason is the shared settings file. The VS Code extension, the cline CLI and the SDK all resolve the same ~/.cline/data/settings/cline_mcp_settings.json, so the server you add in the sidebar today is the server a headless catalogue run picks up tomorrow, with no second config to keep in step.

Questions people actually hit

Cline's docs point me at ~/.cline/mcp.json, but that file isn't there. Where does the config actually live?

The path on the MCP docs page is a documentation bug: no Cline code reads ~/.cline/mcp.json. The real file is ~/.cline/data/settings/cline_mcp_settings.json, and one copy serves the VS Code extension, the cline CLI and the SDK. Open issue cline/cline#11671 tracks it and links three earlier reports from people who could not find their config. Three environment variables override the default, highest precedence first: CLINE_MCP_SETTINGS_PATH, then CLINE_DATA_DIR, then CLINE_DIR. If you are unsure which file your build uses, click Configure MCP Servers on the Configure tab; it opens the live one.

I added the Renderly URL to cline_mcp_settings.json and Cline sees a server, but the tools never load. What did I get wrong?

Almost always a spelling problem. In the settings file the field must read "type": "streamableHttp", camelCase and no hyphen. Write streamable-http, or omit type entirely, and Cline treats the entry as legacy SSE for backward compatibility, which is the wrong protocol for https://renderly.video/api/mcp and leaves the tool list empty. We do keep a legacy SSE endpoint at https://renderly.video/api/sse if you genuinely need one. While you are in that entry, autoApprove is the per-server allowlist of tool names. Start it empty, then add the three free tools once you trust the connection.

I upgraded from Cline 3 to 4 and my Renderly entry vanished. Did the settings file move?

It did. Cline 3 kept MCP settings in two older places: a settings folder inside the VS Code extension's globalStorage for saoudrizwan.claude-dev, and ~/Documents/Cline/MCP/cline_mcp_settings.json. Cline 4.x moved storage to ~/.cline/data/ and migrates each of those sources on first launch. The trap is editing an old copy afterwards. The migration is recorded per source and does not run twice, so your renderly entry never appears in the live file and nothing warns you. Use the Configure MCP Servers button, which always opens the file the running build reads.

Can I connect Cline to Renderly without putting an rnd_ key in a settings file?

Yes. Leave the headers object out of the renderly entry and keep url and type. Renderly answers the first unauthenticated request with a 401 carrying resource_metadata, Cline recognises that as an MCP authorisation error, and it runs the full flow against WorkOS AuthKit: PKCE with S256, dynamic client registration, and a callback on 127.0.0.1 at the first free port of 1456, 1457 or 1458, path /mcp/oauth/callback, with five minutes to finish. Remove any Authorization header first, because Cline refuses to start OAuth while one is set.

My employer's Cline install ignores the Renderly server I add. Is something wrong with my JSON?

Probably not, and the block is deliberate. Cline's enterprise remote configuration lets an administrator push a remoteMCPServers list and set blockPersonalRemoteMCPServers to true. After that only the admin-listed URLs are allowed, and they are checked when a server connects, so your own entry is ignored however correct the JSON is. Ask whoever owns your Cline configuration to add https://renderly.video/api/mcp to the managed list, with type streamableHttp. Your rnd_ key or your own OAuth login still identifies you once the URL is permitted.

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 Cline 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.