Cursor 3.3 Context for Subagents and Skills

The situation

Field note: Context breakdowns expose overloaded rules teams refused to split—we watch reviewers blame “the model” when duplicated .mdc + AGENTS.md paragraphs waste half the budget.

Official anchors: Cursor Agent docs, Rules, MCP intro.

Cursor’s agentic workflows get harder to tune once a repo has layered rules, MCP connectors, custom skills, and subagents. The issue is usually not model quality. It is context going to the wrong places, or too much instruction following the task.

Cursor 3.3 adds a breakdown of agent context usage. That makes it easier to see where the budget is going. If a task drifts, you can check whether the agent spent context on global rules, project rules, attached skills, MCP results, or delegation summaries.

That matters for teams using Cursor subagents and skills. You need to know whether the setup is helping or just adding weight. The goal is to keep the right instructions close to the work and leave the rest out.

Walkthrough

Use the breakdown as a diagnostic, not a scorecard. Compare one successful task with one failed task, then look for the biggest context consumers. The usual suspects are broad rules, duplicated instructions, or an MCP connector that returns more data than the task needs.

Sort the setup into four buckets: repo rules, task-specific guidance, external tool context, and delegated work. Then trim each bucket on its own. In Cursor, that often means moving from one large rule file to smaller scoped .mdc files, keeping team conventions in AGENTS.md, and using skills for repeatable task patterns rather than one-off prompts.

A small rule stub is often enough:

---
description: Apply only to API route files
globs:
  - "src/api/**/*.ts"
alwaysApply: false
---
- Prefer small, reviewable changes.
- Check `AGENTS.md` before editing shared conventions.
- If a task needs external data, use the approved MCP source only.

If the breakdown shows rules taking most of the context, split the rule by scope instead of adding more prose. If task instructions repeat, move them into a skill or a short reusable note. If MCP is expensive, narrow the connector’s scope or ask for smaller outputs. If subagent summaries are too thin, give the subagent a narrower job and a clearer handoff format.

A practical team artifact is a short AGENTS.md boundary:

# AGENTS.md

- Follow existing architecture patterns in this repo.
- Prefer scoped `.cursor/rules/*.mdc` files over a single global rule.
- Use MCP only for approved external systems.
- Before opening a PR, verify that agent-authored changes are covered by tests or a reviewer checklist.

The breakdown makes these choices visible. Once you can see where context is going, you can decide whether the fix belongs in rules, skills, MCP, or delegation. That is usually better than telling the agent to “be more careful.”

Team artifact

Context tuning worksheet (paste in retro notes):

• Largest context slice named + owner assigned to trim it
• Duplicate instructions removed between .mdc, skills, and prompts
• MCP connector output capped or filtered with explicit limits

What to verify

• Does the task need a global rule, or only a scoped .mdc file?
• Is any instruction duplicated across rules, AGENTS.md, and the prompt?
• Did the MCP connector return more data than the task needed?
• Did the subagent return a usable summary, or just a vague status update?
• Can a reviewer verify the result without reading hidden context?

Methodology note: this is a Review step. The context breakdown is most useful after a real task has run, when you can compare the agent’s behavior against the artifacts that shaped it. For a lightweight process note, see our methodology.

Tradeoffs and limits

The breakdown is only as useful as the structure behind it. If your repo has one giant rule file, no clear AGENTS.md, and broad MCP access, the chart will show the problem without fixing it.

It also does not replace judgment. A high context share from rules is not automatically bad if those rules are precise and scoped. A low MCP footprint is not always better if the task needs external data. The question is whether each source earns its place.

There is also a coordination limit with subagents. Smaller context can improve isolation, but it can remove the shared detail a subagent needs for a useful handoff. If summaries become too thin, the fix is usually a better delegation boundary, not more delegation.

Treat the feature as a diagnostic surface, not a contract. Cursor’s docs and behavior can change, so verify the current rules, skills, and MCP guidance in the product docs before standardizing a team workflow.

Further reading

• https://cursor.com/docs
• https://cursor.com/docs/rules
• https://modelcontextprotocol.io/docs/getting-started/intro
• https://github.com/anthropics/skills/blob/main/README.md
• https://github.com/openai/skills/blob/main/README.md
• Subagents and skills topic