MCP for broadcast: what the Model Context Protocol means for media workflows

August 28, 2026

A producer building a rundown touches six systems before lunch. The newsroom computer system holds the running order. The archive holds the footage. The graphics system holds the lower thirds. The captioning platform holds the subtitle files. The compliance log holds what cleared legal. The playout automation holds what actually goes to air.

Every one of those has an API. Most have had one for a decade. But each API is different, each authenticates differently, and connecting an AI assistant to all six means writing six integrations, then rewriting them when any vendor ships a new version.

The IBC 2026 Accelerator programme put the cost in one sentence. Producers, it says, spend more time re-entering context and correcting misunderstandings between tools than the tools save them.

The Model Context Protocol is an attempt to fix the connector problem underneath that. It is worth understanding before IBC, because it has moved from a developer curiosity to a standards recommendation and a live production deployment in under two years.

What is the Model Context Protocol?

MCP is an open standard for connecting AI models to external tools and data. Anthropic created it and open-sourced it in November 2024. On 9 December 2025 it was donated to the Agentic AI Foundation, a Linux Foundation project co-founded with Block and OpenAI, with support from Google, Microsoft, AWS, Cloudflare and Bloomberg. The code is Apache 2.0 and the documentation is CC BY 4.0.

Cuez, one of the vendors on the 2025 IBC Accelerator project, described it as a universal plug: it lets AI connect to tools and data without custom work each time. That is the right level of intuition.

Mechanically, MCP defines three roles. A host is the AI application. A client is the connector inside it. A server exposes capabilities from some system you already run. Servers offer three things: tools the model can call, resources it can read, and prompts it can reuse. Later revisions added sampling, filesystem roots, and elicitation, which lets a server ask the user for more information mid-task.

Messages are JSON-RPC 2.0. Two transports matter: stdio for a local subprocess, and Streamable HTTP for anything remote. The original HTTP with Server-Sent Events transport was deprecated in March 2025, and vendors began removing it during 2026. If you are specifying anything today, Streamable HTTP is the only remote transport with a future.

The scale is real. At the point of donation the project reported more than 97 million monthly SDK downloads and over 10,000 active servers.

One thing MCP is not: a replacement for your REST APIs. An MCP server is a uniform, model-facing wrapper over the interface a system already exposes. If the underlying API cannot do something, neither can the server in front of it. The community DaVinci Resolve server, for example, can only reach what Resolve Studio's external scripting API exposes. MCP standardises the shape of the conversation, not the capability underneath.

Why does broadcast have the problem MCP solves?

Because of arithmetic that anyone who has quoted a systems integration job already knows.

Connect N AI applications to M systems point to point and you write N times M integrations. A facility running a MAM, an NRCS, playout automation, graphics, QC, captioning, archive and a compliance logger is already at eight. Three AI applications across those eight is twenty-four separate integrations, each with its own auth, its own error handling, and its own maintenance burden when a vendor ships a breaking change.

With a shared protocol it becomes N plus M. Eight servers, three clients, eleven things to maintain. That is the entire pitch, and it is the same reason the industry standardised MOS for newsroom-to-device communication in the first place.

The difference is what gets exchanged. MOS connects systems operationally: it moves playlists and story items and device commands. What broadcasters want now is something that connects systems semantically, so a model can ask what happened in this archive clip rather than fetch object 4471.

Is anyone actually using MCP in broadcast?

Yes, though the first production deployment came from the advertising side rather than production.

At CES on 6 January 2026, NBCUniversal announced agentic ad-buying across linear and digital, describing a real-world transaction powered by AI agent-to-agent collaboration leveraging Model Context Protocol. The work involved RPA, FreeWheel and Newton Research, with the first executions scheduled for the first quarter of 2026, including live football playoff inventory. FreeWheel followed with a productised MCP Server on 11 March 2026.

On the standards side, SMPTE's AI Taskforce, working with the EBU and the Entertainment Technology Center, recommended standardising on MCP and A2A. Taskforce co-chair Frederick Walls put it plainly: one of the recommendations was to standardise on things like Model Context Protocol and A2A.

Among vendors, Octopus Newsroom markets Octopus MCP as the core of its agentic workflows in Octopus 13, describing it as secure AI access to newsroom data, context and workflows. Dalet released Dalia, a media-aware agentic AI, commercially in April 2026. Avid announced a multi-year partnership with Google Cloud on 16 April 2026, embedding Gemini into Media Composer and its Content Core platform for agentic search and automated logging. Neither Dalet nor Avid has branded its work as MCP specifically.

