Remote vs local MCP servers for vendor integrations

The same tools, two delivery mechanisms

A vendor shipping an MCP server usually ships it in two forms: a hosted endpoint you point a client at, and a package the client runs on the developer’s machine. Cloudinary does both, publishing remote endpoints for Asset Management, Environment Config, Structured Metadata, Analysis and MediaFlows alongside local equivalents, and recommending the remote form (Cloudinary’s MCP server documentation, checked 2026-08-18).

Settle one thing before comparing anything else: this is a distribution decision, not a capability one. The same tools are exposed either way. What differs is who owns the update cadence and where the secret sits. The Model Context Protocol specification defines tool discovery and invocation separately from the connection carrying them, so a client that lists five tools over a spawned process lists the same five over HTTP. If you are picking a form in the hope that one unlocks an operation the other cannot perform, stop — that is not the axis.

What each form actually is

A remote MCP server is a URL in a config file. The server runs on the vendor’s infrastructure; your client opens an HTTP connection to it. Nothing is installed. The machine holds neither the vendor SDK nor a language toolchain, which is why a designer’s laptop, a locked-down corporate image or a hosted agent runner can connect on the same terms as an engineer’s workstation.

A local MCP server is a process the client spawns, usually over stdio — the client starts the binary, writes to its stdin and reads its stdout, and the transports documentation covers both that path and the HTTP one the remote form uses. Because the process is yours, its credentials never leave the machine. Because the process is yours, every developer is responsible for installing it and keeping it current.

Neither form is a billing decision at Cloudinary: MCP server access is included on every plan, Free included (https://cloudinary.com/pricing, checked 2026-08-18).

Install and runtime cost

Remote costs nothing to install. That is the whole of it — a URL in a config file, and the connection either works or it does not.

Local costs a runtime on every machine that will use it, plus whatever version of the package that machine happens to have. The cost is not the first install; it is the third month, when one developer is on a build from before a tool was renamed and files a bug that nobody else can reproduce. That drift is the real price of owning distribution, and it scales with headcount rather than with usage.

If the tooling is going to a mixed group — contractors, marketers, anyone whose machine you do not provision — remote is the only form that does not turn into a support queue.

Credentials, and where the secret ends up

This is where the two forms genuinely diverge. Remote servers support OAuth by default; local servers require manual credential configuration, which in practice means an API key and secret written into a config file on disk. Cloudinary’s recommendation of the remote form rests on exactly this.

OAuth means the client holds a scoped, revocable token obtained through a browser flow, and no long-lived vendor secret is typed anywhere. Manual configuration means a long-lived key sitting in a file that is easy to sync, back up or commit by accident — the tradeoff is worth reading in full before you choose, both on what OAuth buys over API key headers and on how MCP client config files become a credential exposure surface.

The inverse argument is real too: with a local server, the credential never leaves the machine and no tool call traverses a vendor’s infrastructure to be executed. If your policy is that vendor secrets are machine-bound, local answers it and remote does not.

One caveat against a tidy “remote means OAuth” rule: Cloudinary’s remote MediaFlows endpoint authenticates with cld-cloud-name, cld-api-key and cld-secret headers rather than OAuth, so that server puts a long-lived secret in a config file even in its hosted form (Cloudinary’s MCP server documentation, checked 2026-08-18). Check the specific server, not the category — the MediaFlows configuration details differ from the other four.

Who owns the update cadence

With a remote server, the vendor updates it. You get fixes without doing anything, and you also get changes without being asked. There is no version to pin and no way to hold last week’s behaviour through a release freeze.

With a local server, you own it. You can pin a version, test an upgrade against your own scripts, and roll a team forward on your schedule. You also own the consequence of nobody doing that: a team on a stale local build is running against a surface the vendor has moved on from, and the failure mode is a tool that quietly stops matching the documentation.

Neither is safer in general. Remote suits teams who want the current surface and have nothing that breaks when a tool description changes. Local suits teams with a change-control process that already covers dependencies, and who will actually run it.

Network egress

This is the one criterion that decides the question without reference to preference. An egress-restricted or air-gapped environment eliminates the remote option outright: a URL the machine cannot reach is not a configuration you can tune. There is no partial version of this — if the client cannot open an outbound connection to the vendor’s endpoint, the remote form is not on the table, and every argument about OAuth and update cadence is moot.

It is worth checking early, because it is cheap to check and it collapses the decision. Everything else on this page is a judgement call; this one is a fact about your network.

Which to pick when

Pick local if the machine cannot reach the vendor’s endpoint. Egress restrictions or an air gap end the discussion. Budget for the install and update burden, because you have just accepted it.

Pick local if a long-lived vendor credential must not leave the machine, or if you need to pin a version through a change freeze. Both are legitimate, both cost you distribution, and both assume someone owns keeping the package current.

Pick remote for everything else, and especially for any group larger than a couple of engineers. No runtime on the machine, OAuth instead of a pasted key on the four Cloudinary servers that support it, and the vendor carrying updates. This is the vendor’s own recommendation and the reasoning behind it holds: the install-and-update burden of the local form is paid per developer, forever, and buys you nothing in capability.

If you are still torn, the tie-breaker is not technical. Ask who will be running npm update on this in six months. If the answer is nobody, you want the remote server.