MCP servers for Cursor: how to connect them without overloading context

MCP servers for Cursor turn the agent from a "code reader" into an assistant that reaches into your systems: a database, a task tracker, a browser. They are connected with a single JSON file, but convenience has a price: the descriptions of all tools land in the context. Below we cover how to connect an MCP server to Cursor, what types of servers there are, where to keep secrets and how to avoid inflating token spending. We rely on Cursor's MCP documentation; for the details of a specific server, consult its README.

What MCP is and why Cursor needs it

Model Context Protocol is an open protocol through which a program tells a model what tools (functions), data and prompt templates it has. Cursor acts as the client: it starts the server or connects to it, shows the model the list of tools, and when the model decides to call one, executes the call and returns the result. A general explanation is in the article MCP server: what it is and how to connect it in Claude Code↗.

It helps to understand how roles are split. The server itself runs on your side (or on a remote host), and the model you connected through Zukko sees only the text description of the tools and the results of calls. So MCP needs a model that can call tools. How your model handles calls, test on your own task.

Three types of servers

According to Cursor's documentation, three ways of connecting are supported:

A practical rule: if the server is installed as an npm or Python package and works with your local files, it is stdio. If it is an internet service (a tracker, documentation, a cloud database), the remote variant by URL is usually more convenient.

How to connect an MCP server to Cursor through mcp.json

The configuration lives in one of two places:

• .cursor/mcp.json in the project root: tools for that project only;
• ~/.cursor/mcp.json in your home directory: tools for all projects.

According to Cursor's help, both files are merged, and if a server with the same name appears in both, the project-level one takes priority. Do not commit a file with keys to git.

A local server (stdio)

{
  "mcpServers": {
    "my-server": {
      "command": "npx",
      "args": ["-y", "<server-package-from-its-README>"],
      "env": {
        "API_KEY": "${env:MY_SERVER_API_KEY}"
      }
    }
  }
}

Take the command and arguments from the specific server's README: we do not name packages so as not to suggest an outdated name. For stdio servers there is also an envFile field (a path to a .env file with variables).

A remote server (HTTP or SSE)

{
  "mcpServers": {
    "my-remote": {
      "url": "https://example.com/mcp",
      "headers": {
        "Authorization": "Bearer ${env:MY_SERVICE_TOKEN}"
      }
    }
  }
}

For OAuth servers Cursor supports browser sign-in; if the provider needs fixed client credentials, the config has an auth block with CLIENT_ID and optional CLIENT_SECRET and scopes. For details, go to the MCP page in Cursor's documentation.

Secrets through environment variables

In the values of command, args, env, url and headers, Cursor understands substitutions: ${env:NAME}, ${userHome}, ${workspaceFolder}. Do not write tokens directly in the file: set them in the environment and substitute through ${env:...}. This matters most for .cursor/mcp.json, which sits in the repository.

Checking and debugging

After you save the file, the server should appear in the Customize section (in Cursor's sidebar), where you can switch it on and off with a toggle. If the server did not start, open the Output panel (Cmd+Shift+U / Ctrl+Shift+U) and choose "MCP Logs" in the list: it shows startup, authorization and call errors.

If you use Cursor's console agent, the same servers are available to the commands agent mcp list and agent mcp list-tools <name>, and the --approve-mcps flag automatically approves all MCP servers. By default Cursor asks for permission before using an MCP tool, and it is worth leaving that on for anything that writes or deletes data.

How not to overload the context

Every connected server adds descriptions of its tools to the request: names, explanations, argument schemas. They are sent to the model on every call and billed as input tokens. The scale depends on the server, so do not guess; measure.

A calculation example (assumptions). Say three servers together provide 40 tools, and the descriptions take about 8,000 tokens. At 200 agent requests a week that is 200 × 8,000 = 1,600,000 input tokens. On claude-sonnet-5-5 (input $0.4 per 1M, prices as of October 18, 2026) that is 1.6 × $0.4 = $0.64 a week, and at the official input price of $2 per 1M it is $3.20. On claude-opus-5-5 ($0.8 per 1M): 1.6 × $0.8 = $1.28. For Claude in the OpenAI format that Cursor uses, the cache gives no discount: all input is billed at the input price. The figures are illustrative; to get your own, compare the spending on an identical task with and without the servers in the dashboard's "Usage" section. You can estimate the size of the descriptions in advance through POST /v1/messages/count_tokens.

How to keep this under control:

1. Connect only what you need. An extra server costs tokens on every request even if it was never called.
2. Spread servers across projects. Keep the database server in the .cursor/mcp.json of the project that has the database, not in the global file.
3. Switch off for a while. The toggle in Customize disables a server without deleting its setup: such a server does not load and does not appear in chat.
4. Limit permissions. Give a server tokens with the minimum rights needed and, where possible, read-only.
5. Check the source. An MCP server runs code and calls external services on your behalf: install only what you trust the author of, and review the code for critical integrations.
6. Set a spending ceiling. Create a separate Zukko key for Cursor and give it a daily and monthly limit; see key limits↗.

The Zukko key is connected in Cursor separately from MCP and does not affect the server configuration; how to do it is described in the Cursor documentation↗.

FAQ

Where is mcp.json in Cursor?

For a project it is .cursor/mcp.json in its root, for all projects ~/.cursor/mcp.json. Servers can also be installed from Cursor's Marketplace without editing the file by hand.

The server is connected but the model does not use it. Why?

Cursor calls MCP tools when it considers them suitable, and asks for confirmation. You can name the needed tool directly in your request. If tools cannot be invoked at all, check that the server is enabled and look at "MCP Logs". Tool calling itself depends on the model, so compare the behavior on another model from the list.

Does MCP work when I use my own key instead of a subscription?

MCP runs on the side of Cursor and your servers, while the model receives the tool descriptions and results. So switching the provider to a Zukko key does not turn it off. Check your Cursor plan's terms on using your own keys at cursor.com/pricing↗.

How does MCP in Cursor differ from MCP in Claude Code?

The principle is the same; the config files and commands differ. For Claude Code, see the article MCP servers in Claude Code↗.

Start with one server, measure the difference in spending and only then add the next. A key for Cursor is created on the API keys↗ page.