How to add MCP servers to Cursor

To add an MCP server to Cursor, create .cursor/mcp.json in your project, or ~/.cursor/mcp.json for every project, and add the server under mcpServers. A remote server needs a url. A local server needs the command that starts it. Cursor signs in to servers that use OAuth and asks before it runs each tool.

MCP, the Model Context Protocol, is how Cursor’s agent calls tools outside your editor: a database, an issue tracker, your production logs. The steps below follow Cursor’s MCP documentation.

1. Pick project or global config

Cursor reads two files:

Start with the project file for anything the whole team needs. Keep personal accounts in the global file, so a teammate’s checkout never tries to sign in as you.

2. Add a remote server

A remote server runs somewhere else and speaks Server-Sent Events or Streamable HTTP. It needs only a name and a url:

{
  "mcpServers": {
    "polylane": {
      "url": "https://mcp.polylane.com/mcp"
    }
  }
}

If the server uses OAuth, Cursor opens the sign-in flow the first time the agent needs it, and you approve access in the browser. Servers that take a static key instead accept headers:

{
  "mcpServers": {
    "internal-api": {
      "url": "https://mcp.example.com/mcp",
      "headers": {
        "Authorization": "Bearer ${env:INTERNAL_API_TOKEN}"
      }
    }
  }
}

3. Add a local server

A local server is a program Cursor starts on your machine and talks to over stdio. Give it the command, its args and any env it needs:

{
  "mcpServers": {
    "context7": {
      "command": "npx",
      "args": ["-y", "@upstash/context7-mcp"]
    }
  }
}

Everything in the file runs with your permissions, so only add servers you trust, from sources you can read.

4. Keep secrets out of the file

Cursor resolves variables in the command, args, env, url and headers fields. Use ${env:NAME} for anything secret, as in the remote example above, and the file you commit holds only the variable’s name. The same works in a local server’s env block. ${workspaceFolder} and ${userHome} are also available, which helps when a local server needs a path inside the repository.

5. Check it works, and decide what runs without asking

Open Customize in the sidebar to see each server, whether it connected, and the tools it offers. You can turn a server off there without removing it from mcp.json.

By default Cursor asks before it uses any MCP tool and shows the arguments it is about to send. Read them the first few times: it is the quickest way to learn what a server does. Once you trust a read-only tool, allowlist it so it runs without a prompt in Auto-review mode, and keep anything that writes behind the prompt.

What to connect first

The servers that pay off soonest give the agent context it cannot get from the code: the issue it is fixing, the database schema, and what the code is doing in production. Production is usually the gap. Cursor can read the function that failed, but not the logs, traces and deploys that show how it failed. Polylane brings that into Cursor through the single remote server shown in step 2, covering every cloud and observability tool you connect behind one sign-in.

Using Cursor? See how to give Cursor production context with Polylane.