How do you connect Cursor or Windsurf to your product knowledge?

Add one entry to the editor's MCP config file, pointing at a remote server URL. Cursor reads it from .cursor/mcp.json and Windsurf from mcp_config.json; both accept Streamable HTTP and OAuth. The wiring takes minutes. The part worth thinking about is what the editor can ask once it is connected.

An editor already reads the files you have open. What it cannot read is the history behind them, or the behaviour of the other services your product is made of. That gap is what a per-project product expert fills, and this guide shows the two config entries, then the questions that justify them.

The dated record: what the docs say on 13 October 2026

Editors change their MCP settings often, so this section is a record, not a promise. Re-check both pages before you rely on a line.

Cursor (MCP documentation):

1. Two config locations: .cursor/mcp.json in the project, or ~/.cursor/mcp.json for every project.
2. A remote server uses the url field, with an optional headers object. ${env:MY_SERVICE_TOKEN} interpolation works in both.
3. Transports: SSE and Streamable HTTP, both with OAuth. A fixed OAuth client goes in an auth object.
4. Tool calls ask for approval by default. The docs state no limit on the number of tools.

Windsurf (the page moved to docs.devin.ai; it describes itself as covering the legacy Cascade agent):

1. One user-level file: ~/.config/devin/mcp_config.json on macOS and Linux, %APPDATA%\devin\mcp_config.json on Windows.
2. A remote server uses serverUrl or url, with optional headers. Interpolation: ${env:VAR_NAME} or ${file:/path}.
3. Transports: stdio, Streamable HTTP and SSE, with OAuth on each.
4. At most 100 tools at once across all servers. A server can be toggled off, or single tools listed in disabledTools.
5. For teams, an admin allowlist in MCP Team Settings: once one server is allowlisted, every other server is blocked, and the Server ID must match the config key exactly, case included.

The two entries, side by side

The URL below is a placeholder. Use the one your project gives you; never paste a token into a file you commit.

Cursor, .cursor/mcp.json:

{
  "mcpServers": {
    "product-expert": {
      "url": "https://<your-server>/mcp"
    }
  }
}

Windsurf, mcp_config.json:

{
  "mcpServers": {
    "product-expert": {
      "serverUrl": "https://<your-server>/mcp"
    }
  }
}

Three differences matter in practice.

• Scope. Cursor can pin the server to one repository by committing .cursor/mcp.json. Windsurf's file lives in your home directory: the connection follows you, not the project.
• Secrets. If the server wants a header, pull it from the environment (${env:…}). A committed mcp.json with a literal key is the classic leak.
• Budget. Windsurf's 100-tool ceiling is shared. A server that exposes forty tools to answer one kind of question eats the room of every other server. What a server should expose is a design question before it is a config one.

What can the editor ask that the open file cannot answer?

Four families of question, each one a case where the file in front of the cursor is silent. The examples are illustrative.

1. Behaviour across a boundary. "What does the billing service do when a card is declined twice?" You are editing the web app; the answer lives in another repository.
2. What changed. "What changed in the export module since the 2.3 release?" The editor sees the current code. The change is in the diffs, and a commit titled "fix" says nothing about it.
3. Why. "Why does the import reject empty rows now?" This is the ticket-mystery question: the symptom is visible, the intent is in a past change.
4. Is it safe. "Does renaming this field break an integration?" The answer depends on what the public API promised, not on what this file imports.

Notice what these share: the asker is mid-task, and an invented answer costs more than a missing one. A coding agent that guesses at a service it cannot see writes plausible code against behaviour that does not exist. Product-feature hallucination is the same failure, with the agent on the other side of the keyboard.

"The official GitHub MCP server already does this"

For a developer holding credentials, it covers real ground: listing commits, reading pull requests, searching code. If your team writes disciplined commit messages, it can answer a share of the "what changed" family. We walked through its setup and its limits in the GitHub MCP server guide. Keep it for what it does well.

Two things it leaves untouched. It answers from commit labels and file contents, so a vague message gives a vague answer. And it needs a token with access to each repository, for every person and every agent that asks. A per-project expert returns answers derived from the diffs, so the asker never holds the keys. For a contractor, a support teammate who uses Cursor, or an agency client under an NDA, that distinction decides whether the connection is allowed at all.

"But that expert reads my repository"

It does, on stated terms. The GitHub connection is read-only. Each project gets its own server, so the expert for one product knows nothing about another. DeployIt reads the real code (re-synced on every push), the git history and your data through its own MCP servers, and checks the code before asserting anything. Access is revocable at any time, and the code stays in your repository.

Compared with the neighbours: Context7 and DeepWiki cover libraries and public repositories, and Mintlify generates an MCP server from written documentation. The subject here is your private product, derived from the code, current at each deployment.

Mini-FAQ

Which editor is easier for a whole team? Cursor, if you want the connection versioned with the project. Windsurf, if admins need to control which servers exist at all: its allowlist is the more developed team control in the docs read today.

Does the editor call the server on its own? It decides from the tool's name and description, which is why a description like "answers questions about current product behaviour and recent changes" gets called and "product tool" does not. In Cursor you also approve calls by default.

Do I need OAuth? Only if the server requires it. Both editors support it; a server behind a header can use headers instead.

What if I use Claude or Intercom Fin? Same server, different door. See connecting Claude and the generic API route.

What to take away

Connecting is the easy half: one JSON entry per editor. The half that pays is the server behind it, an expert that answers about your product from the real code and its history. Verify the config keys against the docs on the day you wire it; this record will age.

The DeployIt MCP server is in early access. The design partner program is open to teams who want to wire it into their editors and agents now.