Routing MCP Server Calls to a Specific API Region

What region routing on an MCP connection is

A cloudinary-region header on the connection to a Cloudinary MCP server selects which API region that server talks to. It matters when the product environment being worked on does not live in the default region, and it is worth knowing before the first tool call rather than after, because the failure it prevents is quiet.

The header selects a region for the connection

Cloudinary’s MCP server documentation describes the connection to each of its servers as a set of headers supplied by the client. cloudinary-region is one of them, and its value tells the server which regional API endpoint to address. A product environment provisioned outside the default region needs the header set to match, or the server’s calls go to the default region regardless of where the environment lives.

The Model Context Protocol specification leaves this to the server: it defines how a client and server exchange tool calls, not how a server picks an upstream endpoint. Region is therefore vendor configuration carried on the transport, not part of the protocol, and it will not appear in any tool’s input schema. Read the connection config, not the tool list, to find it.

Selection is per connection, not per call

The header is read when the connection is established and applies to every tool call made over it. There is no per-call region argument. A client that needs to work against product environments in two regions needs two configured servers, one per region, each with its own header set. One entry cannot address both.

That is the same shape as credentials: an MCP server entry binds one set of headers to one connection, so a client working across a development environment and a production one already runs two entries. The pattern is covered on keeping MCP credentials separate across environments, and region follows it exactly. If two environments differ in region, they cannot share an entry even if they could share everything else.

A wrong region does not fail loudly

This is the property that makes the header worth a page. Getting the region wrong does not produce an error. Calls succeed against the wrong regional endpoint and return results for an environment that is not the one being worked on. A list of assets comes back, a search returns hits, an upload reports success — all of it real, none of it against the intended environment.

The Admin API reference is the surface the server is ultimately calling on the reader’s behalf, and its responses do not carry a warning that the caller may have meant a different region. So a session that reports everything working, but shows an asset count or folder tree that does not match what the reader expects, should have its region header checked before anything else. The general procedure for diagnosing a tool call that returns the wrong thing applies, with the addition that a successful wrong answer is the signature here rather than a failure.

The header travels with copied config

cloudinary-region sits alongside the credential headers in the same connection block. A config copied from one project into another therefore carries the region with it, silently. Combined with the point above, this is how the wrong region usually arrives: not by someone typing the wrong value, but by someone reusing a working block from a project whose environment lives elsewhere.

When copying an entry, treat the region as one more field to change along with the credentials, not as boilerplate. Configs that authenticate with OAuth rather than API key headers still carry the region as a header, so the OAuth path does not remove this step.

Region is not data residency

Setting the header routes calls. It does not, by itself, satisfy a data residency requirement. Residency is a property of the product environment — where it was provisioned and where its assets are stored — and the header only tells the server which endpoint to talk to. Pointing a connection at a given region does not move an environment there, and an environment provisioned in the right region is reachable from a client anywhere as long as the header matches.

So a residency commitment is met at environment creation and confirmed in the environment’s own settings, and the header is then set to agree with it. The header cannot be used as evidence that a residency requirement is being honoured; only the environment’s location can. If a project has such a requirement, verify the environment first and configure the connection second.

What to check next

• The connection block for each configured Cloudinary MCP server, confirming cloudinary-region matches the region of the product environment named in the same block.
• Which transport the client is using for that connection, since the header is supplied on the transport — see Streamable HTTP against the deprecated SSE path.
• The product environment’s own region and residency settings, in the Cloudinary console rather than in the client config, if residency is a requirement.