Best MCP Servers for Cursor in 2026

Most lists of MCP servers for Cursor are a pile of links. They tell you what exists, not what you need, and if you install everything on them Cursor gets slower and less accurate rather than more capable.

So this is organised by job. There are five things an MCP server is genuinely worth adding to Cursor for, and the fifth one, letting the agent call real third-party APIs, is where the most time gets lost.

How Cursor loads MCP servers

Cursor reads its MCP configuration from ~/.cursor/mcp.json for servers available everywhere, or from a .cursor/mcp.json inside a project for servers scoped to that repository.

You rarely need to write that file by hand. If you are adding Swytchcode, one command does it:

npm install -g swytchcode
swy login
swy init --editor=cursor

That creates the .swytchcode/ project folder and updates ~/.cursor/mcp.json so Cursor can start the server. Restart Cursor, open Settings and confirm the server is listed and its tools are enabled. The full command reference is in the MCP docs, and there is a longer walkthrough in the MCP server setup guide.

By default the server runs over stdio, which needs no token. If you would rather run it over HTTP:

swy mcp serve --transport http --port 5476

That binds to http://127.0.0.1:5476/sse and is localhost-only. HTTP mode needs a bearer token, which lives at ~/.swytchcode/mcp_token:

swy mcp token            # print it
swy mcp token --rotate   # invalidate and reissue

The five jobs

1. Files outside the workspace

Cursor already reads your open project. An MCP filesystem server is for the directories it cannot see: a sibling repository, a notes folder, a design spec living somewhere else. Useful, low risk, and the first thing most people add.

Scope it to specific directories rather than your home folder. An agent that can read everything will eventually read something you did not mean to put in a prompt.

2. Version control beyond the current repo

Reading issues, pull requests and CI status without leaving the editor. This is where a lot of the real value of MCP in Cursor sits, because the context the agent is missing is usually in a pull request rather than in the code.

Be careful about write access here. "Read issues" and "close issues" are very different permissions, and agents are enthusiastic.

3. A browser

For anything the model needs to see rendered: checking a page it just changed, reading documentation that does not exist as a file, reproducing a UI bug. The trade is speed, since browser servers are slow compared with everything else on this list.

4. A database or warehouse

Letting the agent read your schema rather than guess at it removes an entire class of wrong code. Give it a read-only role. Not a role you believe is read-only, one that is read-only in the database.

5. Third-party API execution

This is the one people set up last and regret setting up last.

At some point you want Cursor to actually do something: file a Stripe refund, post to Slack, create a Jira ticket, add a HubSpot contact. The obvious route is to let the agent write fetch calls with a token from your environment. That works exactly once, and then produces the failures the rest of this post is about.

The problem with installing a dozen servers

Here is the thing the listicles do not mention. Every MCP server you add loads its tool definitions into the model's context before Cursor has done anything at all.

Ten servers with twenty tools each is two hundred tool definitions, each with a name, a description and a parameter schema. That is a large, permanent tax on every request. Worse, it degrades tool selection: the more similar-sounding tools the model can see, the more often it picks the wrong one. We wrote about that failure mode in Claude tool use picks the wrong tool, and it applies equally to Cursor.

So the useful instinct is the opposite of collecting. Add the fewest servers that cover the five jobs, and prefer servers that expose a small number of tools over servers that expose one tool per endpoint.

This is why Swytchcode's MCP server exposes 7 tools, not 363. The default agent profile gives Cursor discover, info, exec, list, search, add and a read-only policy. Those seven tools reach every one of the 363 integrations in the catalog. Adding a tenth provider does not add a tenth set of tool definitions, so your context cost stays flat while your coverage grows.

There is a second full profile with 15 tools, adding init, bootstrap, version, get, doctor, policy_check, policy_add and policy_remove. Use it while you are setting things up and switch back:

swy mcp serve --profile agent   # default, for day-to-day work
swy mcp serve --profile full    # while building

Why API execution needs more than a server

Giving Cursor the ability to call Stripe is not the same as giving it the ability to call Stripe safely. Four things have to be true, and an MCP server on its own provides none of them.

The arguments have to be checked against the real schema. Coding agents invent parameter names with great confidence. It is the single most common reason a call fails, and the failure is usually an opaque 400 that the model then tries to debug by guessing again. We covered the loop in why Cursor writes outdated API calls and the diagnosis in a 400 with no error message.

