Surviving Version Changes in a Hosted MCP Server

What surviving version changes in a hosted MCP server means

Surviving version changes in a hosted MCP server means keeping an integration working when the server it talks to is updated by someone else, on their schedule, without a redeploy on your side. A local MCP server changes when you change it; a remote one changes when the vendor does.

The server moves without the consumer doing anything

A hosted server updates in place. The tool names, argument schemas and transport that a project depended on yesterday can differ today, with no change to the client’s code or configuration. Two runs of the same script against the same URL are therefore not guaranteed to see the same tool surface. Cloudinary’s MCP servers documentation lists five remote servers with published endpoints; a client points at those URLs and receives whatever the current deployment offers. This is the trade you make for not running the server yourself, and it is why the transport, tool discovery and release-notes points below exist at all. If that trade is unwelcome for a given workload, the case for a direct REST integration instead is covered under an MCP server against a direct REST integration.

Versioned paths make change explicit

A versioned endpoint path turns a server change into a configuration edit. When the vendor publishes a new major version at a new path, the old path keeps its behaviour and the client keeps working until someone deliberately edits the URL. An unversioned endpoint moves underneath the client instead: the same URL serves the new behaviour the moment it deploys.

Cloudinary’s published endpoints show both shapes. MediaFlows is served at https://mediaflows.mcp.cloudinary.com/v2/mcp, with the version in the path; Asset Management, Environment Config and Structured Metadata are served at unversioned /mcp paths and Analysis at /sse. A project that depends on one of the unversioned servers has no path-level signal that anything changed. Configuration details for the versioned one are under configuring the MediaFlows MCP server.

A deprecated transport that still works is the most dangerous state

The protocol’s transports concept page describes Streamable HTTP as the current HTTP transport and the earlier HTTP+SSE transport as deprecated. A deprecated transport that has been switched off fails loudly and gets fixed. A deprecated transport that still accepts requests fails nobody, so working configurations keep being written against it, copied between projects, and committed. By the time the path is removed there is a population of clients that have never seen an error and have no reason to expect one.

Cloudinary’s Analysis server is published on an /sse endpoint while the other four are on /mcp. Whether a given endpoint’s transport is on a removal schedule is not stated in the documentation as checked on 2026-08-18; the practical position is to treat any SSE endpoint as one to watch and to know which transport each configured server is using. The two transports and their endpoint shapes are compared under MCP transport endpoints.

Assert the tools you expect at session start

MCP clients discover tools by listing them at connection time, which means a renamed or removed tool is normally discovered when a call to it fails partway through a run. The guard is to move that discovery to the front: after connecting, list the tools and check that every tool the project depends on is present with the argument names it expects, and stop before doing any work if one is missing. A rename then costs one failed startup rather than a half-completed batch of asset operations. This is a few lines in the client wrapper, not a framework, and it is the only check that runs on your schedule rather than the vendor’s. The tool lists to assert against are documented per server, for example under the Asset Management MCP server and the Environment Config MCP server.

Release notes are the only warning

A remote server gives no advance notice through the protocol itself; a client learns about a change by encountering it. The vendor’s release notes are the only channel that runs ahead of deployment. For Cloudinary that is the Programmable Media release notes, which is where MCP server changes, new Skills and transport changes would appear. Subscribing to that page, or diffing it on a schedule, is therefore part of the integration rather than optional reading, and belongs alongside the startup assertion: the assertion catches what release notes announced and nobody read.

What to check next

The endpoint list above was verified on 2026-08-18 and is volatile; recheck the MCP servers documentation before relying on a specific path or transport. Whether a project should be depending on several remote servers at all, given each one is an independent moving part, is the question addressed under choosing which MCP servers a project needs.