How to use MCP servers with Claude Desktop and Cursor

To use an MCP server, you add it to a config file for whichever client — Claude Desktop, Cursor, or another MCP-aware app — you want to run it in, then restart that app. The config tells the client what command starts the server (often npxplus a package name), any arguments it needs, and any environment variables like API keys. Get that right and a hammer or plug icon shows up in the app with the server's tools attached to it. This walks through both clients with a real, working example, plus the handful of things that reliably go wrong the first time.

What an MCP client actually does

Claude Desktop and Cursor are both examples of what the protocol calls an MCP host or client: an application that starts an MCP server as a subprocess (or connects to one over the network), and hands the model whatever tools that server exposes. The server itself doesn't know or care which client is running it — the same filesystem or database server works identically in Claude Desktop, Cursor, or any other compliant client, because the wire protocol between client and server is standardized. What differs between clients is just where you write the config that tells it to start. For the fuller picture of how the client, server and model fit together, see our explainer on the protocol itself; this post is only about the plumbing of getting a server running.

Adding a server to Claude Desktop

Claude Desktop keeps its MCP configuration in one JSON file, edited through the app rather than by hand-finding it (though you can open it directly too):

1. Open the Claude menu in your system menu bar and choose Settings….
2. Go to the Developer tab, then click Edit Config. This creates the file if it doesn't exist yet, or opens it if it does.
3. Add or edit the mcpServers block, save the file, then fully quit and restart Claude Desktop — it only reads this file on launch.

The file lives at a fixed, OS-specific path. Editing it directly (in a text editor) works exactly as well as using the Edit Config button:

• macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
• Windows: %APPDATA%\Claude\claude_desktop_config.json

Every server gets one entry inside mcpServers, keyed by whatever name you want to appear in the app. Inside that entry: command is the executable to run, args is an array of arguments passed to it, and an optional env object supplies environment variables the server needs at startup — API keys, tokens, that kind of thing.

Adding a server to Cursor

Cursor reads the same basic shape — an mcpServers object, one entry per server — but from a different file, and it gives you a choice of scope:

• .cursor/mcp.jsonin a project's root — applies only inside that project.
• ~/.cursor/mcp.json in your home directory — applies across every project you open.

You can create either file by hand, or add a server through Settings → Tools & MCP → New MCP Server, which writes the same JSON for you. For a local, command-based server the entry looks like the Claude Desktop one — command, args, optional env. For a remote server, Cursor accepts a urlfield instead of a command, since there's nothing to launch locally. Cursor supports both local (stdio) servers and remote servers over HTTP, so the same config file covers a locally-run tool and one hosted somewhere else — see remote vs. local MCP servers for how the trust and auth picture differs between the two.

A worked example: the reference filesystem server

The Model Context Protocol project publishes a small set of reference servers, and the filesystem one is the example used in the official quickstart. It exposes tools for reading, writing, listing and searching files inside directories you name explicitly. Here's the exact config, which drops into either client's file unchanged:

{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-filesystem",
        "/Users/yourname/Desktop",
        "/Users/yourname/Downloads"
      ]
    }
  }
}

Breaking that down: "filesystem"is just the label that shows up in the client's tool list — call it whatever you want. "command": "npx"runs the package through Node's package runner rather than requiring a separate install step. "-y" auto-confirms installing the package the first time it's run. "@modelcontextprotocol/server-filesystem" is the actual npm package. Everything after that in argsis passed straight to the server itself — in this server's case, the specific directories it's allowed to touch. Swap/Users/yourname/... for your actual home directory paths (or the Windows equivalent, C:\Users\yourname\Desktop, with backslashes doubled inside the JSON string).

That last point matters beyond this one server: the filesystem server only has access to the exact directories you list. Naming your whole home folder gives it read/write access to everything in it, including things you probably didn't mean to expose. Scope it the way you'd scope a permission grant to any other program — to what the task actually needs.

Claude Desktop vs. Cursor: the config mechanics compared

Before you paste that config in

A config block you find in a README, a forum post or a search result is, functionally, a request to run someone else's code with your file access, your API keys and your network connection. Copying it in blind is the MCP equivalent of piping a random shell script into bash. Before you save the file and restart the client, spend the two minutes it takes to check who actually maintains the server you're about to run: is it still maintained, does it declare a license, is the source public, does it ask for more access than the task needs, and can you tell who actually published it. Our practical vetting checklist walks through exactly those five checks, or look the server up directly in the Vouchity registryand let a Trust Score do it for you — every server we track gets one, computed from live GitHub and npm signals rather than a publisher's own description of itself.

Common setup problems

The server doesn't show up at all

This is almost always one of three things. First, you didn't restart — both clients read their config only at launch, so a saved file with the app still open does nothing. Second, the JSON has a syntax error — a missing comma or an unclosed brace will make the whole file fail to parse, silently dropping every server in it, not just the broken one. Third, the command itself isn't on your PATHthe way the client sees it — GUI apps on macOS in particular don't always inherit your shell's environment, so npx can resolve fine in a terminal and fail inside the app. Try running the exact command and argsfrom your config directly in a terminal first; if it errors there, it'll error identically inside the client.

"It worked in the terminal but not in the app"

This is usually a relative path where an absolute one is required. Point a server at ./data or ~/notes and it may resolve against whatever working directory the client happens to launch subprocesses from, not the one you were sitting in when you tested it manually. Use full, absolute paths in args — /Users/yourname/notes, not ~/notes or ../notes.

Environment variables aren't reaching the server

A server that needs an API key reads it from its own process environment, set through the envobject in its config entry — not from a variable you've exported in your shell. Setting BRAVE_API_KEY in .zshrcdoes nothing for a server launched by a GUI app that never sourced that file. Put the key directly in the config's env block instead.

Tool calls fail, or hang, after the server connects

Check the server's own log output before assuming it's a client bug. Claude Desktop writes per-server logs to ~/Library/Logs/Claude on macOS (or %APPDATA%\Claude\logson Windows) — the file named after your server usually shows the actual stderr from the process, which is where a missing dependency or a bad argument will surface. For a more general-purpose way to poke at a server's tools directly, outside any client, see our guide to MCP Inspector.

Once it's working

A connected server doesn't mean the model uses its tools blindly — both clients ask for your approval before a tool call that reads, writes or reaches out to the network actually executes, and that per-call check is worth reading rather than reflexively approving, especially for a server you just added. If you're trying to decide what to add in the first place rather than how, browse servers by category or the trust leaderboard for ones with strong maintenance and adoption signals, and if you end up building your own server rather than just installing one, what makes a server trustworthy covers what to get right before you publish it.