Should a PRD go in Cursor Rules or MCP?

Put stable repository conventions in Rules. Keep feature goals, user stories, acceptance criteria, and changing product decisions in the PRD, then retrieve that context through MCP when it is relevant.

What should an AI-ready PRD contain?

At minimum, an AI-ready PRD should contain the problem and desired outcome, scope and exclusions, user stories, acceptance criteria, constraints, edge cases, dependencies, success metrics, and unresolved decisions.

AI Coding Workflow · September 4, 2026 · 9 min read

How to Connect Your PRD to Cursor or Windsurf Using MCP

Q: Can Cursor read a PRD through MCP?

Yes. An MCP server can expose a PRD and related product context as tools or resources that Cursor can retrieve when an implementation task needs them.

Q: Can Windsurf access a PRD through MCP?

Yes. When an MCP server is configured in a compatible Windsurf setup, the coding agent can retrieve product requirements instead of relying only on pasted prompt text.

Give your coding agent access to current product goals, user stories, constraints, and acceptance criteria—without copying the same requirements into every prompt.

Short answer: connect Cursor or Windsurf to an MCP server that exposes your PRD as structured, retrievable context. Keep coding conventions in IDE Rules, keep changing product decisions in the PRD, and ask the agent to retrieve the relevant requirement before it plans or edits code.

With ProdMoh, the workflow is: create or select a PRD, generate a private connection token, add the ProdMoh MCP server to your IDE, restart the client, and verify that the agent can list and read the intended PRD.

Why AI Coding Agents Lose Product Context

Cursor and Windsurf can inspect a repository, follow instructions, and edit multiple files. But the repository usually explains what exists, not why the next feature should exist. The missing information lives in customer feedback, product decisions, user stories, edge cases, and acceptance criteria.

Developers often compensate by pasting a PRD into a chat. That works for one conversation, but it creates three problems:

Context becomes stale. A copied requirement does not change when the source PRD changes.
Long prompts dilute the task. The agent receives the whole document when it may need one user story and three constraints.
Every developer creates a different handoff. Important exclusions or edge cases disappear during copy-paste.

MCP addresses the delivery problem. It gives an AI client a standard way to discover approved tools and resources outside the repository. A PRD platform can therefore remain the product source of truth while the coding agent retrieves only the context needed for the current task.

1. Customer evidenceFeedback and research establish the problem.

2. Structured PRDScope, stories, criteria, risks, and metrics record the decision.

3. MCP retrievalThe IDE requests relevant, current product context.

4. Reviewed codeThe developer checks the implementation against the requirement.

PRD vs Cursor or Windsurf Rules vs MCP

These mechanisms solve different context problems. Treating them as interchangeable leads to oversized rule files, stale specifications, and agents that follow conventions while building the wrong behavior.

For a fuller decision framework with examples, read PRD vs Cursor Rules vs MCP: What Context Goes Where?

Context	Best location	Why
Coding style, framework conventions, commands, repository boundaries	Cursor/Windsurf Rules or AGENTS.md	Stable instructions should travel with the repository and apply repeatedly.
User problem, desired outcome, feature scope, exclusions	PRD	These are product decisions that need ownership and revision.
User stories, acceptance criteria, edge cases, success measures	PRD retrieved through MCP	The agent can request the relevant, current requirement when planning or implementing.
“Modify this component but do not change its public API”	Current prompt	This is a task-specific instruction, not durable organizational knowledge.
Existing architecture, types, tests, and interfaces	Repository context	The codebase is authoritative for the present implementation state.

A useful rule of thumb: Rules tell the agent how to work. The repository shows what exists. The PRD defines what should be built. MCP makes the product decision available inside the coding workflow.

How to Connect ProdMoh to Cursor or Windsurf

The exact settings screen can change between IDE versions, but the connection has the same four parts: a PRD in ProdMoh, a private token, an MCP server configuration, and a retrieval test.

Step 1: Prepare an implementation-ready PRD

Choose a PRD that includes more than a feature description. The coding agent should be able to retrieve:

the user problem and desired outcome;
in-scope and out-of-scope behavior;
user stories and acceptance criteria;
negative scenarios, permissions, and edge cases;
non-functional constraints and dependencies;
success metrics and unresolved decisions.

If those fields are missing, MCP will deliver incomplete context more efficiently—it cannot repair an ambiguous product decision on its own.

Step 2: Generate a ProdMoh connection token

Sign in to your ProdMoh dashboard.
Open Share with Developers.
Enable the IDE assistant and generate an access token.
Copy the token and store it as a secret. Do not commit it to a repository.

The token provides read-only access to product context. If it is exposed or a developer leaves the team, revoke it and issue a new one.

Step 3: Add the MCP server to your IDE

In Cursor, add the server in the MCP settings or the supported mcp.json configuration. In Windsurf, add it through the MCP configuration available in your installed version. Use the connection details shown in the current ProdMoh MCP documentation.

