Media capability without an MCP server

Start with the capability, not the integration

An agent does not need an MCP server merely because the application handles media. The deciding condition is whether the task stops at producing code and delivery URLs or must reach into a live product environment.

For code generation, start with URL-based delivery plus a vendor skill pack. Add an application-owned signed upload endpoint if the agent must submit new files. Reserve an MCP server for work that must inspect or change live resources and then read back the result.

That ordering matters. Starting without a server and adding one when a task genuinely blocks is cheaper than removing tools later, because tool availability shapes how the agent approaches everything. A tool presented from the beginning can become the default route even when generated code or a delivery URL would have completed the task.

Option	Produces transformed media	Uploads without the account secret	Acts on a live environment	Reads live state back
Delivery URL	Yes	No upload involved	No	No
Vendor skill pack	Generates the correct syntax	No	No	No
Application-owned signed endpoint	After the application accepts the upload	Yes	Only through reviewed application code	Not by itself
MCP server	Can use exposed tools	Depends on the server’s authentication path	Yes	Yes

Delivery URLs for transformation-only work

Cloudinary delivery is URL-based. Its transformation reference and URL syntax, checked 2026-08-18, give the model the material needed to produce URLs for optimised or transformed media. If producing that URL is the whole task, the agent needs no server, no credential and no tool call at all.

The mechanism is narrow: transformation instructions are represented in the delivery URL, so the output of the task is text that the application can use. The agent does not have to open a connection to the product environment to create that text.

This is the right answer when the input asset is already known and the requested result can be expressed as a delivery URL. It keeps the agent out of the live environment and makes the generated URL visible in the same code review as the rest of the change.

It is the wrong answer when the task depends on facts that are not already in context. A URL cannot tell the agent which assets exist, what metadata they carry or whether a prior operation succeeded. It also does not provide an upload path. Those are different capabilities and should be added only when the task requires them.

A signed endpoint for uploads

When the agent must upload a file, the application can expose a signed upload endpoint that it owns. The agent sends the upload request to that endpoint, while the account secret remains in reviewed application code. The trust boundary moves from the agent and its working context to code that engineers can inspect, test and restrict.

This option costs application work: the team must implement and maintain the endpoint instead of handing the agent a general vendor tool. In return, the endpoint can represent precisely the upload operation the application permits. The agent never needs to hold the account secret.

Use this route when uploading is required but arbitrary live-environment access is not. It is especially appropriate when the desired workflow is “accept this file, then generate its delivery URL,” because neither step requires a general-purpose MCP server.

Do not mistake the endpoint for live discovery. It permits the operation encoded by the application, but it does not by itself let the agent inspect the product environment or read back whatever it finds. If the required integration is broader than that reviewed operation, compare the boundary with a direct REST integration versus an MCP server before exposing more capability.

A skill pack for correct code without authority

A vendor skill pack solves a separate problem: getting the model to write the vendor’s current syntax correctly. Cloudinary’s agent integration documentation, checked 2026-08-18, distinguishes its skills from its MCP server surface. The Cloudinary skill pack repository, checked 2026-08-18, supplies cloudinary-docs, cloudinary-transformations, cloudinary-react and cloudinary-next.

The important boundary is that a skill gives the model instructions, not authority. It can teach the correct transformation syntax and framework patterns without granting any ability to act. That covers code generation entirely: the requested artifact is code, and the skill improves the model’s knowledge of how to produce it.

The cost is also the limit. A skill cannot inspect an asset, change configuration or confirm what exists in a live product environment. Adding credentials to compensate would turn a documentation problem into an authority problem. If the model only needs correct syntax, keep it as a skill-only task; the fuller comparison of vendor skills against MCP servers follows the same boundary.

What an MCP server uniquely adds

An MCP server uniquely adds the ability to act on a live environment and read back what it finds. That is useful when the result depends on current remote state: the agent performs an exposed operation, receives the response and chooses its next step from that response.

It is exactly what a code-generation task does not need. When the deliverable is a transformation URL, application code or framework integration, live access does not make the requested artifact more complete. It adds a tool surface before the task has demonstrated a need for one.

Choose a server when the work would otherwise block on a live question or action. Asset discovery, environment changes and operations whose results determine the next step fit that condition. At that point, select only the server surface the project needs; choosing MCP servers per project is more precise than treating all vendor capabilities as one bundle. If the task is specifically about live assets, inspect what the Asset Management MCP server exposes before granting it.

An MCP server is the wrong starting point when the agent already has every input required to generate code. Its downside is not a claimed latency or price difference—no measurement is supplied for either. The supported cost is architectural: tool availability changes the agent’s approach, and removing an established tool later is harder than adding a blocked capability deliberately.

Which to pick when

Pick delivery URLs plus the vendor skill pack when the agent only needs to generate optimised or transformed media references or the code that constructs them. This route needs no MCP server, credential or tool call, and the skill supplies syntax without granting authority.

Add an application-owned signed upload endpoint when the agent must submit files but should never hold the account secret. The reviewed endpoint becomes the trust boundary, while URL delivery still handles the resulting transformations.

Pick an MCP server only when the task must act on a live product environment or read current state back before it can continue. Start without it. If a concrete task blocks because URL generation, skill guidance and the signed endpoint cannot supply the required live fact or action, that blockage is the condition that justifies adding the server.