Broadcasters are moving too. E.W. Scripps built a newsroom production platform on Microsoft Copilot and stood up a dedicated AI team in March 2026, with executives describing hundreds of agents in use. RTL Deutschland announced an agentic AI strategy in November 2025 alongside an RTL-specific language model developed with Fraunhofer IAIS. The BBC launched two generative AI news production pilots on 27 June 2025 under a strict human-checking policy. Reuters has AVISTA in production. ZDF has demonstrated a coordinated set of persona agents.

The clearest broadcast-specific thread runs through the IBC Accelerator. The 2025 project, AI Agent Assistants for Live Production, was built on MCP, championed by ITN, the BBC and Channel 4, and named IBC Project of the Year. Amira Labs was one of the participants, alongside Google Cloud, EVS, Moments Lab, CuePilot, Shure and others.

There is also a growing set of community MCP servers wrapping media tools: FFmpeg, DaVinci Resolve, Premiere Pro. These are useful for experimentation and are not products.

What would an MCP server look like in your facility?

Start with read-only work, because that is where the risk is lowest and the payoff is immediate.

Archive search. Expose your MAM's search and metadata read endpoints as tools. A journalist asks for the clip of the harbour fire from last winter and gets candidates with timecodes, rather than constructing a query in a UI they use twice a month.

Compliance and clearance checks. Expose the rights and clearance database as a resource. Before a promo cuts, the agent checks what is licensed for which territory and flags what is not.

QC triage. Expose the QC system's report data. An agent reads overnight failures, groups them by likely cause, and drafts the morning summary instead of an engineer scrolling a dashboard.

Captioning and localisation orchestration. Caption generation, language identification and subtitle validation are separate steps that usually live in separate tools. Exposed as tools behind one protocol, an agent can route a file through the right chain and report what came back, which is precisely the coordination work that currently consumes a scheduler's morning.

Rundown assembly. Read the wire feeds, the archive and the running order, propose an order, and leave the editorial decision with the producer.

Notice what these have in common. None is frame-accurate. None sits in the signal path. All of them are the work around production rather than production itself, and all of them are currently done by a person switching windows.

How does MCP relate to MOS, NMOS, FIMS and MXL?

It sits above them, and it does not replace any of them.

NMOS IS-04 and IS-05 handle discovery and connection management for media nodes. That is a control plane for devices, operating on a timescale MCP has no business in.

MOS connects newsroom systems to devices, moving stories and playlists. MCP overlaps here conceptually but at a different altitude: MOS is operational, MCP is semantic. The IBC 2026 incubator explicitly frames its work as MOS for the intelligent computing era, which is a fair description of the gap.

FIMS and EBUCore describe services and metadata. They remain the vocabulary. MCP is a way for a model to reach them.

MXL, the shared-memory layer coming out of the EBU's Dynamic Media Facility work, is a tap source. It carries the actual frames and samples that an inference function reads. MCP carries none of that. Think of MXL as how a function gets the pixels, and MCP as how an agent asks a function a question about them. They operate on different planes and there is no conflict between them.

The practical implication: MCP is additive. You are not migrating anything. You are putting a uniform, model-facing surface in front of interfaces you already run.

Where does MCP not belong?

This matters more than the use cases, because the failure mode of a new protocol is people putting it somewhere it cannot survive.

Not in real-time signal paths. Playout switching, live routing, synchronised graphics triggers. The latency characteristics are wrong, the statefulness is wrong, and the reliability guarantees do not exist. Keep NMOS, MOS and vendor control planes there.

Not as a substitute for a schema. MCP standardises how a model calls a tool. It says nothing about what a story, a clip or a rundown item actually is. Without a shared data model you have standardised the plumbing and left the semantics to every vendor's interpretation. That gap is exactly what the IBC 2026 work is trying to close.

Not where you cannot afford non-determinism. An agent choosing which tool to call is a probabilistic act. For anything that goes to air, a human approves.

There are engineering constraints too. Large tool sets consume context window, since every tool description is tokens the model carries. Statefulness complicated load balancing enough that the 2026 specification revision reworked the protocol toward stateless operation by default. Observability and versioning tooling are immature compared with anything you would normally put in a broadcast chain.

What about security?

This is the part to take seriously, and the part most vendor material skips.

The core issue is structural. Tool descriptions are read by the model as instructions. That makes every connected server an instruction channel, and an attacker who controls a server description controls part of your model's context.