A retry must not become a second write. If a call times out after the provider accepted it, retrying without an idempotency key sends a brand new request. One refund becomes two. See idempotency explained.

Some operations need a gate. An allow list stops unknown methods. It does not stop an allowed method being used badly, which is what policy-as-code is for.

You need a record. Written by whatever sent the request, not by the model describing what it meant to do. Logging every API call an agent makes lists the fields.

Setting up the fifth job properly

The whole thing, start to finish. Note there is no .env file anywhere in this:

swy init --editor=cursor

swy get stripe                       # pull the integration
swy discover "refund a charge"       # find the operation by description
swy info stripe.refund.create3       # see the real inputs and outputs
swy add method stripe.refund.create3 # allow exactly this one
swy auth connect stripe              # store the credential

swy add method is the step that matters most and the one people skip. Only methods listed in your project can run. If Cursor asks for an operation you never added, the call fails at the runtime instead of reaching Stripe.

Credentials go into ~/.swytchcode/credentials.db, a local store outside your project folder, and the model never sees them. That is the argument in credential brokering for AI agents.

Then add a guardrail before you point this at anything real:

{
  "id": "big-refunds",
  "target": ["stripe.refund.create3"],
  "when": { "field": "amount", "operator": ">", "value": 50000 },
  "action": {
    "type": "REQUIRES_APPROVAL",
    "message": "Refunds over 500.00 need approval"
  },
  "approval_timeout": "2h"
}

And check what actually happened:

swy audit network   # what ran
swy audit policy    # what was blocked
swy mcp status      # is the server healthy

A sane default setup

If you want a starting point rather than a menu:

Five servers, not fifteen. If you find yourself above about six, check whether the newest ones are earning their place in the context window.

Keep production separate from your laptop

One last thing worth doing on day one. Run your Cursor project in sandbox mode until you have watched the audit output for a week:

swy init --mode=sandbox --editor=cursor

Mode is set once here and stored in .swytchcode/tooling.json. It is not an environment variable and your code never reads it. And deny the destructive methods in your local project outright rather than approving them, because a developer who genuinely needs to issue a refund can do it in the provider's own dashboard under their own name.

FAQ

What are the best MCP servers for Cursor?

Pick by job rather than by popularity. Most setups want a filesystem server scoped to specific directories, a version-control server, optionally a browser, optionally a read-only database connection, and one server for calling third-party APIs. The last one is where correctness matters most, because that is where the agent does something irreversible.

Where does Cursor store its MCP configuration?

In ~/.cursor/mcp.json for servers you want everywhere, or .cursor/mcp.json inside a project for servers scoped to that repository. Running swy init --editor=cursor updates the global file for you, after which you restart Cursor and confirm the server appears in Settings.

How many MCP servers should I install in Cursor?

Fewer than you want to. Every server's tool definitions are loaded into context on every request, so ten servers is a permanent tax and makes the model worse at picking the right tool. Five that cover distinct jobs beats fifteen overlapping ones. Prefer servers exposing a handful of tools over servers exposing one tool per endpoint.

Can Cursor call APIs like Stripe or Slack through MCP?

Yes, and the question is what sits between the agent and the provider. Through the Swytchcode MCP server, Cursor names the operation and the runtime validates arguments against the real schema, checks the method is on your allow list, applies your policies, injects the credential, retries safely and logs the result. The alternative, letting the agent write fetch with a token from your environment, has none of those.

Do I need an API token to use the MCP server?

Not in the default stdio mode. If you run it over HTTP with swy mcp serve --transport http --port 5476, it binds to localhost only and needs a bearer token stored at ~/.swytchcode/mcp_token, which you can print or rotate with swy mcp token.

How do I stop Cursor calling an operation I did not approve?

Only methods you have explicitly added with swy add method <canonical_id> are allowed to run, so anything else fails at the runtime before a request leaves your machine. Use swy discover to find the right operation and swy info to check its real parameters rather than letting the agent guess an ID.

Why does the server only expose seven tools?

Because tool count is a cost, not a feature. The agent profile's seven tools, discover, info, exec, list, search, add and a read-only policy, are enough to reach all 363 integrations, so adding providers does not grow the context. The full profile adds eight more for setup work, and the docs recommend switching back to agent once you are running.

Setup details here come from the Swytchcode MCP docs and the MCP quickstart. The same approach for other editors is in best MCP servers for Claude Code, and the enterprise view is in best MCP servers for enterprise AI agents.