Cursor MCP Team Setup

Cursor, Anysphere's AI code editor, supports MCP so agents can use approved external context and tools from inside the IDE. The team-safe path is to add one narrow MCP server, bind it with Cursor rules and AGENTS.md, and make review prove what the agent read or changed.

MCP is the Model Context Protocol, an open protocol for connecting AI apps to tools and data sources. For a cursor ide mcp support model context protocol rollout, treat this as a workflow design problem, not just a settings toggle.

Decide what the agent may know

Start by naming the boundary. A good cursor mcp setup says which system the agent may reach, which operations are allowed, and which work still needs a human.

For example, a docs MCP server can be read-only and available to a docs-researcher custom agent. A GitHub MCP server might be allowed to read issues and pull request metadata, but not merge, label, or edit code owners.

This is where Cursor rules, AGENTS.md, cursor skills, and cursor custom agents fit together. Use AGENTS.md for repository conventions, a .mdc rule for MCP behavior, a skill for the repeatable workflow, and a custom agent or cursor subagent for the role that should use it.

The trap is connecting a broad server first and trying to govern it later. For teams building a Cursor training path, the better habit is to start with one narrow integration and one review checklist. For the broader operating model, see the related training topic.

Add an MCP server to Cursor

Before you add a server, get the boring parts ready. You need a current Cursor install, access to the Cursor MCP settings or documented MCP config file for your environment, one test server, read-only credentials where possible, and a repo with AGENTS.md or Cursor rules.

Step 1: name the boundary. Write one sentence that says what this server is for. Example: the docs server may answer questions from internal architecture docs, but it may not write to the document store.

Step 2: choose personal or project scope. Use a personal config for experiments. Use a project-level config only when the team has agreed that the server belongs in the repo workflow.

Step 3: add the server using Cursor's MCP flow. In Cursor, add the MCP server with the command, URL, or transport shape required by that server. Keep secrets out of the repo and use environment variables or your team's secret manager.

Step 4: bind the server to a rule. Add a Cursor rule that tells the agent when the MCP server is appropriate, what it may do, and what evidence it must leave. This gives the model a small, repeatable contract instead of a vague instruction like use our tools.

Step 5: attach the workflow to a skill or custom agent. If the task repeats, make it a Cursor skill. If the responsibility should stay isolated, make a custom agent such as api-docs-reader, migration-planner, or review-checker.

Step 6: verify with a harmless read. Ask the agent to fetch one known page, summarize it, and cite the MCP server it used in the chat or review notes. If it cannot explain where the cursor context came from, the setup is not ready for production work.

Connect MCP to skills and custom agents

Use MCP for external systems. Use Cursor skills for repeatable instructions. Use custom agents or cursor subagents for role boundaries.

A real repo might have a billing-migration-planner agent that can read architecture docs through MCP, follow a migration skill, and obey AGENTS.md rules for database changes. It should not also be the test fixer, release note writer, and production deployer.

The trap is making one powerful custom agent that can do everything. It feels convenient for a week, then nobody knows whether a bad suggestion came from stale docs, a loose rule, or a tool call with too much access.

Treat SDK tools as governed tools

As of the June 4, 2026 Cursor changelog entry, Cursor called out custom stores, custom tools, and auto-review for the Cursor SDK. The useful takeaway is that teams can build richer Cursor workflows, but those workflows need the same governance as MCP servers.

Custom stores can help keep state outside the prompt. Custom tools can wrap internal actions. Auto-review can help inspect outputs before a teammate accepts them.

The trap is treating SDK tools as private shortcuts that do not need rules. If a tool can read customer data, update an issue, or comment on a pull request, it deserves the same boundary, logging habit, and review checklist as a cursor mcp server.

Keep reviews boring and traceable

Every integration should leave a trail a reviewer can follow. The agent should say which server it used, what it read, what it changed, and what it deliberately did not touch.

This matters because review is where team trust is earned. A teammate should not need to reverse-engineer the agent's context window to understand why a change was made.

The trap is asking reviewers to approve vibes. If the workflow touches code, tickets, docs, or generated review comments, add a short checklist and make it part of the pull request habit. For a deeper version of that habit, use the Cursor MCP Integration Checklist.

