Cursor MCP setup: connect servers, auth, and config

How to set up MCP in Cursor

Cursor is an MCP client: it reads a list of MCP servers from a config file and exposes each server's tools to its agent. Add a server, restart, and the tools show up. The hard part — and what makes the difference between a demo and a team-wide rollout — is project-level config, secret handling, and gating write tools.

1. Open Cursor → Settings → MCP. Add each MCP server with its command, args, and (where required) env vars.
2. For team standardization, commit .cursor/mcp.json to the repo so every engineer gets the same tools.
3. Keep credentials out of the file — read them from env or Cursor's secret storage.
4. Reload Cursor (or run "MCP: Reload" from the command palette) and verify the tools appear in the agent chat.
5. Pair MCP tools with a project .cursorrules file so the agent uses them inside your golden-path workflow, not as ad-hoc lookups.

Project config vs. user config

Most MCP clients support two scopes: a project-level file that gets committed to the repo (so the whole team shares the same setup), and a user-level file in the home directory (for personal tools). For team standardization, always prefer the project file and keep it free of secrets.

What you can do with MCP in Cursor

• Wire MCP servers (Postgres, Datadog, Linear, Sentry, etc.) into the editor and use their tools from the agent chat
• Combine MCP tools with Cursor’s Rules to give the agent a project-specific golden path
• Use MCP context inline while editing, the same way you’d look up a type or a file

Authentication and secrets

MCP servers are added in Cursor Settings → MCP. Credentials are read from environment variables or Cursor’s secret storage at call time. The general rule: the config file is a list of where servers live and how to launch them; the credentials themselves come from the environment, a secret store, or a CLI like op / doppler / vault.

Common Cursor MCP setup mistakes

• Putting tokens in the config file. Anything in .mcp.json / .cursor/mcp.json gets committed. Use env vars.
• No version pinning. Servers change. Pin to a specific version or commit-hash so a breaking change in a dependency doesn't quietly rewrite your team's tools.
• Granting write tools to everyone. MCP tool permissions are coarse by default. For high-impact tools (database writes, deploys, ticket transitions), use the client's permission/hook system to require approval.
• Skipping team rollout. Adding the config to your repo isn't the same as the team using it. Pair MCP rollout with rules files, slash commands, and a short demo.

Cursor MCP vs. a custom agent loop

If you only ever want one model + one tool, a hand-rolled loop is fine. The win from MCP in Cursor is reuse: any server you add works across Claude Code, Cursor, Cline, and any other MCP-capable client, and your team doesn't re-implement the same wrapper for every new tool.