Most MCP coverage is about code: repositories, tickets, databases. The media pipeline is less discussed and, for a content site, more directly useful — script in, voice out, asset stored, video delivered, errors visible.
Four servers cover that arc: ElevenLabs MCP for voice, Cloudinary MCP for assets, Mux MCP for video delivery, and Replicate MCP for model runs.
The short answer
Treat each server as a stage in a pipeline, not as a general capability. Generation is one stage, storage is another, delivery and monitoring are a third and fourth. Connecting them with an agent only works if each stage's output is verifiable — a file ID, a playback ID, an asset URL.
Stage one: generation
ElevenLabs gives you text-to-speech and a voice library. The useful pattern is narration: a script goes in, an audio file comes out, and the voice is one you chose from your own library rather than a default.
Replicate is the wider door: one interface over a catalogue of models covering image, video, music, and upscaling. That breadth is convenient and expensive, because every generation is a paid call the agent can repeat without noticing.
The discipline that matters at this stage is idempotency. Store the input, the model, and the parameters alongside the output. When you need a re-render six weeks later, a pipeline that logged those can reproduce it; one that did not has to guess.
Stage two: assets
Cloudinary handles storage and transformation: search the library, generate delivery URLs, apply transformations. The value is that the URL is the interface — an agent can hand back a URL that already encodes size and format.
This is also the stage where permissions should be narrowest. Reading and listing assets is safe; deleting and bulk-modifying are decisions that belong to a person looking at a list.
Stage three: delivery
Mux manages video assets, playback IDs, and delivery. In an agent workflow its most useful job is diagnostics: why is this video not playing, what is the asset status, is the playback policy attached.
That is a read-path service. Write access to production playback policy from an agent is the kind of convenience that costs a weekend when it goes wrong.
The connection points
| Stage | Server | Verifiable output |
|---|---|---|
| Narration | ElevenLabs | Audio file URL |
| Model runs | Replicate | Prediction ID, asset URL |
| Asset store | Cloudinary | Public ID, delivery URL |
| Video delivery | Mux | Asset ID, playback ID |
The pattern is that every stage produces an identifier, and the next stage consumes it. A pipeline that passes files instead of identifiers breaks at the first retry.
What an agent adds
The agent is not producing the media; the models are. What the agent adds is orchestration across a job that has too many steps for a shell script and too few decisions for a person.
A concrete example: take a drafted article, generate a two-paragraph narration, render a social card image, store both in the asset library, and return three URLs and a duration. That is a sequence of tool calls with no judgement, which is exactly what agents are good at.
Where it breaks
Three failure modes we would expect:
- Silent cost. Generation calls are paid and invisible in the response. Cap them at the application layer.
- Orphaned assets. Assets uploaded and never referenced. A weekly reconciliation query is cheaper than a storage bill.
- Format drift. The same asset delivered in three formats because three stages made their own decision.
The first build: one job, one server
The temptation is to wire all four servers at once. The failure is predictable: an agent with four new capabilities will use whichever is easiest, and the pipeline becomes a series of surprises.
Start with one stage. Narration is the clearest: a script in, an audio file out, a URL returned. Run it for a week on real content and watch where it breaks — pronunciation, pacing, a voice that does not suit the piece.
Then add asset storage, because the second problem is always "where does the file go". Only after that is there a reason to add delivery and monitoring, which exist to answer questions about assets that already exist.
The logging discipline
Every stage should log its input identifier and its output identifier. Not the prompt, not the prose — the IDs. That log is what lets you rebuild a pipeline run six weeks later without regenerating everything.
It is also what makes cost visible: a run that touched four paid APIs should produce four log lines with a cost estimate each.
Frequently asked questions
Do I need all four servers? No. Start with the stage that is actually manual today — usually narration or asset search — and add stages as the workflow proves out.
Can an agent publish a video end to end? It can assemble one. The decision to publish is a different question, and the answer should involve a person.
What about images? The Pexels and Unsplash servers cover stock search; a generation model covers bespoke imagery. Both return URLs, which is the format the rest of the pipeline expects.
Last checked: 9 November 2026.
Related: briefing a video model, licensing AI images, and MCP servers.