Hand your coding agent a video studio the same way you hand it a database — over MCP. Here's how the connection actually works, and what to expect the first time you run it.
If you already run Claude Code or Cursor, you can hand it a video studio the same way you hand it a database or a browser: over MCP. Then “make a Short from this week's changelog” becomes a command in your editor instead of a context switch to a different app. This is how the connection actually works, and what to expect the first time you run it.
An MCP server is just a program that exposes a set of tools an agent can call. A video studio's MCP server exposes the pipeline — draft the script, author scenes, narrate, render, publish — as separate tools. Your agent connects to it, sees the tools, and calls them in order to build a video. Nothing runs in a hidden cloud you can't inspect; each call returns a result the agent (and you) can look at. (If MCP itself is new to you, start here.)
In Claude Code, it's one command:
claude mcp add --transport http reelmint https://reelmint.io/api/mcp \
--header "Authorization: Bearer YOUR_WORKSPACE_TOKEN"Or, if you edit config directly (Claude Desktop, Cursor), the same thing as JSON:
"mcpServers": {
"reelmint": {
"command": "npx",
"args": ["mcp-remote", "https://reelmint.io/api/mcp",
"--header", "Authorization: Bearer YOUR_WORKSPACE_TOKEN"]
}
}The token is workspace-scoped — it lets the agent act inside one workspace, and you rotate it in a click. Treat it like any other secret: it belongs in your MCP config, not in a repo.
Verify the connection before asking for anything: tell the agent to list the video tools it can see. If it names the pipeline — script, scenes, voice, render, publish — you're connected. If it sees nothing, the usual suspects are a typo'd URL, a token pasted with a stray space, or a client that needs a restart to pick up new config. Checking now costs ten seconds; discovering it mid-build costs the build.
Resist the urge to ask for a masterpiece on the first run. Ask for one clear thing: “Make a 45-second Short explaining what this repo does, in a draft I can review.” Watch what the agent does — it should call the tools in a sensible order: draft the script, check it, author the scenes, sync narration, stage a render. Each step returns something concrete, so if a scene comes back wrong, the agent can notice before moving on.
The reason to start small isn't caution for its own sake. It's that the first run teaches you the shape of the loop — where the agent is strong (assembling the pipeline, wiring the obvious scenes) and where it needs you (the hook, the one number that has to be exactly right, the joke).
This is the step people expect to be able to skip, and shouldn't. A good pipeline stages the video for you; it doesn't post on its own. You look at the draft, fix the two things that are off, and then you publish. The agent removed the tedium of assembling forty small pieces; you kept the judgment about whether it's good.
“Drafts overnight, you approve in the morning” is a genuinely better shape than “posts while you sleep,” and it's worth choosing on purpose rather than discovering after an agent publishes something half-right to your channel.
Set expectations honestly: a full build is not three tool calls. When we measured a real seven-scene Short built end-to-end by an agent, it took roughly thirty tool calls — create the reel, draft and commit the script, then scenes, voices, timing, transitions, render. That's the nature of a pipeline with seams: every seam the agent can inspect is also a call it has to make.
Two practical consequences. First, some MCP clients cap how many tool calls run in a single turn — on a long build you may have to nudge the agent to continue once or twice. That's the client's guardrail, not a hang. Second, watch the shape of the calls as they scroll by: you'll see an honest craft loop (draft, preview, fix, preview again) around the scenes that matter, and mechanical repetition around the ones that don't. Both are normal; only the second is worth engineering away — which is why the voice step here is one batch call for the whole reel rather than three calls per scene.
Three things, from building the server rather than using someone else's.
Tools have to return what a human would look at. Our first version had tools that returned “success” and an id. The agent would sail past a scene that had rendered wrong, because it had nothing to notice with. The fix was making each tool hand back the real state — the scene contents, a preview, the lint result — so the model can catch its own mistakes the way you would. If you're evaluating any agent-driven tool, this is the thing to probe: when a step goes sideways, does the agent find out?
The agent should be the second-to-last step, never the last. Everything upstream of “publish” is fair game for automation. Publish itself stays a human decision. That single boundary is what makes the whole thing safe to leave running.
And batch the mechanical, keep the judgment. Our first tool set made the agent call three voice tools per scene, six scenes in a row — eighteen calls where no decision was being made, just a loop crossing a network boundary. The rule we landed on: any consecutive run of tool calls with no caller judgment in between should be one tool. Now voicing a whole reel is a single call. But the preview–critique–rewrite loop on a scene stays as separate calls on purpose — that one is judgment, and collapsing it would blind the agent exactly where it needs eyes.
The failure modes you're most likely to meet, from running this daily ourselves:
MCP is young. Client support is real but still settling — the exact config differs slightly between Claude Code, Claude Desktop, and Cursor, and you'll occasionally hit a tool schema that's fussier than it should be. None of it is a dealbreaker; it's just a reminder that you're early. Being early is the point — the pattern is going to be everywhere, and it's a good time to have your workflow already speaking it. (Which models run each step is your call too — it's bring-your-own-keys.)
The quality of what you get tracks the quality of what you ask, so here are shapes that work — refined from our own daily runs:
The pattern across all five: name the checkpoint where you want to be consulted. The agent handles everything between checkpoints; the checkpoints are yours. Asks without checkpoints (“make me a video about X, publish when done”) produce exactly what you'd expect — something plausible you'd have changed three things about, already live where changing it is embarrassing.
The honest recommendation: connect the server, ask for one small Short, and watch the loop once. You'll understand agent-driven video better from a single real run than from any writeup — including this one.
Get one practical MCP-video tip when we publish the next post — no more than that.
Point your agent at a video pipeline that speaks MCP and make one small thing. Free founding-creator pilot — your keys, no watermarks.
Create your studio — free pilot