PRD vs Cursor Rules vs MCP: What Context Goes Where?
Use each layer for the job it does best: the PRD for product decisions, Rules for durable coding instructions, MCP for retrieving live external context, the repository for implementation state, and the prompt for the task at hand.
The short answer:
- Put product intent in the PRD: the user problem, outcome, scope, stories, acceptance criteria, constraints, and success measures.
- Put durable working instructions in Cursor Rules: architecture boundaries, coding conventions, approved commands, testing expectations, and directory-specific guidance.
- Use MCP to retrieve live external context: the current PRD, user story, customer evidence, or decision record needed for the task.
- Let the repository describe implementation state: existing code, interfaces, schemas, tests, and dependencies.
- Use the current prompt for temporary intent: the specific change, file, constraint, and desired response for this turn.
Why Teams Confuse PRDs, Rules, and MCP
When an AI coding agent produces the wrong feature, the immediate reaction is usually to add more text to the prompt. If the problem repeats, teams move that text into a Rule. Eventually the rule file contains coding style, architecture notes, feature requirements, roadmap decisions, customer quotes, and temporary warnings.
The agent now has more context—but not necessarily better context. Stable instructions compete with changing requirements, old decisions remain active, and developers cannot tell which source is authoritative.
The solution is to classify context by three properties:
- Meaning: is this a product decision, a coding instruction, existing system state, or a temporary task?
- Lifetime: should it survive one prompt, one feature, or every task in the repository?
- Ownership: should product, engineering, or the current developer maintain it?
PRD vs Cursor Rules vs MCP: Side-by-Side Comparison
| Layer | Best for | Maintained by | Lifetime | Do not use it for |
|---|---|---|---|---|
| PRD | Problem, outcome, scope, exclusions, stories, acceptance criteria, constraints, risks, and metrics | Product with engineering input | A feature or product decision lifecycle | Repository-wide formatting rules or one-off coding commands |
| Cursor Rules | Coding conventions, architecture boundaries, preferred libraries, commands, test standards, and file-specific guidance | Engineering | Repeated work in a project, directory, or file type | A changing backlog, complete PRDs, or transient tasks |
| MCP | Connecting the agent to current external resources and approved tools | Platform or tool owner | Available on demand while the connection is authorized | Replacing the source system or fixing a vague requirement |
| Repository | Current code, interfaces, tests, schemas, dependencies, and local documentation | Engineering | The current implementation lifecycle | Unapproved future behavior or customer rationale |
| Prompt | The immediate objective, selected requirement, boundaries, and expected response | The person running the task | One task or conversation | Facts the team must remember and reuse consistently |
What Belongs in the PRD?
The PRD should answer what the team has decided to build and why. It is the product contract that connects evidence to behavior.
- Customer problem and supporting evidence
- Desired user and business outcome
- In-scope and explicitly out-of-scope behavior
- User stories or jobs to be done
- Acceptance criteria and negative scenarios
- Business rules, permissions, and product constraints
- Dependencies, risks, assumptions, and unresolved decisions
- Success measures and validation plan
A PRD should not prescribe every implementation detail. Engineering still needs room to select the architecture and implementation that satisfy the product constraints.
PRD example
Requirement: A workspace administrator can remove a saved payment method only when another valid payment method remains.
Acceptance criteria: removal is blocked for the sole valid method; the administrator sees a clear explanation; unauthorized roles cannot perform the action; successful removal is recorded in the audit log.
This belongs in the PRD because it defines product behavior and risk—not merely how code should be formatted.
What Belongs in Cursor Rules?
Cursor’s official Rules documentation describes Rules as persistent, reusable context for the agent. In practice, they should contain instructions the agent needs repeatedly while working in the repository. Good Rules are concise, actionable, scoped, and concrete.
- Use the existing service layer instead of accessing the database from route handlers.
- Validate external input with the repository’s approved schema library.
- Do not modify generated migration files manually.
- Run the named unit and integration test commands before reporting completion.
- Preserve public API compatibility unless a requirement explicitly authorizes a breaking change.
- Apply a directory-specific convention only to files inside that directory.
Cursor Rule example
This belongs in a Rule because it describes how implementation work should be performed across many features.
What Belongs Behind MCP?
MCP is not another document format. It is the connection layer that lets an AI client discover and retrieve context from an external source when that context is relevant. Cursor documents MCP as a way to connect external tools and data sources to the IDE; see the official Cursor MCP guide.
Good candidates for MCP access include:
- the current version of a PRD or a specific user story;
- acceptance criteria and negative scenarios for the selected task;
- customer evidence supporting a requirement;
- decision history and clarification status;
- approved design-system or API documentation maintained outside the repository;
- authorized tools that search or summarize those sources.
MCP is especially useful when the information changes independently of the codebase, has a different owner, or should be fetched selectively instead of injected into every conversation.
What Belongs in the Current Prompt?
The prompt should orchestrate the other context layers for one task. It should identify the requirement, request the relevant context, define a boundary, and specify what the agent should return.
Task prompt example
The prompt does not duplicate the complete PRD or the repository conventions. It tells the agent which sources to consult and how to proceed.
A Five-Question Decision Framework
- Does this explain the user problem, desired behavior, scope, or success?
Put it in the PRD. - Should the instruction apply repeatedly when code is edited?
Put it in a scoped Cursor Rule or repository instruction file. - Does the information live outside the repository or change under another team’s ownership?
Keep it in its source system and expose it through MCP when appropriate. - Is it already represented by code, tests, schemas, or interfaces?
Let the agent inspect the repository rather than maintaining a duplicate description. - Is it specific to the task being performed right now?
Put it in the current prompt.
Complete Example: Adding Account Cancellation
Suppose a SaaS team is implementing account cancellation after users complained that the existing process required contacting support.
PRD
- Users need self-service cancellation from billing settings.
- Cancellation takes effect at the end of the paid period.
- The UI must show the effective date before confirmation.
- Enterprise contracts and unpaid invoices require separate handling.
- Success is measured by reduced cancellation-related support contacts without increased accidental cancellations.
Cursor Rules
- Billing mutations must use the existing billing service.
- Every mutation requires authorization and idempotency tests.
- User-facing dates use the workspace timezone utility.
MCP retrieval
- Retrieve the current cancellation story, its acceptance criteria, enterprise exclusion, and unresolved payment-provider decision.
- Retrieve the supporting customer theme only if the agent needs to evaluate a disputed behavior.
Repository context
- Existing subscription model, billing provider adapter, settings page, authorization middleware, and test patterns.
Current prompt
Ask the agent to retrieve the cancellation story, inspect the existing flow, identify ambiguity, and propose a bounded plan before editing.
Each layer has one job. Product can revise the effective-date decision without rewriting engineering Rules. Engineering can update its test convention without modifying the PRD. The agent can retrieve both when it implements the feature.
Common Context Architecture Mistakes
- Duplicating requirements everywhere. Copies drift. Keep one authoritative product decision and link or retrieve it.
- Using Rules as organizational memory. Rules should guide agent behavior, not become an archive of every decision the company made.
- Retrieving more context than the task needs. Start with one story and expand only when dependencies require it.
- Letting the agent resolve product ambiguity silently. Unanswered product decisions should be surfaced to the owner, not converted into accidental code behavior.
- Treating MCP access as automatic correctness. Retrieval improves grounding; tests and human review still verify the result.
- Giving broad permissions by default. Approve trusted MCP servers, protect credentials, and use the narrowest access appropriate to the workflow.
The New Contract Between PMs and Developers
For developers, this architecture reduces repeated prompting and gives the agent clearer boundaries. For PMs, it keeps product intent inside the implementation loop without requiring them to supervise every IDE conversation.
For the complete PM-side framework, read What AI Coding Agents Need From Product Managers.
PMs who are not technical can use the companion guide to guide Cursor without writing code.
The shared contract becomes:
- Product owns the clarity and currency of the requirement.
- Engineering owns repository conventions and technical quality.
- The developer names the relevant requirement in the task.
- The agent retrieves context, explains its interpretation, and works within the approved boundary.
- The team verifies the diff against both product criteria and engineering standards.
Frequently Asked Questions
What is the difference between a PRD and Cursor Rules?
A PRD defines the product problem and the behavior the team has decided to deliver. Cursor Rules define recurring instructions for how the agent should work in the repository.
What is the difference between Cursor Rules and MCP?
Rules are persistent instructions available to the coding environment. MCP connects the environment to external tools and sources so it can retrieve current context when needed.
Should product requirements be stored in Cursor Rules?
Feature requirements generally should remain in the PRD. A stable product-wide constraint—such as an accessibility baseline—may also appear in a Rule when it must guide every relevant implementation.
Does MCP replace the PRD?
No. The PRD contains the decision; MCP transports or retrieves it. A vague requirement remains vague after it travels through MCP.
Do Cursor Rules replace good prompts?
No. Rules reduce repetition, but the current prompt still needs a specific objective, scope, relevant requirement, and expected result.