Configure the MediaFlows MCP Server in a Client
MediaFlows connects over a versioned endpoint at https://mediaflows.mcp.cloudinary.com/v2/mcp and authenticates with three custom headers — cld-cloud-name, cld-api-key and cld-secret — instead of OAuth. Configure those in your MCP client, verify the server lists workflow tools, and treat every call as an edit to automation rather than to a single asset.
Before you start
You need three values from your Cloudinary product environment: the cloud name, an API key, and the matching API secret. These are the same credentials a server-side SDK uses, so treat them accordingly — the MediaFlows server takes them as plain headers, and your MCP client will store them in a config file on disk. If that file is synced, shared, or committed, the credentials go with it; see where MCP client config files leak credentials for the handling options.
Decide up front which product environment you are pointing at. This server does not read or write one asset — it creates and edits the automations that run against every future upload, so a mistaken call in the wrong environment changes behaviour for everything that lands afterwards, not for one file you can re-upload. A sandbox environment is the right target while you are learning the tool surface.
Also note what you are not doing here: MediaFlows is a remote server, so there is no local process to install, no Node version to pin, and no credentials sitting in a subprocess environment. That is the usual trade — see remote against local MCP servers for what you give up in exchange.
Steps
-
Point the client at the versioned endpoint. The server lives at
https://mediaflows.mcp.cloudinary.com/v2/mcp, documented in Cloudinary’s MediaFlows MCP reference. The/v2is part of the URL, not something the client and server negotiate at connect time. A/mcppath with no version, or a copied/ssesuffix from another integration, is a different endpoint — the transport path matters as much as the host, which is the same trap covered in Streamable HTTP against the deprecated SSE path. -
Set the three authentication headers. MediaFlows authenticates with
cld-cloud-name,cld-api-keyandcld-secret, not with OAuth. In a client that takes a headers map, that is three string entries alongside the URL. There is no browser consent step, no token refresh, and no revocation you can perform from the client side — rotating the API secret in Cloudinary is the revocation mechanism. The OAuth against API key headers comparison covers what that costs you operationally. -
Do not reuse a config block from another Cloudinary MCP server. The other servers — Asset Management, Environment Config, Structured Metadata, Analysis — take
cloudinary-prefixed headers and the remote ones use OAuth, per Cloudinary’s MCP server overview. MediaFlows uses thecld-prefix. The header names carry the same values under different keys, so a copied block looks correct in the file, connects at the transport layer, and then fails authentication. If you are debugging a MediaFlows connection that will not authenticate, check the prefix before you check the credentials. -
Restart the client and confirm the tool list. MCP clients read server config at startup; an edited file with no restart leaves the old connection in place. After the restart, the MediaFlows server should appear with its workflow tools available. If several other servers are already connected, this is the point to decide whether they all need to be — every enabled server’s tool definitions occupy the model’s context on every turn, which the context cost of enabled MCP servers covers in detail. You can also narrow what this server exposes; see restricting which tools an MCP server exposes.
-
Verify against the browser, not against the agent’s own report. The same MediaFlows backend drives a hosted Workflow Agent chat interface and the visual flow editor, alongside the prebuilt PowerFlows for jobs like moderation, UGC deletion and multilingual alt text. Because the browser UI and the MCP server operate on identical primitives, a flow your agent creates over MCP is visible and editable in the browser, and a flow a person builds by clicking is readable by the agent. Have the agent create something trivial and inconsequential, then open MediaFlows in a browser and look at it. That round trip is the only confirmation that the credentials resolved to the product environment you intended.
-
Record the endpoint version somewhere you will see it again. Because the version sits in the path rather than in a negotiated header, a future
/v3is a manual config edit on every machine and every client that holds this block. Nothing upgrades itself, and nothing warns you that a newer revision exists — the/v2connection keeps working until it does not. A line in the repo’s setup notes costs nothing now and saves a diagnosis later.
Result
The MediaFlows MCP server is connected over https://mediaflows.mcp.cloudinary.com/v2/mcp, authenticated by cld-cloud-name, cld-api-key and cld-secret, and its workflow tools are listed in your client. Automations your agent creates appear in the hosted Workflow Agent interface, and ones built there are readable by the agent. The endpoint version is pinned in your config and will stay on /v2 until you change it by hand.
Sources
- Cloudinary's MediaFlows MCP reference cloudinary.com
- Cloudinary's MCP server overview cloudinary.com
- PowerFlows cloudinary.com
See also
-
How to turn on cloudinary-embed-headers so every MCP tool result carries the rate-limit ceiling, remaining allowance, reset time and request ID.
-
Use the cloudinary-tools header to allowlist tools on a remote MCP connection: fewer definitions in context, better targeting, and server-side enforcement.
-
A skill is instruction text; an MCP server executes against a live account. How Cloudinary's four-skill pack and its MCP servers differ, and when to use each.
-
A vendor CLI against an MCP server for bulk asset operations: setup, determinism, per-item token cost, and the cases where each one is the right tool.