The transformation rules file behind Cloudinary's MCP tools

What the rules file is

The Cloudinary transformation rules file is a published, machine-readable description of the transformation URL syntax: which parameters exist, what values each accepts, and which combinations are permitted in one chain. The transformation tools exposed through Cloudinary’s MCP servers generate URLs against that file, not against a model’s memory of the syntax.

URLs come from the file, not from recall

The most common way an agent produces a broken transformation URL is by recalling the syntax approximately: a parameter name that is nearly right, a value from an older version, a flag that belongs to a different parameter. When the tool consults the rules file instead, that class of error is removed at the point of generation. The model decides what it wants — crop to a square, deliver as AVIF, add an overlay — and the tool decides how that is spelled, from the file. That division is the reason the MCP transformation tools are more reliable than asking a model to write the URL string itself, and it is worth understanding before deciding whether a project needs the Asset Management MCP server or can get by without an MCP server at all.

It is a constraint set, so it fails early

Because the file is a constraint set rather than a reference document, it can be checked mechanically. A request for a combination the syntax does not allow fails inside the tool, with the tool reporting the conflict, instead of producing a well-formed-looking URL that returns an error when a browser or a crawler first fetches it. The difference matters operationally: a delivery-time error surfaces in production, on a page you may not be watching, whereas a generation-time failure surfaces in the agent’s transcript, where it can be corrected in the same turn.

It is versioned by the vendor

The rules file is maintained and versioned by Cloudinary. A consequence: the same prompt to the same tool can produce a different URL after the file is updated. When the underlying syntax has changed, that is exactly what you want — the tool tracks the current syntax without anyone editing a prompt. When nothing in your own code or prompts changed and the output moved anyway, it is surprising, and it is worth checking the rules file version before assuming a regression in your integration. Treat it as one more moving part in a hosted server, alongside the tool schemas themselves; the page on surviving version changes in a hosted MCP server covers the general case.

What the file does not say

The rules describe what is expressible, not what is sensible. A chain can pass every constraint in the file and still be expensive: many chained transformations against a large source, a video operation where an image one would do, a set of parameters that produces a new derived asset for every request. Nothing in the file marks a chain as costly, and the tool that consults it will not warn you. Cost judgement stays with the person or agent composing the request, and with the transformation reference, which documents what each parameter does rather than merely whether it is allowed. If a chain is used repeatedly it is usually better captured as a named transformation, which is a separate operation covered under creating and updating named transformations through an MCP server.

Reading it directly

The fastest way to answer “is this operation supported?” is to read the rules file, not to construct a test URL and fetch it. A test URL tells you whether one specific string works against one specific asset; the file tells you whether the parameter and its values exist at all, and what they may be combined with. For an engineer evaluating whether Cloudinary covers a case before wiring anything up, that is the shorter path, and it needs no product environment or credentials.

What to look up next

• The transformation reference, for what each parameter does and which values it accepts, once the rules file has told you it exists.
• The MCP documentation, for which servers expose transformation tools and how they authenticate — remote servers use OAuth, local ones need credentials (checked 2026-08-18).
• The current version of the rules file, whenever a URL changes with no change on your side.