MCP transport: /mcp against the deprecated /sse path

What the two paths are

A Cloudinary remote MCP server answers on one HTTPS URL, and two path shapes are currently in circulation: /mcp, which speaks stateless Streamable HTTP, and /sse, the older Server-Sent Events path. Cloudinary’s MCP server documentation gives /mcp as the endpoint to use in new configurations, and the /sse path is deprecated for every server except one.

Endpoints as published, checked 2026-08-18:

Server	Endpoint	Note
Asset Management	https://asset-management.mcp.cloudinary.com/mcp	—
Environment Config	https://environment-config.mcp.cloudinary.com/mcp	—
Structured Metadata	https://structured-metadata.mcp.cloudinary.com/mcp	—
Analysis	https://analysis.mcp.cloudinary.com/sse	published at /sse, not /mcp
MediaFlows	https://mediaflows.mcp.cloudinary.com/v2/mcp	header auth, and a /v2/ segment

The remote servers authenticate over OAuth. MediaFlows is the exception on that axis too, taking cld-cloud-name, cld-api-key and cld-secret as headers — the practical differences are covered in configuring the MediaFlows MCP server and in OAuth against API key headers.

Streamable HTTP is the current HTTP transport

The MCP transports reference documents two transports: stdio, for a server spawned as a local subprocess, and Streamable HTTP, for a server reached over the network. Streamable HTTP replaced an earlier HTTP+SSE transport that needed two endpoints — a long-lived GET stream carrying server-to-client messages, and a separate POST endpoint for client-to-server messages, whose URL the client learned from the first event on the stream.

Streamable HTTP collapses that into a single endpoint. The client POSTs a JSON-RPC message; the server replies either with a JSON body or with an SSE stream on that same response, depending on whether it has one message to send or several. The long-lived GET stream still exists in the specification, but it is optional, and a server that only ever answers requests does not need it.

That is why the path name changed. /sse described the mechanism of a transport that no longer applies; /mcp is just the server’s endpoint.

Analysis is still published at /sse

Every Cloudinary remote server documented at /mcp moved; Analysis did not, and is published at https://analysis.mcp.cloudinary.com/sse. If you are generating client configuration from a list of server names, the endpoint is a per-server value to look up, not a suffix to append. A template that appends /mcp to every hostname produces a working config for four servers and a broken one for Analysis.

The deprecated path accepts POST as an alias

The /sse path accepts POST as an alias for /mcp. A client that sends Streamable HTTP to the old URL therefore gets a normal response rather than a 404 or a protocol error, and the connection behaves exactly as it would against the new path.

That is a deliberate compatibility choice and it does what it is meant to: nothing broke when the endpoints were renamed. The cost is that the deprecation is silent from the client’s side. There is no warning in the transcript, no failed tool call, no log line in the client that says the path is on its way out. The only thing that distinguishes a current config from a stale one is the string in the file — and the day the alias is withdrawn, every config still carrying the old string stops working at once, rather than degrading one at a time.

Stateless means there is no session to resume

The specification lets an HTTP server assign a session on initialize and return it in an Mcp-Session-Id header, which the client then echoes on every later request. It also lets a server attach event IDs to the SSE stream it sends, so a client that drops mid-stream can reconnect with Last-Event-ID and ask for the messages it missed. Both are optional.

Cloudinary’s remote servers are stateless, so neither applies. There is no session identifier to keep, nothing pinning a client to a particular server instance, and no resumption handshake. A dropped connection is handled by the client re-issuing its request; the server has no memory of the previous one and does not need to reconcile anything. Failure handling in the client reduces to a retry.

What statelessness gives up is server-initiated traffic between requests. Without a session the server has no addressable handle on a connected client, so anything it wants to say has to ride the response stream of a request the client made. For tool-calling — the client asks, the server answers — that is the whole interaction, which is why the trade is cheap here. It would not be cheap for a server that needed to push progress or notifications on its own schedule.

Statelessness also means the transport contributes nothing to context cost, but the tool definitions still do; that is a separate budget, and the context cost of leaving several MCP servers connected is where it shows up.

Configuration drift is the practical risk

The realistic failure is not a broken connection. It is a config copied out of a write-up published before the rename, working perfectly, and pointing at a path scheduled for removal. Because the alias answers, nothing in a test suite, a smoke check or a manual trial distinguishes it from a current config. The staleness is invisible until the alias is gone.

This compounds the way configuration usually does. MCP client config files get copied between machines, committed into dotfile repos, pasted into onboarding docs and templated across a team — the same files that also carry secrets, which is why they are a credential exposure surface in their own right. One stale URL propagates as far as the file does.

The check is mechanical: grep your MCP client configs for mcp.cloudinary.com/sse and confirm each hit is the Analysis server. Anything else is drift, and rewriting it to /mcp is a one-line change that costs nothing today.

What to look up next

• The endpoint list in Cloudinary’s MCP documentation, before writing any new config. It is the source of record for which servers sit at which path, and Analysis has already proved the list is not uniform.
• Whether a removal date for the /sse alias has been announced. Deprecated and removed are different states, and the alias currently works.
• Which specification revision your MCP client implements. A client that only speaks the older HTTP+SSE transport needs the old two-endpoint flow, not a path rename.
• Whether the integration you want is better served by a server at all — vendor-published skills against MCP servers covers the cases where the answer is no.