Cursor Power-User Setup: Rules, MCP, and Agent Mode That Compound

The first time Cursor's Context Usage Breakdown tells you that your rules file is eating 22% of every request, your relationship with the editor changes.

That feature shipped on May 6, 2026, and it quietly exposed the gap between people who use Cursor and people who have tuned it. The tuned setup is not a longer prompt or a bigger model.

It's a handful of small, durable configuration choices that compound: scoped rules, the right MCP servers, the correct editing surface for each task, a clean index, and a review loop the agent can actually run.

This is the Cursor power-user setup, written for engineers who already live in the editor and want the parts that keep paying off.

TL;DR: The Cursor power-user setup is mostly configuration, not prompting. Ship small, scoped .cursor/rules/*.mdc files instead of one mega-rule. Match the task to the surface (Tab, Cmd-K, Composer, Agent, Cloud). Wire up only the MCP servers you trust, pinned and OAuth-first. Keep a tight .cursorignore. And read every diff before you accept it.

Key takeaways

• Many small rules beat one big one. A 1,200-line rule attached to everything dominates the context window and dilutes the signal.
• Each surface has a job. Tab and Cmd-K for local edits, Composer for multi-file specs, Agent for tool use, Cloud for long jobs.
• MCP is a security surface, not just a feature. Pin versions, prefer OAuth, and treat a shared mcp.json like a CI script.
• Indexing quality depends on .cursorignore. No ignore file means a slow, polluted semantic search.
• Plan Mode plus diff review is the whole game. Most agent horror stories trace back to skipping one of them.

What is the Cursor power-user setup?

The Cursor power-user setup is a small set of repo-level configuration files and habits that make the AI editor behave predictably across tasks and teammates: scoped .cursor/rules for conventions, a reviewed mcp.json for tool access, a .cursorignore for clean indexing, and a Plan-Mode-then-diff review loop.

None of it is exotic. All of it compounds, because the same config steers every request you make for months.

How do .cursor/rules work, and why MDC?

Cursor reads its rules from .cursor/rules/ at the project root, with each rule as a separate .mdc file: plain Markdown plus a small YAML front matter. The official Rules docs define three keys.

---
description: A plain-language description of when the rule applies.
globs: ["**/*.ts", "**/*.tsx"]
alwaysApply: false
---

When alwaysApply is false (the default), Cursor attaches the rule only when the active file matches a glob or the prompt references it. The description field is what the agent uses to judge relevance, so a sharp one-sentence "when this applies" line is the highest-leverage thing in the whole file.

Rules also nest. Cursor applies rules from the root and from any .cursor/rules/ directory between the repo root and the active file, with the deeper rule winning, the same way a closer tsconfig.json overrides the one at the root.

That's how you ship a general TypeScript style at the root and a narrow Vitest rule under tests/.cursor/rules/.

One trap: a nested rule with alwaysApply: true fires everywhere, because Cursor walks the tree on every request. Reserve alwaysApply: true for things that genuinely belong in every prompt, like a hard ban on any. For the rest, lean on globs.

A starter rule, scoped and short

---
description: TypeScript and TSX coding style. Applies to all .ts and .tsx files.
globs: ["**/*.ts", "**/*.tsx"]
alwaysApply: false
---

- Prefer `unknown` over `any`; explicit casts need a `// @ts-expect-error <reason>`.
- Use named exports, not default exports.
- Public functions: explicit return types. Private helpers: inferred.
- Never `console.log` in committed code; use the project logger.
- Run `pnpm test` and `pnpm typecheck` before declaring a task done.

The Morph MDC guides walk the same schema with more examples if you want a second reference. The principle holds: small, focused, well-described files. Cursor doesn't penalize you for having many.

What about AGENTS.md and .cursorrules?

Cursor also reads an AGENTS.md at the root, the cross-tool convention popularized by Aider and now used by OpenAI's Codex and GitHub Copilot. If you keep one for another tool, Cursor reads it. A legacy .cursorrules file still works too, but it's treated as one global rule with no glob awareness.

Pick one surface per instruction. Rules in AGENTS.md follow you across every tool that reads it; rules in .cursor/rules/*.mdc are Cursor-specific and can use globs. Duplicating the same guidance in both makes it impossible to know which instruction actually fired.

There's also an Agent Skills surface for multi-step workflows; the clean split is rules for "do/don't" guidance, skills for "perform this procedure."

Which Cursor surface should you use for each task?

Cursor structures its agentic surface into five entry points. The fastest win for most users is simply stopping the habit of reaching for Agent on everything.

The agent overview covers these in depth, and Composer 2.5 is the current Composer release shipping with the 3.x editor. Treat references to "Composer 1.0/2.0" in older posts as superseded.

Using Agent for a one-line change is the most common waste: Cmd-K is faster and cheaper, because Agent pays a tool-use tax on every request. The inverse mistake is letting Composer ride the last-selected model into a large refactor when you wanted a strong reasoning model. Pin the model per task.

Plan Mode is the underused lever

Plan Mode makes the agent write a plan, show it to you, and wait for approval before touching files. It is the single most underused power-user surface in Cursor as of mid-2026. Most "the agent overwrote my file" stories from 2024 and 2025 are just Plan Mode skipped on a task that needed it.

The prompting guide adds the other half: give the agent a specification, not a command. "Implement this with the same error handling as createUser" beats "add error handling here," and it's reusable.

Frame an explicit stop condition too, like "write tests, run them, stop when they pass," so the agent doesn't loop until it decides it's done.

How should you configure MCP servers in Cursor?

Model Context Protocol is how Cursor reaches external tools, and the MCP docs define two config locations.

• Global (~/.cursor/mcp.json): personal tools tied to your own credentials, available in every project.
• Project (.cursor/mcp.json): team-shared servers, checked into the repo, scoped to that project.

When a server name appears in both, the project-level entry wins. The schema is one mcpServers map with two transport shapes: stdio for local subprocesses, and HTTP/SSE for hosted endpoints.

{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["-y", "@github/[email protected]"],
      "env": { "GITHUB_PERSONAL_ACCESS_TOKEN": "<your-pat>" }
    },
    "linear": { "url": "https://mcp.linear.app/sse", "type": "sse" }
  }
}

For OAuth-protected endpoints, don't stuff a token in headers. Anthropic's remote GitHub MCP server went generally available in 2026 with OAuth 2.1 plus PKCE and Cursor as a supported client; Sourcegraph's GA changelog (Feb 25, 2026) describes the same Dynamic Client Registration pattern.

Remote OAuth is now the sensible default over a local API-key stdio server whenever a vendor ships a hosted endpoint.

The fastest path for supported vendors is the Cursor Marketplace, expanded in March 2026 with 30+ plugins (Datadog, Slack, Figma, Linear, Atlassian, and more). One-click install, OAuth auth, and the plugin ships a Skill that teaches the agent how to call it.

Hand-edit mcp.json when you need a server the Marketplace lacks, a pinned version, or a reference server like Filesystem or Postgres.

MCP is a security surface

The most important MCP fact in Cursor is CVE-2025-54136: an approved .cursor/mcp.json could be edited after approval, and the changed command would run on the next server start. Cursor shipped fixes that re-prompt on meaningful changes, but the practitioner rules are unchanged.

• Treat a project-level mcp.json like a CI script: review every change, pin exact versions, never @latest in a shared config.
• Prefer OAuth for any vendor that offers it. Short-lived per-developer tokens beat a long-lived static secret in a shared file.
• Keep personal stdio servers in ~/.cursor/mcp.json so a malicious project can't swap your tools.

Two silent failure modes worth memorizing: a literal "<your-pat>" placeholder left in the JSON 401s with no warning, and setting "type":"sse" on a Streamable HTTP server (or omitting it on an SSE one) yields a quiet "No server info" in the MCP logs.

How does Cursor indexing work, and what should .cursorignore exclude?

Cursor keeps a per-project embedding index that powers @codebase, "find similar code," and most of the agent's "where is X defined" lookups, documented under semantic and agentic search. The first index of a large repo can take 10 to 30 minutes; rebuilds are incremental.

A .cursorignore at the root, in gitignore syntax, controls what gets indexed. Per the ignore-file docs, matched files are excluded from the embedding index and not auto-attached, but they remain readable if you explicitly paste a path. The ignore is a suggestion to the index, not a security control.

node_modules/
dist/
build/
.next/
**/*.generated.ts
src/gen/
.env
.env.*
*.pem
secrets/
*.parquet
vendor/