Named attack classes documented since 2025 include tool poisoning, where malicious instructions are embedded in a tool description; rug pulls, where a server silently redefines a tool after you approved it; tool shadowing across servers; confused deputy attacks; and token theft. Simon Willison's framing is the most useful shorthand: risk concentrates when a system combines access to private data, exposure to untrusted content, and the ability to communicate externally. Broadcast systems routinely have all three.

Real vulnerabilities have followed. CVE-2025-6514 in the widely used mcp-remote proxy scored 9.6 and allowed command execution when connecting to an untrusted server. CVE-2025-49596 was a remote code execution flaw in Anthropic's own MCP Inspector. Two Cursor IDE vulnerabilities were disclosed in August 2025. In March 2026, an authentication bypass scoring 9.8 was patched after active exploitation. Security researchers catalogued dozens of MCP server CVEs in a single sixty-day window in early 2026.

The mitigations are known and unglamorous. Use Streamable HTTP with OAuth 2.1, and require the RFC 8707 resource parameter so a token issued for one server cannot be replayed at another. Pin server versions and re-approve on change rather than trusting mutable definitions. Run servers behind a gateway with audit logging. Treat every tool description as untrusted input. Keep write actions gated behind human approval.

One honest caveat on the scary numbers: an April 2026 audit found roughly a 78% false positive rate from pattern-based MCP scanners, so treat headline percentages about vulnerable servers with scepticism.

The registry situation reinforces the point. An official MCP registry launched in preview in September 2025, and GitHub launched its own days later, but there is still no meaningful certification or trust-rating tier. For a regulated broadcast environment, that means server provenance is your problem, not the registry's.

What is happening at IBC 2026?

The Accelerator incubator to watch is Smart Stories: The Agentic Production Ecosystem. Its champions include the AP, Al Jazeera, the Washington Post, the BBC, Channel 4, ITV, Sky, the EBU, NBCUniversal, SMPTE, Reuters, ITN and Scripps. The goal is an open Story Object Model plus a reference architecture for reusable skills.

That is the missing half of the picture described above. A protocol without a shared object model gets you interoperable plumbing and incompatible meaning. If the SOM work produces a credible multi-vendor demonstration in Amsterdam, the case for building against this stack gets considerably stronger. If it produces slideware, the honest read is that this remains a 2027 conversation.

Also worth tracking: whether NBCUniversal's Q1 2026 agentic buys actually executed as announced, and whether any production or editorial vendor ships MCP support with a security model attached rather than as a feature bullet.

What should you ask any vendor?

Four questions that separate an agentic strategy from an agentic slide.

Do you expose an MCP server, and against which specification revision? Date-based versions make this easy to check. An answer of "we support MCP" without a revision means nobody has thought about the deprecation of SSE.
How do you authenticate, and do you validate the audience claim? If a token issued for their server also works elsewhere, they have skipped RFC 8707 and built a token-replay problem into your facility.
What happens when a tool definition changes? If the answer is that clients pick it up automatically, that is a rug-pull waiting to happen. You want pinned versions and explicit re-approval.
What data model are you using for stories and assets? If the answer is proprietary, you get one vendor's agents working well and nothing else. Ask whether they are tracking the Story Object Model work.

What to do this week

Inventory your APIs. Not your systems, your interfaces. Which of your eight or fifteen or forty platforms expose a documented, authenticated API today? That list is your realistic MCP surface, because a server can only wrap what already exists. Most facilities find the answer is both better and worse than expected: more systems have APIs than people think, and fewer of them are documented.

Pick one read-only workflow and prototype it. Archive search or QC triage. Read-only means the blast radius of a mistake is a wrong answer rather than a wrong transmission. Run it behind a gateway with logging from day one, so you learn your observability gaps in a lab rather than on air.

Write the security requirements before the pilot, not after. Streamable HTTP, OAuth 2.1, audience-bound tokens, pinned server versions, human approval on anything that writes. These are cheap to specify up front and expensive to retrofit.

Send someone to the Smart Stories sessions at IBC. The protocol question is largely settled. The data model question is not, and it is the one that determines whether any of this composes across vendors.

If your interest in agents is driven by the cost of doing this work manually, the same arithmetic applies to the inference underneath it. We worked through those numbers in what live captioning actually costs in 2026, and the infrastructure question in our guide to MXL and the EBU Dynamic Media Facility.

Sources

Get started Book a demo Pre-order hardware