A typical configuration has this shape:

{
  "mcpServers": {
    "prodmoh": {
      "type": "sse",
      "url": "https://prodmoh.com/sse",
      "headers": {
        "x-prodmoh-token": "YOUR_TOKEN_HERE"
      }
    }
  }
}

Important: copy the production URL and transport settings from the live MCP documentation rather than relying on an old snippet saved in a team wiki.

Step 4: Reload the IDE and verify access

After saving the configuration, reload Cursor or restart Windsurf. Then begin with discovery instead of immediately asking the agent to implement a feature.

Use the ProdMoh MCP tools to list the PRDs I can access. Do not edit any files.

Next, retrieve one document and ask the agent to summarize its identity and boundaries:

Read the checkout PRD. Return its title, current objective, in-scope behavior, exclusions, unresolved decisions, and acceptance criteria. Do not write code yet.

Compare the answer with the source PRD. This small check catches wrong-project access, stale content, missing sections, and vague naming before any code changes.

A Safer PRD-to-Code Workflow

Connection is only the first step. The reliable workflow separates retrieval, planning, implementation, and verification so the developer can inspect the agent’s interpretation before accepting code.

1. Retrieve the specific requirement

Retrieve the “Saved payment method removal” user story from ProdMoh. Summarize the goal, acceptance criteria, edge cases, and explicit exclusions. Cite the PRD section or story identifier you used.

2. Compare requirements with the repository

Inspect the repository for the existing payment-method removal flow. Identify which files and tests are relevant. List conflicts or missing decisions between the codebase and the retrieved PRD. Do not edit files.

3. Produce a bounded implementation plan

Propose the smallest implementation plan that satisfies the retrieved acceptance criteria. For every step, name the relevant criterion. Separate required changes from optional improvements.

4. Implement against named criteria

Implement only the required changes. Preserve existing public interfaces unless the PRD explicitly requires a change. Add or update tests for each acceptance criterion and negative scenario.

5. Review the result against the PRD

Re-read the same ProdMoh story. Compare the final diff with every acceptance criterion and exclusion. Report satisfied, missing, ambiguous, and out-of-scope changes. Do not silently repair anything.

This final comparison matters because an MCP connection supplies context; it does not remove the need for engineering judgment, tests, code review, or security review.

For the complete control loop after connection, see how to prevent feature drift when engineers use AI coding agents.

What Product Managers Gain From the Connection

The value for a PM is not “using another developer tool.” It is keeping product intent available after the engineering handoff.

Before configuring the connection, use the practical guide to what AI coding agents need from product managers to make sure the source requirement contains the decisions the agent cannot infer from code.

If the work begins with support tickets, reviews, or interview notes, follow the PM-to-Cursor handoff from raw evidence through the approved implementation context.

Requirements remain usable. Engineers can retrieve a story and its acceptance criteria without finding the correct document and copying it into a chat.
Changes stay closer to their source. The next retrieval can reflect an updated product decision instead of an old pasted prompt.
Ambiguity becomes visible earlier. If the agent cannot form a bounded plan, the PM can improve the requirement before implementation expands.
Review becomes traceable. Teams can discuss whether a diff satisfies named criteria rather than whether it “looks roughly right.”

For PMs, the new skill is not writing prompts for every developer. It is creating product context that both humans and agents can interpret consistently.

Common Mistakes to Avoid

Putting the entire PRD in a Rule. Rules are better for durable instructions; changing feature decisions belong in a governed product artifact.
Retrieving the whole roadmap for one task. Ask for the smallest relevant story or PRD section to reduce unrelated context.
Using vague names. Stable PRD and story identifiers reduce the chance that the agent retrieves a similarly named feature.
Allowing implementation before verification. Confirm that the agent found the correct PRD and understood its exclusions first.
Committing a token. Treat MCP credentials like API keys and keep them out of source control, screenshots, and shared prompt logs.
Assuming access means correctness. Agents can still misinterpret good context. Require tests and human review.

Frequently Asked Questions

Can Cursor read a PRD through MCP?

Yes. An MCP server can expose the PRD as retrievable product context. The developer can ask Cursor to read the relevant requirement before it plans or edits code.

Can Windsurf access a PRD through MCP?

Yes, when MCP is configured in the compatible Windsurf client. Keep the connection details in the client’s supported MCP configuration and verify access before implementation.

Should I use Rules or MCP for product requirements?

Use Rules for stable instructions such as repository conventions and coding constraints. Use a PRD for changing product decisions, and MCP to retrieve those decisions when the current task needs them.

Does MCP automatically keep generated code correct?

No. MCP improves access to context. Correctness still depends on requirement quality, the agent’s interpretation, the implementation, automated tests, and human review.

Do developers need to leave the IDE to read the PRD?

They should still be able to open the source when necessary, but routine discovery and retrieval can happen from the IDE after the MCP connection is configured.