Model Context Protocol began as a way to connect AI applications to tools and context. By summer 2026, it is also becoming a product-distribution layer. A media company can operate a remote MCP server that exposes its generation models. A model platform can let developers register remote MCP servers as agent tools. An assistant can discover and call those tools without every provider inventing a unique plugin interface.

Runway MCP, Gemini remote MCP, and Claude’s tool stack show that convergence from three directions. They also show why “supports MCP” is an incomplete product description. The provider, model, host, connector, authentication method, transport, and external job remain separate components with separate responsibilities.

A four-layer model for MCP

Most confusion disappears when an MCP workflow is divided into four layers:

  1. The model interprets a request and decides whether and how to use a tool.
  2. The host or API manages conversation state, user interface, approvals, and tool-result delivery.
  3. The MCP connection handles discovery and structured calls to a configured server.
  4. The provider service authenticates the user, performs the operation, bills usage, and returns results or task state.

One company may operate several layers, but the contracts remain different. A more agentic model does not automatically gain a server. A server appearing in a client does not imply every tool is authorized. A successful tool call does not prove an asynchronous render has finished.

Runway turns media generation into remote tools

Runway announced its remote MCP server on May 27, 2026. It exposes image and video generation capabilities available through Runway inside MCP-compatible agent experiences. The setup described by Runway uses the hosted endpoint https://mcp.runwayml.com, followed by sign-in to a Runway account. Runway says a separate API key is not required for this path, and usage is tied to the account’s plan.

That changes the front end for media creation. A user can ask an agent to generate an asset, let the agent select an available Runway tool, and receive the output in the same working context. Runway positions the server for concept art, product visualization, storyboards, effects, and campaign assets.

The server remains provider-specific. MCP does not turn a Runway model into a local model or a generic video primitive. Model availability, credits, moderation, retention, output limits, and account access still come from Runway. Agents should surface which model and parameters they selected instead of hiding a costly generation behind a vague “make video” action.

Runway MCP also differs from Runway Dev. The former is a hosted tool server for MCP clients; the latter is a broader API platform with models, recipes, workflows, and characters. Teams should choose the surface that matches their product. A conversational creative session and a backend production pipeline have different observability and versioning needs.

Gemini makes remote MCP part of agent configuration

Google approaches MCP from the model-platform side. The Interactions API supports remote MCP servers as external tools. Its documented configuration includes a server name, URL, headers, and allowed tools. Google currently specifies Streamable HTTP for this path and does not support SSE-only MCP servers in the Interactions API configuration.

Managed Agents, announced in public preview in May 2026, adds Google’s Antigravity agent and an isolated Linux sandbox. A developer can customize an agent with instructions, files, skills, functions, and separately registered remote MCP servers. The managed runtime can reason, browse, execute code, and persist environment state across follow-up interactions.

“Managed” does not make the remote server part of Google. The developer still chooses the URL, supplies or references credentials, filters tools, and accepts the server’s trust and data-handling terms. Google’s documentation notes that sandbox outbound access is open by default unless restricted, which makes allowlists and least-privilege headers important.

Status language matters here too. The Interactions API is generally available as of June 2026, while Managed Agents remains public preview. A production architecture should isolate preview-specific agent definitions and not assume all managed features inherit the API’s GA status.

Claude separates model capability from connector behavior

Anthropic released Claude Sonnet 5 on June 30, 2026 and describes it as its most agentic Sonnet model. It is designed to plan, use browsers and terminals, call tools, and operate over long tasks more reliably than the previous Sonnet generation. Those capabilities improve the reasoning side of a tool workflow.

The actual connection to a remote MCP server is controlled by the product or API surface. Anthropic’s MCP connector for the Messages API is documented as a beta capability. It can connect directly to remote servers, filter allowed or denied tools, work with multiple servers, and support OAuth. It handles MCP tool calls; it does not make local stdio servers directly reachable from Anthropic’s API.

Anthropic documents remote HTTP transports for its connector and requires a beta header in the API request at the time of writing. It also says MCP connector usage is not eligible for Zero Data Retention. These operational facts can matter more than the model name for a sensitive deployment. Verify the current beta header, transport, regional availability, and retention policy before shipping.

Claude applications may also use client-side tools executed by the developer or other server-side tools operated by Anthropic. These are not synonyms for MCP. Log where each tool runs and who can see its inputs.

What the 2026 pattern signals

Remote MCP lowers integration friction in three ways. Providers can publish one tool surface to several compatible clients. Agent hosts can add capabilities without embedding each vendor SDK. Users can authorize a service in the context where they work.

The pattern also shifts competition toward tool quality. A useful server needs clear names, compact schemas, stable errors, progress visibility, and outputs that an agent can validate. Models waste fewer turns when a tool explicitly distinguishes asset upload, job creation, status query, and result retrieval.

MCP may therefore become an important distribution channel, but it does not erase REST APIs or SDKs. Backend applications often need deterministic control, high-volume batch submission, webhooks, service accounts, or contractually pinned versions. An MCP server can wrap those capabilities, yet the application still needs durable state outside the conversation.

Security and governance do not come from the protocol

A remote MCP server can receive sensitive prompts, files, and identifiers. It can change schemas, return malicious instructions, or perform side effects. Review the operator, endpoint, authentication flow, privacy policy, data region, and tool list before adding it.

Use allowlists rather than exposing every advertised tool. Separate read and write authority. Require approval for uploads, publication, destructive actions, and paid generation. Treat returned text and metadata as untrusted content. Record server identity, tool name, schema version, normalized arguments, response, and external job ID.

OAuth or account sign-in improves credential handling but does not answer whether the granted scope is appropriate. Likewise, a provider-hosted server reduces endpoint ambiguity but does not guarantee that every generated asset is safe, accurate, or licensed for the intended use.

Where Medux Remote MCP fits

Medux represents a separate provider-service layer focused on supported media-processing operations. It is not made native to Runway, Gemini, or Claude because each supports MCP. In the linked tutorials, Medux Remote MCP is independently configured and authorized in Codex or Claude, which then acts as the controller.

The Codex video-editing tutorial shows an asynchronous merge: Codex inspects clips, requests temporary signed upload URLs and Medux file IDs, uploads the source files, creates one merge task, polls by its returned task ID, downloads the MP4, and verifies it. The Claude audio-track tutorial follows the same boundary with an audio asset and a silent video.

That role differs from Runway MCP. Runway’s server exposes generative image and video capabilities from Runway. The Medux examples expose defined post-processing operations. An application may use a generator and then send an approved result to a separate finishing tool, but the handoff must be built and authorized by the application. MCP support on both sides does not create an automatic tool-to-tool pipeline.

With Codex, configuration belongs in the Codex environment and the user approves the relevant remote tools. With Claude, configuration may live in the Claude product, a client application, or Anthropic’s API connector depending on the workflow. Do not copy credentials between hosts or assume one OAuth session applies to another.

Persist Medux asset and task IDs outside the model transcript. If a controller restarts, query the known task instead of generating a duplicate. Validate the output before a later tool publishes or transforms it. The best signal from MCP in 2026 is not that every service has merged into one platform; it is that independently governed capabilities can be composed through a clearer interface.