Choosing Which MCP Servers a Project Needs

Before you start

You need a written list of what the project does to media, in the vocabulary of operations rather than tools: uploads, tags, deletes, changes an upload preset, builds a delivery URL. If the list does not exist, write it first — the rest of this procedure is a mapping exercise and it fails without an input.

You also need to know what each candidate server exposes. Cloudinary publishes five: Asset Management, Environment Config, Structured Metadata, Analysis and MediaFlows, and access is included on every plan, Free included (checked 2026-08-18). Whether it is included is not the question; whether the project performs the operations it exposes is.

Steps

1. Write the operation list, then map operations to servers. Start from what the project performs, not from what is available. Under the protocol, each server advertises a set of tools the model may call, and the mapping is mechanical: an operation with no server behind it needs a server; an operation every server leaves untouched needs none. Done this way, most projects turn out to need exactly one — usually the Asset Management server, because upload, tag, search and delete are where the agent has to act on state it cannot reach any other way.

2. Check whether the answer is zero. A project that only delivers media — renders images and video that already exist, at sizes and crops the code decides — needs no server at all. Delivery URLs are plain URLs, and any code can build one from a public ID and a transformation string with no session and no tool call. Attaching a server to a delivery-only project buys nothing and costs on every turn; the no-server route is the correct answer, not a shortcut.

3. Treat the configuration server as a separate decision. Enable Environment Config only where configuration is genuinely being changed — presets, named transformations, environment-level settings. Its effects outlive the session that made them: a preset edited during a debugging conversation is still edited next week, for every upload that uses it. That persistence is what makes it useful and what makes it the wrong default. If the project reads configuration but never writes it, leave the Environment Config server out; if a one-off change is needed, enable it for that change and remove it after.

4. Count the cost of everything you leave enabled. An unnecessary server is not free because it is idle. Its tool descriptions are sent on every turn as context, and the protocol places no cap on how many tools a server may advertise, so the bill scales with the server, not with your use of it. The second cost is quieter: every extra tool is a plausible-but-wrong choice the model can make, and a metadata-field tool sitting next to an upload tool is one confusable name away from a wrong call. Two servers with overlapping verbs is where this bites first; if a server earns its place but exposes more than the project uses, restricting which tools it exposes recovers most of both costs.

5. Re-run steps 1–4 when the project’s phase changes. What a build needs and what a running system needs are different lists. During build, an agent may legitimately define metadata fields, set up presets and bulk-upload seed assets — three servers, briefly. In production the same project may upload user content and nothing else, or deliver only and need nothing. The set chosen on day one is a snapshot of day one; the review point is the phase boundary, not a calendar.

Done looks like

The project has a written operation list, each operation is mapped to a server or explicitly to none, and the enabled set is the smallest one that covers the list — for most projects, one server, and for delivery-only projects, none. Environment Config is enabled only where configuration is written. A note records which phase the set was chosen for, so the next phase change triggers the review rather than inheriting the list.