Cursor MCP Integration Checklist

Cursor, Anysphere's AI code editor, can use MCP to connect the IDE and agent workflows to external tools your team approves. For engineering teams, the useful path is simple: add one MCP server, wrap it in Cursor rules and skills, then make reviews prove the integration is safe.

MCP is an open protocol for giving AI tools structured access to external systems such as repos, docs, issue trackers, databases, and internal services. In a Cursor workshop or cursor training session, the goal is not just to wire up cursor mcp. It is to make the new power legible to the whole team.

Start with the June 2026 Cursor SDK change

The June 4, 2026 Cursor changelog calls out custom stores, custom tools, and auto-review for the Cursor SDK. Treat that as a workflow signal: integrations are becoming team-shaped surfaces, not one-off local hacks.

Custom stores are useful when the agent needs durable, structured context. Custom tools are useful when the agent needs to take a specific action. Auto-review matters because every new tool path should leave something a teammate can inspect.

Do not add integrations before naming the boundary. A GitHub MCP server, a Jira MCP server, and a private docs MCP server may all be reasonable, but they should not all be available to every cursor custom agent in every repo by default.

For more on the training lane this belongs to, see the related training topic.

Add one MCP server your team can explain

Start with one boring, high-value integration. A good first server is usually GitHub, an internal docs index, or a read-only issue tracker.

Prerequisites:

• A known MCP server package, command, or remote endpoint
• A clear owner for the integration
• Authentication that does not put secrets in the repo
• A repo-level rule for when the agent may use the tool
• A review habit for tool-driven changes

Step 1: name the boundary. Decide what the server is allowed to help with. For example: read issues and pull request metadata, but do not create issues or merge code.

Step 2: register the server in Cursor. Use Cursor's MCP configuration flow from the docs, and prefer a shared workspace config only when the server itself is safe to share. Keep personal tokens in user-level or secret-backed configuration.

Step 3: add a repo rule. Put the integration boundary where the agent will see it during real work. A .cursor/rules/mcp-integrations.mdc file is a good place for short, durable constraints.

Step 4: create a skill for the repeatable workflow. A cursor skill should say when to use the server, which files or systems matter, and what evidence to return. The skill is the recipe; MCP is the connection.

Step 5: assign the work to a scoped agent. If your team uses cursor subagents or cursor custom subagents as a convention, give the integration to the narrowest agent that needs it. A release-notes agent may read changelogs and PRs; it should not need production database access.

Step 6: verify with a harmless query. Ask Cursor to fetch one known issue, summarize it, and cite the tool output in the chat or review note. If the agent cannot show where the context came from, the setup is not ready for production work.

This is the practical answer behind cursor ide mcp support model context protocol: Cursor can connect to MCP servers, but teams still need rules, skills, and review checks to make that access safe.

Put Cursor context in files, not folklore

Good cursor context is written down close to the code. Use AGENTS.md for durable repository conventions, nested AGENTS.md files for local boundaries, and Cursor rules for IDE-native instructions that should travel with the project.

For example, a payments service might allow an MCP docs server for API references, but forbid the agent from using customer data in prompts. Put that rule beside the service, not in a Slack thread from three months ago.

Avoid making one giant root file that tries to explain the whole company. Local scope wins because the agent needs the rule at the moment it edits the relevant code.

Make skills and custom agents boring on purpose

Cursor skills should package repeatable work: triage a flaky test, prepare a migration plan, draft release notes, or run a security review. Keep the description crisp because it is part of the activation surface.

A custom agent, or cursor subagent in team shorthand, should have a narrower job than a human engineer. Good examples are dependency auditor, API migration helper, docs sync reviewer, or frontend accessibility reviewer.

Do not create a heroic generalist agent with every tool attached. That feels convenient for a day, then becomes hard to audit. If a skill uses MCP, say which server it may use and what output it must leave behind.

A useful next step is pairing the integration with a review trail. The pattern in Make Cursor Reviews Leave a Trail fits especially well when a tool can read external state.

Use auto-review as the guardrail

Auto-review should not be a rubber stamp. Use it to check the exact risks introduced by MCP and custom tools: unverified external context, broad permissions, missing citations, and code changes that were not connected to the original task.

A lightweight review habit works better than a heavy policy document. Ask every MCP-backed workflow to leave three things: what it read, what it changed, and what a human should verify.

Do not review only the final diff. With cursor mcp model context protocol workflows, the context path matters as much as the code path.

Paste this integration checklist

Use this as a starter artifact in AGENTS.md or in a repo onboarding note. Keep it short enough that people actually maintain it.

# MCP Integration Checklist for Cursor

Owner: @team-or-person
Repo area: services/payments
MCP server: internal-docs-readonly
Allowed use: read API docs, ADRs, and migration notes
Not allowed: customer data, secrets, production queries, write actions

## Cursor rule stub
Create or update: .cursor/rules/mcp-integrations.mdc

- Use the internal-docs-readonly MCP server only for payments architecture, API contracts, and migration history.
- Before changing code based on MCP context, summarize the document or record used.
- Do not paste secrets, customer data, or production identifiers into agent prompts.
- If MCP output conflicts with repo code, trust the code and ask for human review.
- Any PR using MCP context must include a short review note with the source, decision, and remaining risk.

## Skill boundary
Skill name: payments-docs-check
Use when: planning a payments API change or reviewing a migration PR
Expected output: relevant docs summary, affected files, open questions, review checklist

## Custom agent boundary
Agent: payments-reviewer
Tools: repo read, tests, internal-docs-readonly MCP
No access: production database, deploy tools, customer records

## Review checklist
- [ ] The agent named the MCP server it used.
- [ ] The agent summarized the external context in plain language.
- [ ] The code diff matches the cited context.
- [ ] A human reviewed permission scope before merging.
- [ ] The rule or skill was updated if the workflow changed.

Common questions

• How do I add an MCP server to Cursor?

  Add the MCP server through Cursor's MCP configuration flow, then test it with one harmless read-only request. Before sharing it with a team, write the allowed use, owner, auth pattern, and review requirement in AGENTS.md or a Cursor rule so the integration is not just living on one person's machine.

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

  Yes, Cursor supports MCP so agents can connect to external context and tools from the IDE workflow. The important caveat is governance: the cursor mcp support model context protocol story is strongest when access is scoped by repo rules, skills, custom agents, and review checks instead of being enabled everywhere.

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

  Use both when the integration affects real engineering work. Put durable team policy and repo boundaries in AGENTS.md, then put Cursor-specific activation notes in .cursor/rules/*.mdc; the split makes the rule readable to humans and useful inside Cursor at the same time.

• Do Cursor skills replace custom agents?

  No, Cursor skills and custom agents solve different parts of the workflow. A skill packages a reusable procedure, while a custom agent owns a scoped role; for example, a release agent might use a changelog skill and a GitHub MCP server, but still follow the same repo review rules.

• What can go wrong with a Cursor MCP setup?

  The common failure is giving the agent broad tool access without a review trail. Limit the first integration to one server, prefer read-only permissions, keep secrets out of repo config, and require the agent to state what external context it used before a human accepts the change.

Further reading

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

Try this next

Pick one read-only MCP server and add the checklist above before you connect a second one. If the team cannot review the boundary in five minutes, narrow the integration until it can.

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.