Most MCP servers hand a model some text. This one hands it a rendering pipeline. Add ClipSpeedAI as a connector, describe what you want in a sentence, and the model finds the moments, renders vertical clips with burned-in captions, scores them, and reports back with the finished files — all without you opening a tab.
Real ClipSpeedAI output — every clip below was scored, cut, reframed to 9:16 and captioned automatically from the video above it.
Source video
15:27
There is no package to build and nothing to run locally on the hosted path.
In Claude, open Settings, then Connectors, then add a custom connector and paste https://api.clipspeed.ai/mcp. Click Connect and choose Sign in with ClipSpeed. You authenticate with Google or email, approve the connection, and that is the whole setup — no key to copy, nothing pasted into a config file, nothing living in your shell history.
Give it a link and a preference: clip this in hormozi captions, or find the fastest-growing AI-tools video this week and cut it up. The model picks the tool, fills in the arguments, and starts the job. You are not learning an argument schema — the schema is the model’s problem, which is the entire reason this interface exists.
Clipping runs in the background rather than blocking the chat, so the submit call hands back a project id and you carry on. Ask whether the clips are done and the model polls the job and lists what came back with a viral score against each one. Ask for titles, hooks and posting times and it fetches those too.
These are live in production, not a roadmap. Each maps to a real endpoint behind the same account you use in the app.
Name a niche, or say nothing and it reuses your last one, and the tool scans recent videos in that space and returns the fastest-growing pick along with why it stood out. This is the piece that makes an unattended loop possible: you never had to know which video to paste, so the sentence "grow my AI page" becomes a complete instruction.
Hands any video URL to the engine and returns a project id. Optionally set a caption style up front. It deliberately does not wait for the render, because a tool call that blocks for twenty minutes is a tool call that fails, and the model handles the wait far more gracefully as a follow-up question.
Polls a project id and, once the render is complete, returns each clip with its title, duration, 0-100 score and a link. In practice this is the call you make from your phone an hour later while you are somewhere else, which is a workflow no timeline-based editor supports at all.
Returns suggested titles, opening hooks and platform-aware posting times for a finished project. Clipping was never the last step; writing eleven titles and deciding when to publish them is real work, and this is the call that closes that gap inside the same conversation.
Lists the caption presets — karaoke, hormozi, beasty, fire, youshaei and cinematic — so you can ask what the options are instead of guessing a style name and getting a validation error back. Style is the single most visible decision in a short-form clip, so it is worth one question up front.
Sends a finished clip to a connected YouTube account, and it defaults to private. That default is deliberate: an agent with publish rights that defaults to public is one misread sentence away from an embarrassing upload, and nobody wants to discover a tool call in their subscriber feed.
Beyond the recorded-video loop, the connector exposes tools to start clipping a live broadcast, check on the session while it runs, extend it, and stop it. Asking your AI to watch a stream and cut the moments is a genuinely strange sentence to be able to say, and it works. More on that in the YouTube live clipper.
The hosted connector returns links. If you want the MP4s written straight to your own ~/Downloads folder, install the clipspeed-mcp package instead — a local stdio server can touch your disk where a hosted one cannot. Pin the version rather than floating on latest, so a background update never changes tool behaviour mid-project.
Claude Code, Cursor and Windsurf take an HTTP MCP server with an Authorization header, which means one command or one config block and a key from your account settings. Windsurf uses serverUrl rather than url in its config, which is the single most common reason a working setup appears broken.
If your working day starts in a chat window, the tab switch to a web app is the friction. Removing it is a smaller change than it sounds and a much bigger one in practice.
One add command and clipping is available beside your repo. Handy when the marketing clip and the release note are the same task on the same afternoon.
One message after publishing, one message an hour later to collect. Compare the fuller workflow on the podcast clip generator.
The agent covers finding the moment, cutting it, captioning it and suggesting the title. What is left is a human deciding whether to post, which is the part worth keeping human.
A tool that returns media rather than text is a rare thing to compose with. It changes what an agent chain can end in.
Discovery plus clipping in one turn means the gap between noticing a spike and having something postable is a sentence, not an afternoon.
A language model on its own can do a surprising amount with a video transcript. Paste one in and it will happily suggest which passages would clip well and roughly where to cut. Then the conversation stops, because the model cannot cut anything. You take its timestamps, open a tool, scrub to each one, crop the frame, add captions and export. The insight was free and the execution was the whole job.
The Model Context Protocol closes that specific gap. It is a standard way for an AI client to call an external system, so the model that just decided which moment matters can also be the thing that renders it. The clip that comes back is a real file with burned-in captions and a vertical crop, produced by the same pipeline the web app uses. Nothing is simulated and no output is a description of a clip.
The second thing it changes is who holds the context. The model already knows what you are working on, which video you mentioned two messages ago, and that you said you wanted the punchier caption style. None of that has to be re-entered into a form. Over a session that adds up to more saved effort than the individual tool calls do.
Conversation wins when the next step depends on what came back. You are exploring, you do not know which video yet, you want to see three scores before deciding what to publish, and the shape of the task changes as you go. That is a bad fit for a form and a great fit for a chat window, and it is why the discovery-then-clip loop feels natural here and clumsy anywhere else.
It loses when the flow is fixed and nobody is watching. Clipping every episode of a weekly show at the same time each Tuesday does not benefit from a model deciding anything — it benefits from a cron job that never gets creative. For that, use the clip maker API directly; the endpoints underneath are the same ones the connector calls.
It also loses when you need to see the frame. Judging whether a crop kept the right person in shot is a visual question, and a chat transcript is a poor place to answer it. Clip in the conversation, then open the app when you want to look at something properly.
Front-load the constraints. A first message that names the caption style, the number of clips you care about and what you intend to do with them saves three clarifying turns, because the model fills the tool arguments from what you said rather than from a default it picked. "Cut this into vertical clips with the punchy yellow captions and show me only the top three" is a complete brief.
Then let the job breathe. The submit call returns a project id on purpose, so the correct next move is to go and do something else. Asking twice in ninety seconds achieves nothing except two identical status responses, and the render is not going faster because the conversation is impatient.
Ask for the packaging in the same session rather than a new one. The context you built — which video, which style, who it is for — is what makes the suggested titles and posting times land, and starting a fresh chat throws all of it away.
Keep one habit manual. Look at the clip before it goes anywhere public. Everything upstream of that is worth handing to an agent; the last check is cheap and it is the only thing standing between a misread instruction and your audience.
Work through it in the order the failure actually occurs. First, does the client see the tools at all? Several clients read MCP configuration only at launch, so a connector added while the app was running is a connector the model has never heard of; restart before you change anything. If the tools still do not appear and you are on a config file rather than the hosted sign-in, check the key name your client expects — one of them wants serverUrl where the rest want url, and the mismatch fails silently instead of complaining.
Second, does the call reach us? An authentication failure on a static key is almost always the key itself: copied with a trailing newline, revoked when someone rotated it, or belonging to an account whose plan lapsed. The OAuth path in Claude sidesteps the whole category because no key exists to mangle. If the model reports the tool errored but cannot say why, ask it to show you the raw error — the envelope names the failure type, and that string is worth more than any amount of guessing.
Third, is the argument wrong rather than the connection? The classic is a caption style the model invented. Ask it to list the templates first and it will use a real preset name instead of a plausible one. The same goes for a project id from a previous session that no longer exists in your account — the model will happily poll a stale id forever, and it takes one sentence to make it start a new job instead.
Fourth, and this is the one people misdiagnose most: the clips came back and something about them looks wrong. A chat window cannot show you framing, and the failure mode of speaker tracking is not an error but a static crop that quietly ignores whoever is talking. If a batch feels off, open the app and look at a frame. Judging a crop, a caption position or a Brand Kit colour is a visual question, and the conversation is the wrong instrument for it.
Finally, a job that seems stuck is usually just a job. Source length and queue depth both move the number, and asking three times in two minutes produces three identical answers. What genuinely warrants attention is a project id you submitted an hour ago that the status call cannot find at all, which normally means the submission never landed and the model narrated an intention rather than a completed tool call.
Anything you have to look at closely does not belong in a chat. Comparing two caption styles, checking that filler-word and silence removal has not clipped a beat you wanted, nudging an in-point by a third of a second — those are all decisions made with your eyes, and the honest answer is to use the web app for them. The conversation is a control surface, not a viewer.
Volume is the other boundary. Say you have four hundred archived episodes to work through: an agent is a poor batch runner, because every job costs a turn, the context fills with status chatter, and nobody wants to babysit a chat window for a weekend. Wire the clip maker API to a queue and let the webhooks land while you sleep. As a rule, if a person is not going to read the output of each step, there is no reason for a model to be in the loop at all.
The other options are worth naming plainly. The app is better for review and for anything visual. The REST API is better for fixed, repeatable, unattended flows. A no-code HTTP node in an automation platform gets you most of the API benefit without writing a service. And a conventional editor is still the right tool when the deliverable is a package with archive footage or a graphics template rather than a clip. None of those are competitors so much as different shapes of the same job.
Two limitations are worth stating because they surprise people. The model never sees your video — it passes a URL and receives structured results, so it cannot tell you whether the crop looks good or whether the captions sat over someone's mouth. And there is no video generation anywhere in the product: no invented footage, no synthetic narration, no machine-made cutaways. Every frame that comes back was in the source, which is a deliberate position rather than a gap in the roadmap.
An MCP server that can post to your channel deserves more scrutiny than one that can read a calendar. Two design choices matter here. The first is that publishing defaults to private, so the failure mode of a misunderstood instruction is an unlisted upload you delete rather than a public one your audience already saw. The second is that the connector is scoped to your ClipSpeedAI account and the platform accounts you deliberately linked in the app — connecting it does not hand anything a general grant over your channels.
The practical advice is the boring kind. Keep publishing as an explicit request rather than something you tell the agent to do standing instruction-style, review what came back before it goes out, and use a static key only where you actually need one. On Claude the OAuth path avoids a key existing at all, which is one fewer secret to rotate.
Observations from operating the pipeline in production — not general advice.
A face-detector self-test on our side once returned a false negative for months, and the consequence was not a crash: every clip simply rendered as a static centre crop while the dashboards stayed green. Quality degraded and nothing reported it. That is the exact risk profile of handing a pipeline to an agent, because the model reads a success payload and reports success — it has no eyes on the frame. In practice the cheapest defence is a human looking at one clip per batch, not more monitoring.
Most MCP tools answer and finish. Starting a live capture on YouTube, Twitch or Kick does something stranger: the call returns in a second and the work keeps running for hours afterwards, which is why there are separate tools to check, extend and stop a session rather than one call that does it all. Say you kick off a four-hour Friday stream and then close the laptop — the session runs to the window you gave it and stops on its own, so the failure mode is an unattended session that expired early, not a runaway one.
The clip count you name is a target the engine will not pad to reach. Cuts land on sentence boundaries and there is a hard 15-second floor underneath every clip, because below that a viewer reads it as a fragment however good the moment was. A thin twenty-minute source with two real moments in it returns two, and an agent that promised you ten will sound apologetic about a result that is actually correct. Judge a run by the scores that came back, not by the length of the list.
This is what people do today and it is genuinely useful for finding the moments. It ends at a list of numbers. Everything expensive — the cut, the reframe, the captions, the export — is still ahead of you, and the timestamps drift the moment you trim anything.
The app is better for anything visual: reviewing a crop, comparing caption styles side by side, nudging an in-point. MCP is better for starting work from wherever you already are and for collecting results later. Most people who use both end up starting in chat and finishing in the app.
A lot of connectors wrap a search index or a read-only lookup, which is fine but bounded — the model gets more to say and nothing new to do. A server that renders media expands the set of tasks an agent can finish rather than just describe.
You can call the REST endpoints from your own agent framework and some teams should. The connector saves you the auth flow, the tool descriptions, the polling etiquette and the argument validation, all of which are small jobs that add up to an afternoon you did not plan on.
One URL, one sign-in, and your AI can cut video. Start with a link you already meant to clip and see what comes back.
⚡ Get A.I Clips — $1 trial