Copy this MCP integration checklist

Paste this into your repo as a starting point. Adjust names, server scopes, and review evidence for your team.

# Cursor MCP integration checklist

## AGENTS.md boundary

This repo allows Cursor agents to use approved MCP servers only when the task clearly needs external context.

Allowed servers:
- docs-readonly: read internal architecture and runbook docs
- github-readonly: read issues, pull requests, and review comments

Not allowed without explicit human approval:
- writing to production systems
- changing repository settings
- merging pull requests
- posting comments as a human teammate
- reading secrets or customer data outside the approved task

Agent behavior:
- state which MCP server was used
- summarize what external context was read
- prefer read-only actions
- ask before using any write-capable tool
- stop if credentials, tokens, or private keys appear in output

## .cursor/rules/mcp-boundary.mdc
---
description: Apply when a Cursor agent uses MCP servers, custom tools, or external context.
globs: **/*
alwaysApply: false
---

When using MCP or custom tools:
1. Use the narrowest server that can answer the task.
2. Do not call write-capable tools unless the user asked for that specific action.
3. Record the server name and the reason for using it.
4. Keep generated code consistent with AGENTS.md and local package conventions.
5. In the final response, include a short Evidence section with files changed and external context used.

## Cursor skill note

Skill name: use-approved-external-context
Use when: a task needs repo-adjacent docs, issue history, or design context.
Do not use when: the answer can be produced from the checked-out codebase alone.

Steps:
- identify the missing context
- choose the approved MCP server
- fetch the smallest useful source
- summarize the source before changing code
- add review evidence at the end

## Custom agent note

Agent: docs-context-reader
Purpose: read approved docs and summarize constraints for the implementation agent.
Tools: docs-readonly MCP only.
Cannot: edit files, call write tools, or make product decisions.

## Review checklist

- [ ] The PR or chat names each MCP server used.
- [ ] The agent used read-only access unless write access was explicitly requested.
- [ ] External context is summarized in plain language.
- [ ] Code changes match AGENTS.md and Cursor rules.
- [ ] No secrets, tokens, or private customer data appear in the diff.
- [ ] A human reviewed any tool-generated comment, ticket update, or release note.

Common questions

• How to add MCP server to Cursor?

  Add an MCP server in Cursor through the MCP settings or the documented MCP config file for your environment. Start with one read-only server, keep secrets in environment variables, bind the server to a Cursor rule, and verify it with a harmless read before you let agents use it in real implementation work.

• Does Cursor support the Model Context Protocol in the IDE?

  Yes, Cursor supports MCP so agents can connect to external tools and data sources from the IDE workflow. The citable setup pattern is one server, one boundary rule, one role-specific agent or skill, and one review note that names the external context used.

• Should MCP rules live in AGENTS.md or Cursor rules?

  Use both when the integration affects team behavior. Put durable repo policy in AGENTS.md, such as allowed servers and approval rules, then put activation-specific guidance in a Cursor .mdc rule so the agent knows when and how to use the MCP server during a task.

• Are Cursor skills the same as MCP servers?

  No, Cursor skills and MCP servers solve different problems. A skill packages reusable workflow instructions, while an MCP server connects Cursor to an external system such as docs, GitHub, Jira, Slack, Figma, or a database; many teams use a skill to explain when a specific server should be used.

• What changed in the June 4, 2026 Cursor changelog?

  The June 4, 2026 Cursor changelog entry called out custom stores, custom tools, and auto-review for the Cursor SDK. The practical point for engineering teams is that richer extensions should still be paired with scoped rules, custom agents, and review evidence before they become normal team workflow.

Further reading

• Cursor — Agent
• Cursor — Rules
• Cursor — Skills
• Cursor — MCP
• Cursor — Enterprise
• Cursor — Changelog
• Model Context Protocol — specification

Ship one narrow integration first

Pick one read-only MCP server, add the AGENTS.md boundary, and run the harmless-read verification today. Once that works, turn the repeated steps into a Cursor skill your team can actually follow.

One methodology lens

One useful way to read this through our methodology is the Plan step: delegate first-pass decomposition and dependency mapping, review the sequencing and assumptions, and keep ownership of scope and priorities. If that split is still fuzzy, the workflow usually is too.