MCP Servers: Marketplace Plugin or Hand Configuration

What each route actually does

A marketplace plugin, in Claude or Cursor, is a package the client installs after one consent prompt. For a vendor with several servers, that one step registers the MCP servers and the accompanying skills together, so a developer goes from nothing to a working toolset in about five minutes and never opens a config file. Cloudinary’s plugins are the concrete case: its MCP and skills documentation states that the Claude and Cursor marketplace plugins bundle a selected subset of what it publishes, and that they lag the source pack.

Hand configuration is writing the server entry yourself: the endpoint or launch command, the transport, the credentials, and any per-server options the client supports. The MCP specification defines what a client and server say to each other, not how a client is told about a server, so the file format and the available options are the client’s, and they differ between an IDE and a desktop assistant. If you are configuring the same servers in two clients, the details in MCP client differences between an IDE and a desktop assistant are the ones that bite.

Coverage: what you get

The plugin carries a curated subset. Cloudinary publishes five MCP servers (Asset Management, Environment Config, Structured Metadata, Analysis, MediaFlows) and a four-skill pack, but the plugin ships whichever of those its maintainers selected. A capability that exists upstream may simply not be present in the plugin, and nothing in the client tells you it is missing; you find out when the agent cannot do the thing.

Hand configuration has no such ceiling. Anything the vendor publishes an endpoint for, you can register. The cost is that you have to know the endpoint exists — the five Cloudinary remote endpoints are listed in the documentation above, and the MediaFlows one is different enough in shape that it has its own configuration walkthrough.

Currency: how fresh it is

Plugin bundles update on their own cadence and trail the source. For servers this is tolerable, because a server’s tool list is discovered live over the protocol; the plugin only registers the connection. For skills it is not, because a skill is content — the instructions are the product — and a stale skill is a stale product. Cloudinary’s skills repository is the source of truth; the four skills there (cloudinary-docs, cloudinary-transformations, cloudinary-react, cloudinary-next) are installed directly with npx skills add cloudinary-devs/skills, and a plugin may carry fewer or older versions of them.

Hand configuration points at the live endpoint or the current pack, so there is no intermediate bundle to lag. Whether skills should be part of your setup at all is a separate decision, covered in vendor-published agent skills against MCP servers.

Control: per-server options

This is the criterion the plugin cannot meet. Tool allowlists, header authentication and region selection are per-server settings, and hand configuration is the only route to them.

Tool allowlists. Restricting which of a server’s tools the agent may call is set on the server entry. A plugin registers the server as published, with everything it exposes.
Header authentication. Cloudinary’s four remote servers use OAuth, which a plugin can drive through the client’s consent flow. MediaFlows does not: its endpoint takes cld-cloud-name, cld-api-key and cld-secret as request headers, which means a hand-written entry holding those values. That also makes it the entry most likely to need separate credentials per environment.
Region selection. Pinning a server’s calls to a specific API region is likewise a per-entry setting; see routing MCP server calls to a specific API region for how that is expressed.

The cost of hand configuration is ownership. Someone on the team holds a config file that carries secrets, is per-client, and drifts when the vendor changes an endpoint. That is exactly the file the plugin exists to spare you.

They combine

The options are not exclusive. A client can hold plugin-registered servers and hand-written entries side by side. The working pattern is: install the plugin for the common path — the OAuth remote servers and whatever skills it bundles — then add one hand-configured entry for the server that needs options, whether that is a header-authenticated server, an allowlisted one, or one pinned to a region. You keep the five-minute setup for most of the surface and own config only for the piece that needs it.

One caution: if the plugin and your hand entry both register the same server, the agent sees two copies of its tools. Register a server one way or the other.

Which to pick when

Pick the marketplace plugin if you are evaluating, onboarding a team, or need the default servers and skills with no per-server settings, and you accept a subset that lags the source.
Pick hand configuration if any server needs a tool allowlist, header authentication or region selection, or if you need a capability the plugin omitted, or if skill freshness matters enough to install from the pack.
Pick both if the plugin covers most of your surface and one server needs options — the usual outcome for anyone running MediaFlows alongside the OAuth servers. Plugin for the common path, one hand-written entry for the exception, and no server registered twice.