How to connect MCP servers to Claude Code, Cursor and other clients

What does “connecting an MCP server” actually mean?

Connecting a server means telling the client how to reach it. For a local stdio server, that is a command plus arguments and environment variables the client uses to spawn a process. For a remote server, it is a URL, plus authentication.

Once connected, the client lists the server’s tools and makes them available to the model. Nothing is installed into the model itself; if the client cannot start the process or reach the URL, the tools simply do not appear.

Every client follows the same idea but stores it differently, which is why copying a config from one tool into another often fails. The command, arguments and environment variables stay the same; only the file location and the top-level key change.

Before connecting anything, decide whether the server should be personal or shared with the team. That choice determines the scope or file you use and whether secrets must be kept out of the repository.

Where does each client store MCP configuration?

How to add MCP servers to Claude Code

• Add a local stdio server: claude mcp add filesystem -- npx -y @modelcontextprotocol/server-filesystem /absolute/path/to/folder
• Pass environment variables: claude mcp add github -e GITHUB_TOKEN=your_token -- <server command>
• Add a remote server over HTTP: claude mcp add --transport http <name> <https-url>
• Choose a scope with --scope: local (default, only you in this project), project (writes .mcp.json to share with the team) or user (all your projects).
• List configured servers: claude mcp list; inspect one: claude mcp get <name>; remove one: claude mcp remove <name>
• Inside a session, type /mcp to see connection status and to authenticate remote servers that use OAuth.
• Import servers you already set up in Claude Desktop with claude mcp add-from-claude-desktop (supported on macOS and WSL).

How to add MCP servers to Cursor and VS Code

• Cursor, project-level: create .cursor/mcp.json with { "mcpServers": { "name": { "command": "npx", "args": ["-y", "package-name"], "env": { "API_KEY": "..." } } } }
• Cursor, remote server: use { "url": "https://..." } instead of command and args for that entry.
• Open Cursor settings, find the MCP section and confirm the server shows as enabled with its tools listed.
• VS Code: create .vscode/mcp.json with a top-level servers object; each entry has type (stdio or http), plus command and args or a url.
• VS Code supports an inputs section that prompts for secrets at startup, so keys stay out of the committed file.
• Use agent mode in the chat view; MCP tools are available there, not in plain completions.

How to add MCP servers to Claude Desktop

• Open Settings, then Developer, then Edit Config to open claude_desktop_config.json.
• Add an entry under mcpServers with command, args and optional env, exactly like the Cursor format.
• Use absolute paths for both the command and any file arguments; the app does not start in your project folder.
• Fully quit and reopen the app; the tools indicator in the chat input should list your server’s tools.
• If it fails, read the MCP log files the app writes (their location is linked from the Developer settings).

Which scope should you use for a team?

Project scope is the right default for servers the whole team needs, such as a database or issue tracker server. Commit the config, but never the secrets: reference environment variables and let each developer supply their own values.

User scope suits personal helpers you want everywhere, like a notes or search server. Local scope is for experiments you do not want to share yet. Claude Code asks for approval before using project-scoped servers from a checked-in .mcp.json, which protects you from a malicious repository config.

The table shows the main pattern: Claude Code manages servers through its CLI, while most other clients read a JSON file. Knowing where each file lives saves a lot of guesswork when a server does not appear.

Troubleshooting: why is my MCP server not showing up?

• The command is not on the client’s PATH: GUI apps often do not inherit your shell PATH, so use absolute paths to node, npx, uv or python.
• The server writes to stdout: logs must go to stderr, otherwise the protocol stream breaks.
• Wrong JSON key: Cursor and Claude Desktop use mcpServers, VS Code uses servers.
• Missing environment variables: the client does not read your .bashrc; put required keys in the env block.
• Too many tools: dozens of servers bloat the tool list the model sees, which costs context and hurts tool choice; enable only what the task needs.
• Stale process: restart the client or reconnect via /mcp after changing a server’s code.

What should you check before connecting a third-party server?

An MCP server runs with your permissions. A stdio server can read files and use credentials you pass it, and tool outputs can contain prompt injection aimed at your agent.

Read the source or at least the package page, pin versions instead of always pulling latest, give tokens the minimum scope, and prefer official servers from the vendor behind the API. RepoLoot’s catalog notes the licence and maintenance signals of MCP projects, which helps with that first filter.

Start with a minimal, shared set: the project’s own tools such as a database or issue tracker server in project scope, and personal helpers in user scope. Resist adding every interesting server you read about.

Document the setup in the repository so a new teammate can reproduce it in minutes. A short section in the project instruction file listing each server, what it is for and which environment variables it needs saves repeated questions.

Review the list every few months. Remove servers nobody uses, update pinned versions and check whether an official server from the vendor has replaced a community one.

How do you verify a server works end to end?

After connecting, do not assume the model will use the tools. Ask a question that clearly needs one, then check that the call appears in the transcript with sensible arguments.

Run the same check in each client your team uses. Clients differ in how they present tools, ask for approval and handle resources or prompts, so a server that works in one may need small config changes in another.

• Confirm the server shows as connected in the client’s MCP view.
• Confirm the expected tool names are listed.
• Trigger one read-only tool call and inspect its arguments and output.
• Trigger a failing call on purpose and check the error message is readable.
• Record the working configuration in your project docs or instruction file.

Frequently asked questions

Where is the Claude Code MCP config file?

Servers added with local or user scope are stored in ~/.claude.json, while project-scoped servers live in a .mcp.json file at the project root that you can commit. Using the claude mcp add, list and remove commands is safer than editing these files by hand, and /mcp shows live status.

Can I use the same MCP server in Claude Code and Cursor at the same time?

Yes. Each client starts its own process for a stdio server, so they do not conflict, although two instances may compete for resources like a local database lock. Remote HTTP servers can be shared by many clients at once, subject to their own authentication and rate limits.

How do remote MCP servers authenticate?

Remote servers typically use OAuth, following the authorization flow described in the MCP specification. In Claude Code you add the server with its URL and then complete sign-in from the /mcp menu. Some servers instead accept an API key sent as a header, configured in the client’s settings.

How many MCP servers should I connect at once?

As few as the task needs. Every connected server adds tool names and schemas to the model’s context, which uses tokens and makes tool selection less reliable. Keep a small default set and enable specialised servers per project, using project scope for team-wide tools.