The Analysis MCP server: tagging, moderation, detection

What the Analysis MCP server is

The Analysis MCP server is one of Cloudinary’s five MCP servers, alongside Asset Management, Environment Config, Structured Metadata and MediaFlows. It exposes the analysis side of the platform — automatic tagging, content moderation, safety checks, object detection and recognition — as tools an agent can call against an individual asset. Access to MCP servers, this one included, is part of every plan, Free included, per Cloudinary’s pricing page as checked on 2026-08-18; what the analysis itself costs is a separate matter, covered below.

What it exposes

The server’s tools map onto Cloudinary’s analysis capabilities as documented in the Cloudinary MCP and LLM tooling overview: tagging that returns descriptive labels for an image, moderation and safety checks that flag content against a policy, and detection and recognition that locate or identify things within the frame. Each is invoked per asset. An agent that wants to tag a thousand images makes a thousand tool calls, and an agent that wants to both tag and moderate them makes two thousand — there is no batch tool on this server that takes a folder and returns a report. That shape is what makes the billing and write-back points below matter; it also means a long tagging loop is worth reading against what MCP tool results do to the context window before it runs unattended.

The underlying features are the same ones reachable through the REST API and the upload pipeline. The MCP server does not add new analysis; it makes existing analysis callable by an agent without a client library, which is the reason to use it. How the tagging output is kept usable once it comes back is its own subject, covered in running automatic tagging through an MCP server; driving moderation from an agent covers the moderation side.

Analysis is billed as add-ons, not credits

The Image & Video API bills in credits — one credit is 1,000 transformations, or 1 GB of storage, or 1 GB of bandwidth. Analysis features are not in that pool. They are add-ons, and per Cloudinary’s free-plan FAQ (checked 2026-08-18) add-ons bill separately from base-plan credits and appear as separate invoice lines; the Free plan reaches only the free tier of each add-on.

The practical consequence is that a loop which analyses every asset in a library has a cost curve of its own. Storage and bandwidth credits do not move when an agent tags ten thousand images; the add-on meter does. A library that fits comfortably inside a plan’s credit allowance can still exhaust an add-on’s free tier on the first pass, and the transformation-and-bandwidth rolling 30-day window does not describe add-on consumption. The details of each add-on’s tiers are on the AI content analysis add-on page; this site has not measured per-call costs and does not quote them.

What this means for an agent: any prompt or workflow that says “analyse everything” should be read as a spend instruction, and the number of assets it will touch should be known before it starts, not discovered on the invoice.

Detection returns confidence, not decisions

Detection and recognition results come back with confidence scores, not bare labels. A response does not say “this contains a car”; it says a car was detected at some confidence. Moderation is documented the same way in Cloudinary’s moderation documentation: a result is a score against a category, and the decision to approve or reject an asset is taken relative to a threshold.

Choosing that threshold is the actual work, and it is work the API cannot do. The service does not know whether a false positive costs you a support ticket or a false negative costs you a lawsuit, so it cannot tell you what confidence your use case tolerates. A stock-photo library tagging for search can afford loose thresholds and noisy tags; a user-generated-content moderation gate cannot. An agent that consumes detection results without an explicit threshold has, in effect, picked one silently — usually whatever the model happens to do with a number it was not told how to read. State the threshold in the workflow, keep it somewhere a human can revise, and expect to revise it after seeing real results.

The endpoint is on the SSE path

The published remote endpoints for Cloudinary’s MCP servers, from the MCP documentation as of 2026-08-18, are:

Server	Endpoint
Asset Management	https://asset-management.mcp.cloudinary.com/mcp
Environment Config	https://environment-config.mcp.cloudinary.com/mcp
Structured Metadata	https://structured-metadata.mcp.cloudinary.com/mcp
Analysis	https://analysis.mcp.cloudinary.com/sse
MediaFlows	https://mediaflows.mcp.cloudinary.com/v2/mcp

The Analysis server is the one still published on the /sse path rather than the /mcp path the others use. That is a transport difference, not a naming quirk: the SSE path is the older MCP transport, and a client configured for Streamable HTTP against /sse — or for SSE against /mcp — will fail to connect in ways that look like authentication or network problems. Before debugging an Analysis connection, confirm the client is speaking the transport the path implies. The distinction is laid out in MCP transport endpoints: Streamable HTTP against the deprecated SSE path. Whether Cloudinary moves this server to /mcp is unknown here; check the live docs page rather than this one if a connection that worked stops working.

The remote servers authenticate with OAuth; local servers need credentials supplied manually. MediaFlows is the exception, using header auth, and is covered separately in configuring the MediaFlows MCP server.

Write results back as structured metadata

An agent can consume analysis results inline — call the tool, read the tags or scores, act on them, and discard the response. That form is fine for a one-off question. It is the wrong form for anything asked more than once, because each time the question is asked the analysis is re-run: the add-on is billed again, latency is paid again, and the answer can drift between calls.

The durable form is to write the result onto the asset as structured metadata — tags, or a moderation status, or a detected-objects field — so that later queries read stored values instead of recomputing them. That is what the Structured Metadata MCP server exists for, and it is why the two servers are most useful together: Analysis produces the values once, Structured Metadata makes them a property of the asset, and every subsequent search, filter or agent step reads the field. Fields also survive a change of client or model, whereas an inline result lives only in the conversation that produced it. Which asset properties are readable and writable, and how the asset itself is addressed, is covered in the Asset Management MCP server and what it exposes.

The threshold decision from above belongs in this step, not before it. Store the raw score where the schema allows it, and derive the label from the threshold in the field that consumers read; then a threshold change is a re-derivation over stored scores rather than a re-analysis of the library.

What to check next

• The live MCP documentation for the current endpoint path, since the SSE/Streamable HTTP position could change without notice.
• Which of the server’s tools a given client actually needs; restricting which tools an MCP server exposes matters more here than elsewhere, because every exposed analysis tool is a billable call an agent can decide to make.
• Whether calls need to land in a specific API region, covered in routing MCP server calls to a specific API region.
• The add-on tiers for each analysis feature on the account in question, before any loop that touches the whole library.