Skip this and Cursor indexes everything, so "where is useAuth defined?" returns a hit inside node_modules/next-auth. Rules and the index are separate systems, which is why a rule that says "don't edit *.generated.ts" coexists cleanly with an ignore line for the same glob: the ignore keeps it out of search, the rule tells the agent to leave it alone.

One distinction that trips people up: @codebase is approximate vector search. For "list every callsite of processPayment," use the agent's literal grep tool instead. Use @codebase for "where is the rate limiter implemented?"

Picking a model without chasing the menu

The model picker is the most volatile part of Cursor, rotating roughly monthly, so anchor any specific choice to a date and re-check the enterprise controls doc and live changelog. The model families are stable even as version strings move.

As of June 2026, a pragmatic routing policy:

Two habits matter more than the exact pick. Don't default to the most expensive model; reserve Opus-class for the hard 10%. And don't switch models mid-session, because the choice is sticky and switching loses the run's accumulated context.

Also check the privacy tab: the default is not zero-retention, so set it if your project requires it.

The review habits that actually compound

Three habits separate a tuned setup from an expensive autocomplete.

1. Read the diff before accepting. Composer and Agent both surface changes as a diff first. That diff is your review surface, full stop.
2. Wire the agent to a test loop. A repo with a single pnpm test and pnpm typecheck command lets the agent verify its own work. A repo without one lets it only guess.
3. Make rules a team convention. When everyone shares the same .cursor/rules/*.mdc, the agent behaves the same for everyone and diffs stay consistent.

Layer Plan Mode on top for anything touching three or more files, run tests and lint as part of the task, and keep a feature branch so "reject all" isn't your only undo. The cloud agent dev environments (May 13, 2026) give you an isolated per-task sandbox for anything that hits the network or filesystem.

When something goes wrong, the checks are mechanical. Silent context bloat? Open the Context Usage Breakdown. Rule conflict? grep -RIn "<keyword>" .cursor AGENTS.md before arguing with the agent. MCP "no tools available"?

Check the panel for a red server and restart, or re-auth if a hosted OAuth token expired (a 401 surfaces as "tool call failed," not "please re-auth").

What this means for you

Spend an hour once. Split your rules into small MDC files with sharp descriptions and tight globs. Add a .cursorignore. Audit your mcp.json, pin versions, switch to OAuth where you can. Expose one test command and one typecheck command the agent can run.

Then make two habits non-negotiable: Plan Mode for anything non-trivial, and reading the diff every time. That's the setup that compounds, and unlike the model menu, none of it goes stale next month.

Sources

• Rules | Cursor Docs
• Cursor Rules Best Practices (2026) | Morph
• Agent Skills | Cursor Docs
• Agent Overview | Cursor Docs
• Plan Mode | Cursor Docs
• Prompting agents | Cursor Docs
• Composer 2.5 · Cursor
• Context Usage Breakdown · Cursor
• Development environments for cloud agents · Cursor
• Model Context Protocol (MCP) | Cursor Docs
• Cursor Marketplace
• Remote GitHub MCP Server is now generally available
• Sourcegraph MCP server is now generally available
• Cursor AI Code Editor Vulnerability (CVE-2025-54136) | The Hacker News
• Semantic & Agentic Search | Cursor Docs
• Ignore File | Cursor Docs
• LLM Safety and Controls | Cursor Docs
• Cursor is rolling out a new kind of agentic coding tool | TechCrunch