Add an MCP Server to Cursor

By Rogier Muller11.04.26
Add an MCP Server to Cursor

Add the MCP server only after you know what the agent may read or change. Cursor MCP gives Agent access to external systems such as repos, tickets, docs, databases, and design files, but the team risk is scope, permissions, and review, not the JSON syntax. In a Cursor workshop, I usually make teams start with one read-only server, add it at the narrowest useful scope, and inspect the first agent run before broadening access.

For engineering teams, learning how to add MCP server to Cursor is best treated as a small integration change: choose the boundary, configure the server, add Cursor rules, and review the output. That fits the same habits you need for Subagents and skills: the agent can be capable, but the repo still needs clear conventions.

Choose the first server boundary

Start with the system where better context removes obvious friction. A GitHub or issue-tracker MCP server is often safer than a database MCP server because the first use case can be read-only: inspect an issue, read linked code, summarize the likely change, and draft a plan.

In a Next.js repo with Prisma migrations and GitHub Actions, I would not start by giving Cursor write access to production data. I would start with an MCP server that can read issues and pull request metadata, then ask Agent to connect a failing CI job to the files it should inspect.

A good first boundary says three things: which system Cursor may reach, which actions are allowed, and who owns the token. If the server can mutate state, write that down before anyone runs it.

Rolling this out in your team?

We train engineering teams on their own codebase in two days. Cursor setup, shared rules and review included.

Add the server at the right Cursor scope

Cursor supports MCP configuration through its settings and JSON configuration. Use a user-level config for personal tools and tokens. Use a project-level config when the team should share the same server name, command, and expected tool surface.

A practical setup flow looks like this:

  1. Pick one MCP server and one use case, preferably read-only.
  2. Decide whether it belongs in your user config or the repo's .cursor/mcp.json.
  3. Add the server through Cursor's MCP settings or by editing the MCP JSON file.
  4. Keep secrets in environment variables or your local secret manager, not in committed JSON.
  5. Restart or refresh the server in Cursor and check that its tools appear.
  6. Ask Agent a small question that should use the new tool, then inspect the answer and tool calls.
  7. Commit only the project-safe config and rules, never local credentials.

For a project config, the shape is usually a named server under mcpServers. The exact fields depend on whether the server is local command based or remote, so copy the current pattern from the official Cursor MCP docs before committing it.

Put access rules where the agent will see them

Do not rely on a chat message to carry the policy. Put durable rules in Cursor rules or an AGENTS.md boundary so the same instruction is present when another teammate or agent session runs the workflow.

Cursor rules are useful for always-on repo conventions. Cursor skills are better for repeatable task workflows, such as turning a ticket into an implementation plan or reviewing a migration. Cursor custom agents or subagents can then specialize the work, but the MCP permission boundary should still be visible in the repo.

This is where I connect it to our methodology: MCP setup belongs in Review as much as Build. The agent may fetch context, but a human should review the tool use, the assumptions, and any proposed change before ownership moves back to the team.

Paste this MCP boundary note

Use this as a small repo artifact. I usually put it near the MCP config or in the repo's agent guidance so the access decision is not hidden in one person's local setup.

# Cursor MCP boundary

Owner: <team or person>
Server name in Cursor: <mcp-server-name>
Connected system: <GitHub, Jira, docs, database, etc.>
Default mode: read-only
Allowed actions:
- Read linked issues, pull requests, docs, and metadata needed for the task.
- Summarize findings with links or file paths where possible.
- Propose code changes in the repo, but do not apply external writes without approval.

Blocked actions without explicit human approval:
- Posting comments, changing issue status, assigning users, or editing external records.
- Running write queries or migrations against shared databases.
- Reading secrets, customer data, or private documents outside the task scope.

Review habit:
- Before accepting an agent plan, check which MCP tools were used.
- Before merging code, verify that external facts cited by the agent still match the source system.
- If a new tool permission is needed, update this boundary before using it.

This artifact is deliberately boring. Boring is good here, because the useful part is shared ownership: everyone can see what Cursor may do through MCP, and reviewers have something concrete to enforce.

Keep skills separate from credentials

A Cursor skill can describe the steps for a recurring workflow, but it should not become a dumping ground for tokens, private URLs, or personal setup. Store the workflow in the skill. Store the access path in MCP config. Store the safety boundary in rules or agent guidance.

For example, a ticket-triage skill can tell Agent to read the linked issue, inspect touched packages, identify tests, and draft an implementation plan. The skill should assume the MCP server exists by name. It should not explain how to fetch a private token from someone's machine.

If you want a fuller security pass before wiring external systems into Cursor, I would pair this setup with Connect Cursor to MCP Safely. The important question is not whether MCP works. It is whether the team can tell what access was granted and how it was used.

Further reading

Next step

Add one read-only MCP server to a non-critical repo, paste the boundary note, and review the first Agent run as a team. If you want to practise this with real repo workflows, our hands-on training covers Cursor rules, skills, MCP, and review habits together.

Related research

Train your team on Cursor

Two days on your team's own repository, onsite or remote, with a written proposal before you commit.

Book a call

Prefer to measure first? Take the free team check.