MCP clients: IDE assistant vs desktop assistant

The same server, two different clients

The Model Context Protocol specification defines what passes between a client and a server: how tools are listed, how a call is made, how a result comes back. It does not define where a client stores its configuration, how much of your working context the model can see, or when a human is asked before a tool runs. Those are client decisions, and they are where an IDE assistant and a desktop assistant part ways.

This page weighs the two against each other on five criteria that decide whether a given MCP setup works at all: configuration shape, repository context, tool approval, OAuth reach, and how servers get installed. The examples use Cloudinary’s servers because its documentation covers both kinds of client, but the differences apply to any vendor’s server.

Configuration: nested versus root

Both clients read a JSON file that names each server, its transport, and its credentials or endpoint. The shape differs. An IDE client nests every server under an mcpServers object; a desktop client may take the same entries at the root of its config file. The server definitions themselves are usually interchangeable — the endpoint for Cloudinary’s Asset Management server is https://asset-management.mcp.cloudinary.com/mcp regardless of which client you paste it into — but the wrapper around them is not.

The practical consequence: a config block copied from one client’s documentation into the other’s file fails silently or loudly depending on the client, and the failure looks like a broken server rather than a broken wrapper. When a server that works in one client refuses to appear in the other, check the nesting before checking the endpoint. Cloudinary’s MCP server and Skills documentation gives per-client snippets for this reason; take the snippet for the client you are actually configuring rather than adapting the other one. The MediaFlows server configuration is a worked example, including its header-based auth (cld-cloud-name, cld-api-key, cld-secret) which has to be expressed in each client’s own header syntax.

Standing: neither wins. The IDE’s nesting is one more level to get right; the desktop client’s flat file is easier to hand-edit but easier to corrupt when several servers are pasted in. The cost is a few minutes the first time and a confusing failure every time after that if you forget which file uses which shape.

Repository context: what the model can see

An IDE client has the repository open. When its model calls a tool — say, an upload through the Asset Management server, or a transformation lookup — it can read the code that will consume the result: the component that renders the URL, the schema the metadata has to match, the environment file the CLOUDINARY_URL lands in. The model can cross-reference the call against the consumer and notice when they disagree.

A desktop client is working from description alone. Everything the model knows about your code arrives because you typed or pasted it. It can still drive the same servers with the same tools, but it is reasoning about the call in isolation, and it will not notice that the public ID it just chose collides with a naming convention in a file it has never seen.

This is the mechanism behind the most common complaint about desktop assistants doing engineering work: the tool call succeeds, the result is correct in itself, and it is wrong for the codebase. It is also why the two clients suit different jobs. Managing assets, structured metadata, or a MediaFlows automation is description-driven work; the repository is not the point. Wiring an upload widget or a transformation chain into a Next.js app is repository work, and the four Skills in the cloudinary-devs/skills pack — cloudinary-docs, cloudinary-transformations, cloudinary-react, cloudinary-next — exist precisely to give an IDE assistant framework-specific guidance while it has that code open. Two of the four are useless to a desktop client that has no React or Next.js files to apply them to.

Standing: the IDE wins wherever the call’s output has a consumer in the repository. The desktop client is not worse at the protocol; it is blind to the consumer.

Tool approval: per call, per session, or not at all

Clients differ in when they ask a human before running a tool. Some prompt on every call, some once per session for a given tool or server, and some can be configured to run without prompting. This is not a convenience setting. It decides whether an unattended run is possible at all.

A client that prompts per call cannot complete a multi-step job with nobody watching; the run stalls at the first approval dialog. A client that approves per session can be started by a human and then left, provided every tool it will need was approved up front. Only a client that can be configured to skip approval for a named set of tools can be scheduled or triggered from a pipeline. Which of these a given IDE assistant or desktop assistant offers changes with releases, so check the current behaviour of the client you have rather than trusting a write-up — including this one.

