MCP Servers in Cursor: Setup and Differences

One protocol, different clients. Here is what Cursor does differently and what stays the same.

Where it is configured

The editor settings include an MCP section where servers are connected and their status is visible. Behind the interface is an ordinary config file that can be edited by hand.

There are two levels, as with other clients:

• User level, applying across all your projects.
• Project level, living in the repository and working for anyone who opens it.

As everywhere, secrets go in environment variables rather than the file. A project config with a token inside reaches everyone who clones the repository.

How it differs from a terminal agent

Lifecycle. The server lives with the editor. Close it and the process ends. A terminal agent behaves the same way, but sessions are usually shorter, and the difference shows on servers that are slow to start.

Where you see results. In the editor, tool calls appear in the chat interface, which is easier to observe. In a terminal you read text.

Automation. There is none: an editor does not run on a schedule or fit into CI. If the server is meant for background work, the client has to be a different one.

Permissions. The confirmation model in the editor is its own, and it is worth checking once what runs without asking. That matters most for servers with write access - see security.

What behaves identically

Practically everything else:

• The server itself. The same server connects to any compatible client with no changes.
• Tool selection. The agent chooses by description, and description quality matters more than the client.
• Context cost. Tool descriptions occupy space in every request regardless of client.
• The debugging order. Run it by hand, check stdout, check variables, restart the client - see setup.

Porting a configuration between clients

The entry format is similar but not identical: field names and file structure differ per client. Copying blindly usually ends with the client reading the file, failing to parse it, and silently running with no servers.

What to check when porting:

• The full path to the executable. Different clients launch processes in different environments, and PATH may differ.
• Environment variables. What was picked up in one client may not be in another. Set them explicitly in the server entry.
• The configuration level. User versus project: a server that “disappeared” is often defined somewhere other than where you are looking.

A practical rule: port one server at a time and verify each. Five servers added at once tell you nothing about which one broke.

Next

The general procedure is in how to connect an MCP server. Terminal-agent specifics are in MCP servers in Claude Code. The tools themselves are compared in Claude Code or Cursor. The overview is in the MCP guide.