Cursor Context Management: Rules, Indexing, and MCP

Cursor assembles context from your prompt, open or attached files, indexed code, project rules, conversation history, enabled tools, and the selected model. Reliable results come from making each source intentional, not from trying to place an entire repository in one prompt.

This guide was reviewed on September 11, 2026. Cursor’s interface and model catalog change frequently, so follow the official documentation links for current labels and limits.

Start with project rules

Version-controlled rules give Cursor durable instructions about a repository. Put project rules under .cursor/rules/ and keep each rule focused on a specific concern such as API conventions, database migrations, or test requirements.

A useful rule explains:

• where it applies;
• what the agent must or must not do;
• which command verifies the result;
• which generated or sensitive paths are off-limits.

Prefer a concrete instruction such as “Run npm test -- workspace-api after changing packages/api” over “write high-quality tests.” Cursor documents current rule types, metadata, and compatibility behavior in its rules guide.

Keep rules small and composable

One large rules file becomes expensive to load and hard to maintain. Split guidance by responsibility and scope it to the files that need it. Put detailed architectural background in normal documentation, then have the rule point to that source when relevant.

Review rules like code. Remove stale commands and conflicting instructions, because an agent cannot reliably infer which obsolete rule the team intended to ignore.

Understand codebase indexing

Cursor indexes a repository so it can retrieve relevant code without placing every file into the prompt. Indexing improves discovery, but it does not guarantee that every dependency or runtime behavior is present in a given response.

After a large branch switch or generated-code change, check the indexing state before diagnosing the model. Exclude secrets, build output, large data files, and dependencies that add noise. The official codebase indexing documentation describes current controls.

Attach decisive context

For a focused task, include the smallest evidence that determines correctness:

1. the failing command and its exact output;
2. the implementation and nearest tests;
3. the public contract or acceptance criteria;
4. any repository rule that constrains the change.

Use explicit file references when you already know the relevant surface. Use codebase search when you need the agent to trace callers, implementations, or related tests. Broad context is helpful for discovery; direct attachments are better for facts that must not be missed.

Separate planning, editing, and review

Ask the agent to plan when the affected surface is uncertain. Ask it to edit only after the boundaries are clear. Then review the resulting diff and test output as separate evidence.

A good implementation prompt includes the goal, allowed scope, behavior that must remain unchanged, and completion checks. A good review prompt asks for findings without authorizing edits. This prevents a diagnostic request from turning into an unexpected rewrite.

Manage long conversations

Long chats accumulate outdated assumptions and repetitive tool output. Record durable decisions in the repository, then start a fresh conversation when the objective changes. If a session is summarized, restate non-negotiable acceptance criteria and reattach the decisive files.

Do not use conversation history as the only record of an architectural decision. A short ADR, issue, or project rule is reviewable by both people and tools.

Choose models by task, not headline limits

Cursor’s available models and modes can change by plan and release. A larger advertised context window does not mean the application sends the entire repository, and it does not guarantee better retrieval.

Use a capable reasoning model for unfamiliar architecture or difficult debugging. Use a faster model for constrained edits and mechanical transformations. Check Cursor’s current models documentation instead of hard-coding model names, prices, or token limits into team guidance.

Add MCP tools sparingly

MCP servers can expose documentation, tickets, databases, and other systems to Cursor. They also add tool descriptions to context and expand the agent’s authority.

Enable only what a workflow requires, use least-privilege credentials, and prefer read-only tools for analysis. Never assume that a local editor makes a remote MCP server private. Cursor’s current setup options are documented in the MCP guide.

Troubleshooting checklist

When Cursor misses relevant context:

1. Confirm the correct repository and branch are open.
2. Check codebase indexing status and exclusions.
3. Verify that the applicable .cursor/rules/ files are valid and non-conflicting.
4. Attach the decisive file or error directly.
5. State the expected behavior and verification command.
6. Disable unrelated MCP servers or tools.
7. Retry in a fresh conversation if old assumptions dominate the session.

When the agent changes too much, narrow the prompt to named directories and prohibit incidental refactors. When it claims success without evidence, require the exact command and output that define completion.

Recommended repository baseline

A team-ready Cursor setup usually includes:

• small, scoped rules in .cursor/rules/;
• a documented build, format, lint, and test workflow;
• sensible indexing exclusions;
• least-privilege MCP connections;
• branch protection and automated checks independent of the agent;
• a review process for rule and tool changes.

The goal is not to maximize how much Cursor sees. The goal is to make the authoritative context easy to retrieve and the result easy to verify.