Model Context Protocol has moved from an integration experiment to a practical distribution channel for agent tools. In May 2026, Runway launched a remote MCP server for generating images and videos from compatible agents. In July, Google added direct remote MCP connectivity to managed agents in the Gemini API alongside background execution and custom functions.
That adoption solves an important interface problem: an agent can discover a capability and call it through a shared protocol. It does not make media a simple function. Image, video, audio, and avatar work remains large, asynchronous, stateful, expensive, and subject to rights and review. A production agent therefore needs a media layer behind—or exposed through—the MCP surface.
What MCP standardizes
The official MCP architecture defines a host, clients, and servers. The host is the AI application. It controls connections and security policy. Each client maintains a connection to one server, while servers expose focused capabilities.
At the data layer, MCP uses JSON-RPC and defines lifecycle management plus core primitives:
- tools are executable actions the model can call;
- resources provide contextual data;
- prompts provide reusable interaction templates;
- notifications and utilities support progress and other coordination.
At the transport layer, local servers can use standard input and output, while remote services can use Streamable HTTP. Initialization and capability negotiation let the parties declare what they support.
This is significant because a media provider can publish tool schemas once instead of building a separate extension for every agent. Runway says its MCP server can be added to Claude, ChatGPT, Cursor, or another compatible agent and tied to the user’s Runway account. Google’s managed agents can now receive a remote MCP server as a tool beside built-in search or code execution.
What MCP does not standardize
A protocol call does not determine how a five-gigabyte source video reaches a renderer. It does not choose object storage, retention, transcoding, queue priority, model pricing, content review, or output delivery. It does not make two providers use the same concepts for duration, seed, reference strength, voice identity, or safety.
MCP also does not guarantee that a remote tool is trustworthy. The server can receive data and perform actions under whatever authorization the host grants. A clean schema can still wrap an unsafe, unreliable, or poorly governed service.
Think of MCP as the control plane. It carries capability descriptions, structured arguments, responses, and progress. Media files often need a separate data plane using signed upload and download locations, checksums, scoped authorization, and explicit retention.
Why media workloads need durable tasks
A database lookup may finish in one tool response. A video generation or character replacement may queue, process for minutes, fail downstream, or finish after the client disconnects. Returning an open network request for the entire render is fragile.
A media layer should create a durable task with:
- a unique task identifier and idempotency key;
- operation, model, parameters, and source references;
- normalized state such as queued, processing, completed, failed, or canceled;
- provider-specific state retained for diagnosis;
- timestamps, progress, and a bounded error object;
- estimated and actual usage where the service exposes them;
- result references, checksums, and expiry;
- ownership, access policy, and audit trail.
The 2026 MCP roadmap explicitly recognizes lifecycle gaps around transient retry semantics and result expiry. Those issues are especially visible in media because a retry can create another billable render and an expired result can mean losing a large asset.
Uploads are a security boundary
Embedding large binaries into prompts or tool arguments is inefficient and can exceed request limits. A common pattern is to request a short-lived upload destination, transfer the file directly, and pass an opaque file identifier into the media task.
The upload layer must validate content type, actual file signature, size, checksum, malware risk, ownership, and expiry. A filename is not a trustworthy media type. Signed URLs should be scoped to one object and short period, kept out of logs, and never reused as permanent asset links.
Source rights belong at this boundary too. A successful upload does not establish permission to clone a voice, transform a face, remove a watermark, or republish a video. Capture consent and allowed use before granting the task access to the file.
Provider diversity belongs behind an adapter
Runway’s MCP announcement lists access to several image and video model families from one creative surface. Google managed agents can combine remote MCP servers with other tools. These products reflect a broader trend: agents increasingly choose capabilities at runtime rather than bind every workflow to one SDK.
A media layer should normalize what can be normalized without pretending every model is interchangeable. Use a stable internal description for task identity, file references, status, cancellation, results, and errors. Keep model-specific controls inside an explicit options object or separate capability schema.
Forcing all generators into the smallest common schema removes useful features. Exposing raw provider requests everywhere recreates coupling. The balanced approach offers a stable lifecycle plus discoverable model-specific capability and validation.
Progress is not the same as completion
Agents need a disciplined wait loop. Polling too frequently wastes requests and can trigger limits; polling too slowly creates a poor interactive experience. Notifications or callbacks can reduce polling, but clients still need reconciliation after missed events.
On every status check, query the same task ID. Use backoff and a maximum wait policy. Treat completed, failed, and canceled as terminal. If the client times out, do not submit a duplicate until it has established that the original task does not exist or is safe to replace.
Completion also needs validation. Check that the result can be downloaded, matches the expected container and dimensions, contains the required streams, and has a stable checksum. “Provider says complete” is an operational state, not editorial approval.
Cost controls must exist before action
Media tools can spend materially more than lightweight SaaS actions. The host should know which calls are billable, expose an estimate when available, and require confirmation above policy thresholds. Cap resolution, duration, variants, concurrency, and retries.
Keep a ledger by task rather than reconstructing spend from chat transcripts. Include rejected outputs and failures when billing applies. Measure cost per accepted asset, because an inexpensive model with a low acceptance rate can be more expensive than a higher-priced model that succeeds quickly.
An MCP description can tell a model that an action is costly or destructive, but prose is not enforcement. Apply server-side limits and authorization even if the agent omits a warning.
Remote MCP changes the threat model
A remote MCP server sits outside the host and may have its own data handling, retention, and security controls. Review the operator, endpoint, OAuth scopes, network path, regional behavior, logs, deletion, and incident process.
Give each agent only the servers and tools it needs. Separate read and write capabilities. Validate arguments outside the model, require user confirmation for sensitive transformations or publication, and use idempotency for external effects.
Treat tool descriptions, retrieved resources, uploaded documents, and media metadata as untrusted input. Prompt injection can ask an agent to call another tool, disclose a secret, or broaden a task. The host’s authorization policy must remain independent of content the model reads.
Evaluate the layer, not only the model
Model quality matters, but the surrounding layer determines whether an agent can finish. Test large uploads, expired URLs, duplicate requests, provider outages, queue spikes, status-event loss, cancellation, partial outputs, unsupported files, unsafe requests, and permission revocation.
Record completion rate, duplicate-job rate, time to result, cost variance, download success, validation failures, and human acceptance. Run contract tests whenever a provider adapter or MCP schema changes. A visually better model does not compensate for a task system that loses outputs.
Medux as a separately configured media layer
Medux exposes media operations to authorized Codex or Claude clients through a remote MCP connection. It is a separate service, not a native component of Runway, Gemini managed agents, or the other model providers mentioned here.
The Codex video merge tutorial shows the control and data planes clearly. Codex requests temporary upload URLs and file IDs, uploads two MP4 files, starts a merge task, queries its status, downloads the result, and verifies the finished video. The Claude audio-track tutorial follows the same lifecycle for a video and audio file before creating an asynchronous add-audio task.
For a production design, preserve these boundaries:
- the agent proposes the operation and source assets;
- a user or policy layer approves sensitive or costly actions;
- signed uploads transfer only required files;
- one Medux task ID represents the operation;
- bounded polling follows that same task;
- the result is downloaded, checked, and approved;
- source and output checksums remain attached to the record.
If a generator changes, an approved clip from the new provider can still enter a later merge or audio-finishing operation. If finishing fails, retry that task without silently regenerating the source. The stable value is the explicit lifecycle, not a claim that every underlying model behaves identically.
MCP makes capabilities reachable. A media layer makes them operable. Agents that create production media need both: a standard control surface and durable infrastructure for the large, slow, costly, reviewable work behind each tool call.