Agent skills against MCP servers for one integration

Two different artifacts that arrive through the same door

A vendor-published skill is instruction text. It ships as markdown, it is loaded into the model’s context when the subject comes up, and it steers the model toward the patterns the vendor considers correct — the transformation syntax that actually works, the SDK helper instead of a hand-built URL, the framework component with the right defaults. It executes nothing. Everything it produces is a token the model then has to act on.

An MCP server is an execution surface. It advertises tools over the Model Context Protocol, and the model calls those tools to perform operations against a live account: upload an asset, read back a delivery URL, edit structured metadata. The protocol specification defines how those tool definitions are advertised and invoked; what a given server exposes is the vendor’s decision.

Cloudinary ships both, and treats them as complementary rather than as alternatives. The skill states the practice, and the model then decides which MCP tools to call to carry it out. As of 2026-08-18 the Cloudinary MCP and Skills documentation lists five MCP servers — Asset Management, Environment Config, Structured Metadata, Analysis and MediaFlows — alongside the skill pack, and MCP server access is included on every plan, Free included ( https://cloudinary.com/pricing , checked 2026-08-18).

That leaves a real decision only at the margins: what to install when you cannot or do not want to install both.

The comparison, criterion by criterion

	Vendor skill	MCP server
What it does	States the correct pattern	Performs the operation
Context cost	Per relevant turn, while the subject is live	Per tool definition, from the moment it is connected
Credentials	None	An authenticated connection is required
Distribution	One npx command, four skills today	Per-server configuration in the client
Fails by	Writing plausible code it cannot verify	Calling the right tools in the wrong order

Context cost

Both cost context, but on different schedules, and that is the difference that decides most installations.

A skill costs context on every turn where it is relevant. Its text enters the conversation and stays there for as long as the subject does. The cost scales with how often the topic comes up, not with how many skills you installed.

An MCP server costs context per tool definition, and it pays that cost from the moment the connection is live — whether or not a single tool is called. Every name, description and parameter schema the server advertises is sitting in the window. Connect several servers and the definitions accumulate, which is why the context cost of leaving several MCP servers connected at once is worth measuring before you enable all five, and why restricting which tools a server exposes is the usual mitigation.

The practical asymmetry: an unused skill is nearly free, an unused server is not.

Credentials

A skill carries no credentials. It is text in a repository. Installing one grants no access to anything, which is why a skill pack is an easy thing to add to a shared development environment or to CI.

An MCP server requires an authenticated connection. Cloudinary’s remote servers use OAuth and its local servers need manual credentials ( https://cloudinary.com/documentation/cloudinary_llm_mcp , checked 2026-08-18) — a distinction that also drives the remote versus local server choice and the OAuth against API-key-header decision. Whichever you pick, connecting a server means the model can now change things in a real product environment. That is the entire point of it, and also the reason it is not the thing you hand to every contributor by default.

Distribution and drift

The Cloudinary skill pack installs through a single command, npx skills add cloudinary-devs/skills, and currently holds four skills: cloudinary-docs, cloudinary-transformations, cloudinary-react and cloudinary-next (checked 2026-08-18). The skills repository is where that set is maintained, and it is the version that moves first.

Marketplace plugin bundles for Claude and Cursor carry a selected subset and lag the pack. If you install through a marketplace, you get fewer skills and older ones. cloudinary-next is the concrete example: it exists in the pack, and write-ups from a few months ago describe three skills because that was true when they were written. Installing from the pack is one command and removes the drift; installing from a marketplace is one click and does not.

MCP servers have no equivalent packaged bundle — each is configured in the client individually, by endpoint, as with the MediaFlows server configuration. That is more setup per server, but it also means what you connected is what you get, with no subset silently chosen for you.

How each one fails on its own

A skill without a server writes plausible code it cannot verify. The model produces a transformation chain that matches the documented pattern, and nothing in the loop confirms the asset exists, the preset is configured, or the URL returns anything. Plausible-and-wrong is the expensive failure here, because it looks finished.

A server without a skill exposes tools the model calls in the wrong order. The tools are individually correct and the sequence is not: metadata written before the asset lands, an environment queried before it is configured, an operation repeated because the model did not know the first call was sufficient. Tool descriptions describe one call each; they do not describe the practice that connects them.

This is the reason the two are shipped together rather than as competing integration styles. They fail in complementary ways, and each one’s failure is the other’s job.

Which to pick when

Pick the skill pack alone if the work is code that lands in a repository and no live account is in the loop. Contributors get correct patterns with no credentials distributed and no tool definitions parked in the context window. This is also the right answer for CI and for shared or untrusted environments, where handing out an authenticated connection is the part you would regret.

Pick an MCP server alone if an agent is operating on assets in an account and generating no code — moderation passes, metadata edits, bulk operations against an existing product environment. Connect only the servers that specific job needs, narrow the exposed tools, and accept that you will occasionally correct the ordering by hand.

Install both when the model is writing code that touches a real product environment. That is the case the pairing was designed for: the skill supplies the pattern, the server verifies the result against something real. If context is tight, drop servers before you drop skills — an idle server is charging you for tool definitions you are not calling, while a skill only bills when its subject is on the table.

One caveat that applies whichever way you go: install skills from the pack, not from a marketplace bundle, unless you have checked that the bundle currently carries the skills you need.