For AI agents
← Back to home

MCP in media, video and streaming: what exists, and the gap nobody has filled

Two years into the Model Context Protocol, an agent can transcode a file, cut a timeline, search a video library and clone a voice. It still cannot do the thing broadcast actually is: run a channel that keeps playing after the tool call returns.

Published 1 August 2026 · My TV Channel

What MCP actually changed for media

Media software has never lacked APIs. Every encoder, MAM, playout system and CDN has had one for twenty years. What they lacked was a way for something that had not been programmed against them specifically to find out what they could do.

That is the whole of MCP’s contribution, and it is worth stating without inflation: a server describes its tools at runtime, and a client that has never seen it before can read that description and start calling. No SDK, no per-integration glue, no release cycle between “the vendor shipped a capability” and “my agent can use it.”

For media that matters more than for most domains, because media workflows are unusually long chains of unrelated tools. A single job might touch an asset store, a transcoder, a captioning service, a rights database and a distribution platform, none of which have ever heard of each other. Every one of those hops used to be a bespoke integration.

The map: every layer that has a server

Here is the landscape as of August 2026, organised by what the tools actually operate on rather than by vendor marketing. Names are examples, not endorsements, and the list is not exhaustive — new servers appear weekly.

Layer What the agent manipulates Examples
Infrastructure The asset lifecycle — upload, encode, playback policy, signed URLs, delivery analytics Mux, Cloudflare Stream, Bunny
Editing & render A timeline — layers, cuts, transitions, overlays, then a rendered file out Shotstack (cloud), Kinocut (local, open source), Wireflow (pipelines)
Understanding The contents of video — semantic search, indexing, scene and object retrieval TwelveLabs
Voice & localization Audio tracks — synthesis, dubbing, translation, transcription AllVoiceLab and similar
Generation Pixels from nothing — text-to-video and image-to-video models The model vendors’ own endpoints
Playout & linear A channel — a continuous schedule that is on air now and stays on air Essentially empty

Read down the third column and the pattern is hard to miss. Every mature server in media takes an asset in and gives an asset back. Upload this. Cut that. Find the scene where the logo appears. Dub it into Spanish. They are, in the precise sense, stateless with respect to time: the job finishes, the tool returns, and nothing is left running.

The layer that doesn’t

Linear playout is the one media layer where the deliverable is not a file. A channel is a process. It was playing before you called the tool, it is playing while you read the response, and it will be playing tomorrow whether or not anyone calls anything.

The video MCP ecosystem stops at the clip. Nothing on the market operates the channel.

The nearest neighbours are worth naming honestly, because “nobody has done this” is the kind of claim that ages badly:

Why the gap is there

Not because nobody thought of it. Because durable state is genuinely harder to expose to an agent than a render is, in four specific ways.

1. Success now can be wrong later

A transcode either produced a file or it did not, and you know within minutes. A schedule is a claim about the future. A tool call can return success: true and produce a broadcast that is wrong at 6pm — the wrong programme in the wrong slot, a gap where an asset failed, the same clip four times an hour. The feedback loop that lets an agent self-correct is broken by default, because the error surfaces hours after the call.

2. Writes are not idempotent in the way agents assume

Agents retry. That is fine when the operation is “render this timeline” and catastrophic when it is “insert this programme into the live schedule.” Every mutating tool in a playout surface needs to answer: what happens if this runs twice? Most API designers have never had to think about it, because most APIs are called by code that was written once and does not improvise.

3. The moment a change reaches the air is not the moment you made it

This one bites everybody. In our own system, a channel builds its schedule the instant it crosses its launch threshold, from the weights present at that moment. Set a weight afterwards and it is stored faithfully, reported back correctly, and does not change what is on air until the schedule is regenerated.

An agent doing the obvious sensible thing — import everything, then tune the weights — produced a channel where a weight-3 clip and a weight-9 clip got identical airtime, and every tool call along the way returned success. We only found it because we pointed an agent at our own documentation and watched what it built.

4. Unattended operation needs a safety vocabulary

“Regenerate the schedule” is destructive: it replaces what was going to air. So is replacing a ruleset. An agent has no way to know that unless the server says so. MCP’s tool annotations — readOnlyHint, destructiveHint, idempotentHint, openWorldHint — are the mechanism, and they are widely under-used. Without them a cautious client asks permission for everything, which trains the user to click through, which is worse than not asking.

The design rule that falls out of all four: every destructive scheduling tool needs a dry-run twin that saves nothing and returns what would happen. Ours returns a simulated 24-hour grid. It is deliberately not tier-gated, because the whole point is that an agent calls it before it commits.

What an agent-operable channel actually requires

Concretely, if you are building this layer, here is the surface that turned out to be the minimum. Nine tools of ours are read-only, and that ratio is not an accident — most of what an agent needs is the ability to find out where things stand.

What we learned building one

We built this surface for My TV Channel and then did the thing that is easy to skip: gave an agent nothing but an API key and the documentation, and told it to take a channel from nothing to broadcasting.

It found nine defects. Two made the documented path impossible, and neither was findable by reading the application code:

The rest were the same shape: documentation that disagreed with the implementation, an error state that was reported on a healthy asset, a tier gate we told people to pay for that they already had. All of it invisible to a human clicking through the app, all of it fatal to something reading the docs literally.

The generalisable lesson: pointing an agent at your own public API is the cheapest documentation audit that exists. A human tester brings context and routes around the gaps without noticing. An agent has only what you wrote down, so every place the docs and reality disagree becomes a hard stop — which is exactly what you want from a test.

A note on the numbers

Articles in this space tend to open with a wall of market statistics. Most of them do not survive being chased to a source, so here are the few that do, with their provenance attached and their disagreements left visible rather than averaged away.

The reason to care about the direction rather than the decimals: the number of linear channels is going up while the cost of originating one goes down, which is the condition under which programmatic channel creation stops being a curiosity.

Where this goes

The clip layer is close to solved and will commoditise fast; there is not much differentiation left in “call FFmpeg from an agent.” The interesting problems are the ones that involve time: scheduling, rights windows, ad insertion, continuity, what happens at 3am when a source disappears.

The 2026 protocol work on native media types will help — agents that can pass video around directly rather than trading URLs. But it does not touch the harder half. Handing an agent a video is a transport problem. Handing it a broadcast is a state problem, and state is where the design work actually is.

If you want to see the state problem solved end to end, the fastest route is to watch a channel that was built entirely through it.

Try it against a live channel

demo.my-tv-channel.com is broadcasting right now. The channel, its programmes, their weights and its 24/7 schedule were all created through the MCP tools described here — nobody opened the app.

Nineteen tools, Streamable HTTP, listed in the official MCP registry and on Smithery.

See the tools and connect

Sources