Development Choices

Configure the MediaFlows MCP Server in a Client

Author
Joseph Trasatti Member of technical staff
Published
Section
MCP
Length
4 min read3 sources cited

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

  1. 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 /v2 is part of the URL, not something the client and server negotiate at connect time. A /mcp path with no version, or a copied /sse suffix 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.

  2. Set the three authentication headers. MediaFlows authenticates with cld-cloud-name, cld-api-key and cld-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.

  3. 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 the cld- 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.

  4. 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.

  5. 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.

  6. 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 /v3 is 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 /v2 connection 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

  1. Cloudinary's MediaFlows MCP reference cloudinary.com
  2. Cloudinary's MCP server overview cloudinary.com
  3. PowerFlows cloudinary.com

See also