Publish Sign in
Product 2 Aug 2026 · 3 min read

How to install an MCP server in Claude, Cursor, VS Code and Zed

One command per client, the exact file each one writes, how to tell whether it worked, and the five failures that account for most of the confusion.

MR mcprush team · The people who run the gateway

The install itself is one line. Installs go wrong because MCP clients share no config file, no schema and no reload behaviour — so the same server is a different three lines of JSON depending on what you are running, and a mistake in any of them produces the same symptom: the tools do not show up and nothing explains why.

One install, five destinations. The reload rule under each box is the part that costs people time.One install, five destinations. The reload rule under each box is the part that costs people time.
One install, five destinations. The reload rule under each box is the part that costs people time.

Underneath every one of those wrappers is the same small object: a name, a transport, an address, and — if the server authenticates with a key rather than through a broker — a header carrying it.

The entry itself. Three lines decide whether it works, and the third decides what a leak costs.The entry itself. Three lines decide whether it works, and the third decides what a leak costs.
The entry itself. Three lines decide whether it works, and the third decides what a leak costs.

The command

# the default client npx mcprush@latest add <server> # anything else npx mcprush@latest add <server> --client claude npx mcprush@latest add <server> --client cursor npx mcprush@latest add <server> --client vscode npx mcprush@latest add <server> --client zed
The flag decides which config file is written and nothing else.

If the server authenticates, a browser tab opens once. Where that token then lives is the question worth asking of any installer: on your disk, or with something that can revoke it for you later.

On a machine with no Node at all, two clients have their own commands, and they reach the same server:

claude mcp add --transport http <server> <url> code --add-mcp '{"name":"<server>","type":"http","url":"…"}'

What each client actually reads

ClientWhere the entry goesPicks it up
Claude CodeProject or user MCP configNext session
Claude Desktopclaude_desktop_config.jsonOnly on launch — quit and reopen
CursorIts own MCP settings fileWithout a restart
VS CodeWorkspace or user MCP configurationOn reload of the window
ZedThe context-server section of settingsOn save
Paths move when clients change. When this table and a client’s own documentation disagree, the client wins.

Checking it worked, from both sides

There are two views and they are frequently not the same. The account’s view is what the server thinks you have; the client’s view is what your editor thinks you have. When they disagree, the config file is the thing that is wrong.

Two views of one install. Only one of them is a file you edit by hand, and that is the one to suspect.Two views of one install. Only one of them is a file you edit by hand, and that is the one to suspect.
Two views of one install. Only one of them is a file you edit by hand, and that is the one to suspect.
npx mcprush@latest list # what the account holds, and what is paused npx mcprush@latest whoami # which account this key belongs to, and what it may reach

If list shows the server and your client does not, stop editing anything on the account side. If whoami fails, nothing downstream of it is worth debugging yet.

The five failures

Two commands split “it does not work” into three completely different problems.Two commands split “it does not work” into three completely different problems.
Two commands split “it does not work” into three completely different problems.
  • The client was never relaunched. Claude Desktop reads its config at launch. This is the most common report by a distance and it looks exactly like a broken install.
  • Two configs, one machine. A project-level file and a user-level file both exist, and the one you edited is not the one being read. Check both before changing either.
  • The key belongs to a machine you removed. An install belongs to an account, not to a laptop. A key from a device you deleted authenticates and then fails the second check — a 401 that is not about the key at all.
  • A trailing comma. Every one of these files is JSON, and a client that cannot parse its config usually says nothing whatsoever.
  • The OAuth tab was closed. The install completes, the grant does not, and the first call is what tells you.

Four of those five are a file, and the fifth is a browser tab. None of them is the server — which is worth remembering before you open an issue on somebody’s repository.

A note on claimed client support

Listings tend to claim every client there is, because the box is easy to tick and nothing checks it. Treat a client list as an aspiration rather than a test matrix. If you are on one of the less common clients and nobody in the reviews mentions it, assume you are the test.

Installing several at once

Two things do this and they are not the same. A stack is a curated set somebody assembled for a job. A list is your own saved set, which is what teams end up using.

npx mcprush@latest stack add <stack> npx mcprush@latest add-list <list>

Whatever the tool, demand one behaviour from anything that installs several things at once: it should install what is free and name what is paid, rather than quietly starting subscriptions on your behalf.