Cursor MCP Servers: How to Set Them Up and What to Add

Cursor MCP servers are configured in an mcp.json file, either inside a project or in your user folder, or through Cursor’s settings screen. Add a server by giving it a command to run or a URL to reach, reload, then check that its tools appear. Start with one read-only server and test it before adding others.

Where Cursor looks for servers

Cursor’s MCP documentation describes a JSON file with a top-level mcpServers object. Each entry has a name and either a command with arguments for a local server, or a URL for a remote one. Two placements are common:

Placement	Applies to	Use it for
Project file	One repository, shareable via version control	Servers the team needs, with no secrets inside
User file	Every project on your machine	Personal tools and keys

The same server definition style is shared across MCP clients, which is why a server listed on a directory usually ships a snippet you can paste. BusinessMCP’s page for Cursor gathers the servers it lists for that client, and the broader MCP server directory shows setup notes on each listing.

Key takeaway: put shared server definitions in the project file and personal credentials in your user file or environment variables. Never commit a token.

A starter set for an editor-based agent

Cursor users are mostly writing code, so the useful servers are the ones that give the agent facts it cannot see in your files.

1. Documentation search. BusinessMCP’s Dev Tools page lists Context7 (Upstash) as returning current documentation and code examples with one tool, and Microsoft Learn MCP for official Microsoft docs, both unlabeled rather than verified there. That fits the common failure of an agent writing code for an outdated library version.
2. Repository and Git. GitHub is listed as Official, Git as Verified.
3. A database. A read-only connection so generated queries match your actual schema; see best database MCP servers.
4. A browser or fetch tool. Useful for checking a rendered page. The Dev Tools list includes Chrome DevTools, described as driving a Chrome instance with navigation, DOM, console, network and performance traces.

For the longer version, read best MCP servers for developers.

Adding a server step by step

1. Open Cursor’s settings and find the MCP section, or open the mcp.json file directly.
2. Paste the server definition from its listing or README.
3. Replace placeholder keys with a narrowly scoped credential.
4. Save and reload the window if the new server does not appear.
5. Toggle the server on and confirm it shows a healthy status.
6. Ask the agent to list the server’s tools, then run one harmless request.
7. Watch the first few tool calls rather than approving blindly.

Local commands and what they imply

Many local servers start with a command like npx followed by a package name. That means Cursor will download and run code from a package registry on your machine. This is normal, and also exactly why you should check who publishes the package. A server marked Verified on BusinessMCP means the directory located the repository or vendor docs and confirmed the link resolves, which is a start, not an audit. See official vs verified MCP servers.

Fixing common problems

Symptom	Likely cause	Fix
Server missing	Invalid JSON	Validate the file; watch for trailing commas
Red or failed status	Runtime not installed	Install Node or the required runtime
Auth errors	Expired or wrongly scoped key	Create a new restricted key
Wrong tool chosen	Overlapping servers	Disable one of the duplicates
Slow or confused agent	Too many active tools	Turn off servers you are not using

Working with approvals

Cursor typically asks you to approve tool calls unless you enable broader auto-run behaviour. For read-only tools, allowing automatic runs is reasonable. For tools that write, send or deploy, keep manual approval. Several servers state their limits on their listing. BusinessMCP’s Stripe entry, for example, says there are no refund, payout or subscription-change tools, which makes the risk easy to judge.

How Cursor compares with other clients

The server side is identical across clients. What differs is where configuration lives and how approvals look. If you also use a terminal agent, our Claude Code guide covers its scopes, and the Claude guide covers the desktop app. Interface details change often, so rely on Cursor’s current documentation for exact menu names, and keep your active set small, since every tool description competes for the model’s attention.

A short rule set for editors

Because an editor agent works inside your codebase all day, a few habits pay off quickly. Keep the global file for personal utilities and the project file for shared ones. Name each server by purpose so you can spot duplicates. Disable servers you are not using in the current project instead of deleting them, so that switching contexts is cheap. Keep a note of which servers can write.

Compare with the directory’s own guidance too: BusinessMCP’s Dev Tools page lists dozens of options, but you only need a handful, and the page itself says it publishes no install counts for third-party servers, so you cannot use popularity as a shortcut. Read each listing’s tool names and decide on that basis. Finally, update deliberately: when a server package updates, skim its changelog before the next session if the server has access to anything sensitive.

Checking what actually ran

After a session in which the agent used several tools, look back at the tool calls it made. Confirm they match what you intended, particularly any that wrote data. If something surprised you, tighten the server’s credential or move that tool behind manual approval. Treat the first week with a new server as a trial period, not a permanent setup.

When to turn a server off

Switch a server off when the task at hand does not need it, when you are working with unfamiliar code from an outside source, or when you are screen sharing. Fewer active tools means a clearer context for the agent and a smaller set of things that can go wrong. Turning one back on takes a few seconds.