RepoAI
Browse MCPs

How to install an MCP server

Installing an MCP server is really just editing a config file. You add a short JSON entry naming the command that starts the server, restart your AI client, and the tools it provides show up. There is no installer and usually nothing to download in advance — most servers are fetched on first run.

Not sure what one is yet? Start here.

The five steps

  1. Check what the server needs

    Almost every server that touches a real service wants credentials — an API key, a token, a database URL — and some want a path to a folder it's allowed to read. Have those ready before you edit anything, because a server that starts without them usually fails silently.

  2. Find your client's config file

    Each AI client keeps its MCP servers in its own JSON file, in its own location. The file may not exist yet; creating it is fine.

  3. Add the server entry

    Inside that file, servers live under a single key — mcpServers for most clients, servers for VS Code — with one entry per server naming the command to run and any arguments and environment variables it needs.

  4. Restart the client

    Config files are read at startup, so nothing appears until you fully restart (or reload) the application. This is the step people skip.

  5. Confirm it connected

    Ask the assistant what tools it has, or look for the server in your client's MCP or tools panel. If the tools you expected aren't listed, the server failed to start rather than connecting silently.

Where each client keeps its config

Claude Desktop
~/Library/Application Support/Claude/claude_desktop_config.json on macOS, or %APPDATA%\Claude\claude_desktop_config.json on Windows. Servers go under "mcpServers". Fully quit and reopen the app afterwards.
Cursor
.cursor/mcp.json for one project, or ~/.cursor/mcp.json to make the server available everywhere. Servers go under "mcpServers". Reload Cursor afterwards.
VS Code
.vscode/mcp.json in your workspace, or the "MCP: Open User Configuration" command for a global file. VS Code is the odd one out: its entries sit under "servers", not "mcpServers".
Windsurf
~/.codeium/windsurf/mcp_config.json. Servers go under "mcpServers". Reload Windsurf afterwards.

What the entry looks like

{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem", "/Users/you/projects"],
      "env": {
        "API_KEY": "your-key-here"
      }
    }
  }
}

command is the program that starts the server and args are what gets passed to it — here, npx fetching a package and being told which folder it may read. env holds secrets and settings the server reads from its environment. Only include env if the server actually asks for it.

That config file ends up holding live credentials in plain text. Keep it out of any repository you commit, and prefer a token scoped to only what the server needs over one that can do everything your account can.

Every server in this directory has its config generated for you, with safe defaults already applied — no hand-editing the JSON:

When it doesn't work

Nothing appeared after restarting
Usually invalid JSON — a trailing comma or a missing brace makes the client discard the whole file, not just the bad entry. Paste it into any JSON validator before assuming the server is at fault.
The server is listed but its tools fail
Typically a missing or wrong credential, or a path the server isn't allowed to read. Client logs are the fastest way to see the real error — a server writes its complaints to standard error, and clients surface that in their MCP logs.
"command not found"
The client couldn't find the program named in command. For npx-based servers that means Node isn't installed or isn't on the PATH the app sees, which can differ from your terminal's.
It worked yesterday and doesn't today
Servers fetched with npx pull the latest published version each run, so an upstream release can change behaviour under you. Pinning a version in args removes that surprise.

Before you add one

An MCP server runs with the access you give it, so it's worth a moment's thought about which ones you trust. What to check before installing a server covers the real risks, and every server here carries a security score.

Frequently asked questions

›Do you need to download an MCP server first?

Usually not. Most published servers are fetched on first run by the command in your config — npx for Node servers, uvx for Python ones — so the config entry is the whole installation. Servers distributed as a binary or run from source are the exception and say so in their README.

›Can you run several MCP servers at once?

Yes. Each one is a separate entry under the same key in the config file, and the client opens an independent connection per server. The practical limit is context, not the protocol: every server's tools are described to the model, so a dozen large servers crowd out room for your actual conversation.

›Can the same server be used in two different clients?

Yes — MCP is a shared protocol, so the same server works anywhere that speaks it. Each client keeps its own config file, so you add the entry once per client, and each runs its own copy of the server.

›How do you remove an MCP server?

Delete its entry from the config file and restart the client. Nothing is installed system-wide for the common npx and uvx servers, though a package cache may still hold the downloaded copy.

›Where do API keys go, and is that safe?

They go in the env block of the server's config entry, in plain text. Treat that file like any other secrets file: never commit it, and give the server a token scoped to the minimum it needs rather than one with full account access.