Structured Metadata MCP Server: Schema-Shaped Asset Data

What it is

The Structured Metadata MCP server is the one of Cloudinary’s five MCP servers that owns the metadata schema of a product environment: the typed fields attached to assets, the values those fields may hold, and the rules that make one field depend on another. An agent connected to it can build and change that schema by describing it, and the result is data that Cloudinary search can filter on.

Its published remote endpoint is https://structured-metadata.mcp.cloudinary.com/mcp. Like the other remote servers it authenticates with OAuth rather than pasted credentials, and access is included on every plan, Free included, per Cloudinary’s MCP server documentation (checked 2026-08-18). The other four servers — Asset Management, Environment Config, Analysis and MediaFlows — cover different ground; this one is narrow on purpose.

Typed fields rather than free-text tags

Structured metadata defines fields with a type, validation, and — for list-shaped fields — a controlled set of allowed values, as described in the structured metadata documentation. That is the property that separates it from tags. A tag is a free string, and free strings drift: one uploader writes hero, another hero-image, a third Hero, and a query for any one of them misses the other two. A structured field with a controlled value list refuses anything outside the list at write time, so the vocabulary cannot fork, and a date or number field rejects a value that does not parse as one.

The cost is that a schema has to exist before values can be written. Tags need no setup and are the right tool for genuinely open-ended labelling. Automatic tagging in particular emits tags, not structured metadata; if you are running automatic tagging through an MCP server, the output lands in the tag list, and mapping it onto a controlled field is a separate step you design, not something the tagger does for you.

What the server does

The server exposes the schema-side operations: create fields, set values, and define conditional rules. That is enough to build a metadata schema by describing it — a field for campaign with five allowed values, a field for region, a rights-expiry date — rather than by clicking through the settings screen field by field. The schema an agent creates this way is the same schema the console shows; the server is a different surface over the same product environment, not a parallel store. A worked pass through the process, from a plain-language description to a finished field set, is in defining a structured metadata schema through an MCP server.

Two things it does not do are worth stating plainly. It does not upload or transform assets — that is the Asset Management MCP server — and it does not run search on your behalf. It defines what is searchable.

Conditional rules

A conditional rule makes one field’s options depend on another field’s value. With a product-line field and a model field, a rule can restrict the models on offer to those belonging to the chosen product line, so whoever — or whatever — is setting values sees only the models that apply. This is the mechanism that keeps a large schema usable. Without it, a schema with a few hundred allowed values presents every option every time, and the controlled list stops controlling anything because the wrong value is as easy to pick as the right one.

Rules add coupling. Changing the allowed values of a parent field means revisiting every rule that keys off it, and a value removed from a parent can orphan the options a rule was gating. Keep the dependency graph shallow: one level of parent-to-child is easy to reason about; three levels is a settings screen nobody wants to debug.

External ID and display label are different things

Every field has an external ID and a display label. The external ID is what code, upload parameters and search expressions reference; the label is what a person sees in the console. Renaming the label is safe — nothing references it. Renaming the external ID is not: every search expression, every automation branch and every integration that named the field breaks at once, and it breaks silently, because a search for a field that no longer exists returns nothing rather than an error you notice.

The practical rule is to choose external IDs as though they were permanent and to treat labels as free. If the label Campaign (2026) needs to become Campaign, change it; the external ID campaign stays. When an agent creates a field from a description, check the external ID it chose before anything references it, because that is the last moment a rename is cheap.

Queryable through search expressions

Metadata defined here is queryable through the expressions accepted by the search method, referencing fields by external ID. That is what turns structured metadata from documentation into something an automation can branch on. A field that only shows in the console describes an asset; a field a search expression can filter — every asset whose rights-expiry date has passed, every asset in region emea with campaign spring — is a condition a workflow can act on: pull the assets, tag them, move them, delete them.

This is also why the typed-field property matters downstream. A search over a controlled value list returns exactly the assets that carry that value, because there was no way to write a near-synonym. A search over tags returns the assets that happen to spell the tag the way the query did.

What to check next

• The server’s tool list, and any change to it, is in the MCP documentation. The agent surface has changed on a monthly cadence; the facts here were checked 2026-08-18.
• If the server’s field operations count against the Admin API, the Free plan’s cap of 500 Admin API requests per hour (pricing page, checked 2026-08-18) bounds how fast a large schema can be built. The documentation, not this page, is where to confirm which calls count.
• Schema changes made by an agent are as durable as any other, so knowing what was created and renamed matters; seeing what an agent actually did through an MCP server covers how to reconstruct that.
• Structured metadata is a feature of the Image & Video API product environment. Cloudinary’s Assets (DAM) product is purchased separately, and an API plan does not raise DAM limits (pricing page, checked 2026-08-18).