The interaction with the previous criterion matters. A per-call prompt in the IDE is tolerable because the human is already there, looking at the code. The same prompt in a desktop client that you hoped to leave running overnight is the reason the job did not finish. If unattended is the goal, the choice of client is downstream of its approval model, and you may find that neither an IDE nor a desktop assistant is the right host — see running MCP-driven work in CI for what changes when the client is a container rather than a desktop.

Narrowing the tool set reduces how many approvals you need in either client. Restricting which tools an MCP server exposes is the lever: a client that only sees three tools asks about three tools.

Standing: for supervised work, either. For anything unattended, the client whose approval model can be relaxed for named tools — and that is a property of the specific client, not of the IDE-versus-desktop split.

OAuth: the client needs a browser it can reach

Cloudinary’s remote servers — Asset Management, Environment Config, Structured Metadata, and Analysis at their published mcp.cloudinary.com endpoints — authenticate with OAuth. Its local servers need credentials entered by hand, and the MediaFlows server takes headers. An OAuth flow needs a browser the client can open and get a callback from.

A desktop assistant has one: it is running on a machine with a browser, so the same server config that names a remote endpoint completes its login on first use. An IDE assistant on the same laptop also has one. The failure case is the IDE assistant, or the desktop client’s headless cousin, running inside a remote container, a devcontainer, or a CI runner. There is no browser to open, the callback has nowhere to land, and an identical config that worked on the desktop stalls at authentication.

The fix is not to fight the client. It is to choose the transport that fits the environment: OAuth-backed remote servers where a browser exists, credential-backed local servers or header auth where it does not. Remote versus local MCP servers covers that trade-off in full; the short version is that the browser requirement, not the client type, is what decides.

Standing: the desktop client wins by default because it always has a browser. The IDE wins or loses on where it runs.

Marketplace plugins: one step, one version behind

Cloudinary publishes marketplace plugins for Claude and Cursor. Each installs a curated subset of its MCP servers and Skills in one step. The cost is that the plugin bundles a selection, not the whole pack, and lags it: the skills pack is the source of truth, and the plugin catches up on its own schedule. A plugin can therefore be missing a server you need, or shipping a Skill that has since changed upstream.

The IDE client is where this bites hardest, because the IDE is where the Skills matter and where a stale cloudinary-next Skill quietly gives dated advice about code you are actively writing. The desktop client is less exposed — it mostly wants servers, and the server endpoints move rarely — but it is not immune, since a plugin might omit the server it needs. Marketplace plugin or manual install sets out when the one-step install is worth its lag; the shortest rule is that if you can name the server or Skill you need, install it directly with npx skills add cloudinary-devs/skills and the per-client config snippet, and use the plugin only when you cannot.

Standing: the plugin favours whoever wants a working setup in one step and does not care about the newest additions. Anyone depending on a specific server or Skill should configure by hand in either client.

Which to pick when

• Pick the IDE assistant if the tool call has a consumer in a repository — an upload the app will render, metadata a schema will validate, a transformation a component will build. The cross-referencing is the whole advantage, and it is where the React and Next.js Skills earn their place.
• Pick the desktop assistant if the work is description-driven — reorganising assets, running a MediaFlows automation, querying analysis results — and no code needs to agree with the outcome. It also authenticates OAuth-backed remote servers without ceremony.
• Pick neither, and go to CI, if the run must be unattended. First check the client’s approval model can be relaxed for the exact tools you need; if it cannot, no amount of choosing between IDE and desktop will let the job finish.
• Pick the desktop client, or an IDE on a local machine, if you are on OAuth-backed remote servers. In a container, switch the servers to credential or header auth rather than switching the client.
• Configure by hand in either client if you need a specific server or Skill; take the marketplace plugin only for a first setup where a lag against the upstream pack is acceptable.

The two clients are not competing implementations of the protocol. They are the same protocol placed in two different rooms, and the room decides.