All posts

How to Use MCP with Cursor and Claude as a Developer

Wire your repo, APIs, and docs into Cursor via MCP so the agent stops guessing and starts grounding in real files and tools.

~13 min read

Cursor suggested a migration script last week that referenced a Prisma model we deleted two sprints ago. The code looked plausible. It was wrong because the agent never opened schema.prisma. I had MCP installed but only for GitHub, not for the repo filesystem. One config line later, the same prompt produced a diff that actually applied.

That is the practical payoff of MCP in Cursor and Claude Desktop: the model gets tools and resources from your machine instead of improvising from training data. This guide is the setup I use on Windows and Linux, the security rules I do not skip, and the workflows that save time once servers are connected.

If you want the protocol background first, read What is MCP?. This post is hands-on configuration.

What you are configuring: host, client, servers

Cursor and Claude Desktop are MCP hosts. They spawn or connect to MCP servers and expose discovered tools to the model in Agent mode (Cursor) or chat with tools enabled (Claude).

You do not configure the LLM directly. You configure the host's MCP client, usually via a JSON file listing server commands or URLs.

MCP tool call flow from developer prompt through Cursor agent to MCP server

Prerequisites

  • Cursor (recent build with MCP support) or Claude Desktop
  • Node.js 18+ for many official reference servers (npx launches them)
  • API tokens only where needed. Default to read-only scopes
  • Basic comfort editing JSON. No MCP server authoring required for your first hour

On Windows, install Node from nodejs.org or fnm, then confirm npx works in PowerShell. Path issues cause most "server won't start" tickets I see in team chats.

Cursor MCP setup step by step

1. Open MCP settings

In Cursor: Settings → MCP (or Cursor Settings → Features → MCP depending on version). You can also edit the config file directly.

Cursor stores project-level config at:

.cursor/mcp.json

Global config on Windows typically lives under your user profile in Cursor's application data. I prefer project-level configs checked into git (without secrets) so the whole team gets the same tools.

2. Add your first server (filesystem)

Scoped filesystem access is the best first server. It lets the agent read files in your repo without you pasting them into chat.

{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-filesystem",
        "D:\\Rohit\\Other\\Portfolio\\portfloio_green"
      ]
    }
  }
}

Replace the path with your project root. On macOS/Linux use absolute POSIX paths (/home/you/project).

Windows gotcha: Use double backslashes in JSON (\\) or forward slashes (D:/projects/app). A single backslash escapes the next character and breaks the path silently.

3. Reload MCP

Restart Cursor or use the MCP panel's reload action. A healthy server shows green/connected status. If it fails, open the MCP log panel. The first error line is usually PATH, JSON syntax, or a missing Node install.

4. Verify tools in Agent mode

Open Agent mode and ask: "List available MCP tools" or run a concrete task: "Read package.json and summarize scripts." You should see a read_file or similar tool invocation instead of a hallucinated file tree.

If tools do not appear:

  • Confirm the server process stays running (stdio servers exit on crash)
  • Check Cursor version. MCP moved fast in 2025–2026; older builds lack UI
  • Validate JSON with a linter. Trailing commas break parsing

5. Add GitHub (read-scoped)

{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem", "D:/projects/my-app"]
    },
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": {
        "GITHUB_PERSONAL_ACCESS_TOKEN": "${env:GITHUB_PERSONAL_ACCESS_TOKEN}"
      }
    }
  }
}

Create a fine-grained PAT limited to the repos you need. Read-only is enough for triage and code review assistance. Store the token in your OS environment, not in committed JSON.

Cursor supports env var interpolation patterns like ${env:VAR_NAME} in recent versions. If yours does not, use a local untracked mcp.local.json or OS-level env vars referenced in docs for your build.

6. Postgres read-only analytics (optional but high value)

{
  "mcpServers": {
    "postgres": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-postgres", "postgresql://readonly:PASSWORD@localhost:5432/analytics"],
      "env": {}
    }
  }
}

Create a readonly role with SELECT only. Set default_transaction_read_only = on at the role level if your provider supports it. Ask the agent for explain plans and row counts, not bulk exports.

Never point this at production primary unless you enjoy incident reviews.

Full project mcp.json example (my daily driver)

{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem", "D:/Rohit/Other/Portfolio/portfloio_green"]
    },
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": {
        "GITHUB_PERSONAL_ACCESS_TOKEN": "${env:GITHUB_PERSONAL_ACCESS_TOKEN}"
      }
    },
    "fetch": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-fetch"]
    }
  }
}

Three servers, nine to twelve tools total, predictable behavior. I add a fourth server only when a workflow repeats weekly.

Claude Desktop MCP setup

Claude Desktop uses the same protocol with a different config path.

macOS: ~/Library/Application Support/Claude/claude_desktop_config.json

Windows: %APPDATA%\Claude\claude_desktop_config.json

Example:

{
  "mcpServers": {
    "fetch": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-fetch"]
    },
    "memory": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-memory"]
    }
  }
}

Restart Claude Desktop after edits. The UI lists connected servers under settings. Claude uses MCP tools in chat when the model selects them; destructive operations still need your confirmation depending on tool and policy.

I run filesystem + fetch in Claude for research tasks, and filesystem + github + postgres in Cursor for shipping code. Same servers, different hosts.

Cursor vs Claude Desktop: when I use which

TaskCursor + MCPClaude Desktop + MCP
Edit code with AgentPrimary choiceRarely
Multi-file refactorsPrimaryNo
Research public docsGood with fetchGood with fetch
Long writing + citationsOKOften better UX
Quick issue triageGitHub MCP in IDENice for focus mode
Shared team config.cursor/mcp.json in repoPer-machine JSON

The protocol is the same. The difference is workflow: Cursor optimizes for in-repo execution, Claude Desktop for general knowledge work with attachments and longer chats.

Windows-specific setup notes (Jaipur dev machine, real paths)

Most MCP tutorials assume macOS. On Windows 11 this is what actually mattered for me:

Node on PATH for GUI apps: Cursor may not see Node if you only installed it for PowerShell. Install Node system-wide or launch Cursor from a shell where node -v works once to verify.

Defender and corporate AV: Child npx processes can be slow the first run while packages download. Whitelist %LocalAppData%\npm-cache if your network throttles.

Path separators: JSON requires escaped backslashes. I often use D:/projects/app instead of D:\projects\app to avoid escape mistakes.

Line endings: stdio servers do not care about CRLF inside file tools, but custom servers that read config files should normalize paths with path.resolve.

WSL vs native: You can run Linux MCP servers inside WSL while Cursor runs on Windows, but stdio bridging across boundaries is painful. Pick one environment per project when possible.

Recommended starter servers

ServerPackageGood forCaution
filesystem@modelcontextprotocol/server-filesystemRepo reads, docsScope to project root only
fetch@modelcontextprotocol/server-fetchPublic URL docsCan become an open proxy if misused
github@modelcontextprotocol/server-githubIssues, PRs, filesPAT scope and rate limits
postgres@modelcontextprotocol/server-postgresSchema-aware SQLRead-only DB user, row limits
memory@modelcontextprotocol/server-memoryPersistent notes across chatsDo not store secrets

Add servers incrementally. Ten tools the model understands beats forty tools it confuses.

Daily workflows that actually help

These are prompts I use after MCP is wired.

Refactor with grounding: "Find all imports of legacyAuth and propose a migration to sessionAuth. Read files before editing." Filesystem tools prevent invented paths.

PR triage: "List open PRs touching src/lib/blogs.ts and summarize review comments." GitHub MCP keeps links real.

Schema questions: "Explain foreign keys on Post and suggest an index for slug lookups." Postgres MCP with a read-only analytics replica works well here.

Docs that match production: Expose OpenAPI or GraphQL schema as a resource server. Ask "What is the request body for POST /v1/invoices?" Answers should cite your spec, not generic REST patterns.

Runbook assistance: Custom MCP server wrapping internal HTTP endpoints (staging health, feature flags). Keep write endpoints behind explicit approval.

For multi-step automation patterns, see Building AI agent workflows with MCP and the broader AI agents landscape in 2026.

Security rules I follow on every machine

MCP makes dangerous actions easy to describe in JSON. These are non-negotiables for me.

Chroot filesystem servers: Only pass directories you are willing to exfiltrate. Never point filesystem MCP at $HOME or /.

Read-only first: Database users without INSERT/UPDATE/DELETE. GitHub tokens without admin or delete scopes until you trust the workflow.

Secrets out of config: Environment variables or secret managers. If mcp.json is in git, reviewers should see commands, not tokens.

Approve writes: Keep Cursor's tool approval on for file writes, deploy scripts, issue creation. Convenience is not worth silent rm -rf.

Audit custom servers: Log tool name, args hash, user, timestamp. When something weird happens at 2 a.m., you want a trace.

Fetch server caution: Public URL fetching can leak internal URLs if the model guesses http://169.254.169.254. Block metadata endpoints at the network layer if you run fetch in CI.

Troubleshooting common failures

Server exits immediately on Windows

  • Run the same npx command in PowerShell. Missing Node or corporate proxy errors show up directly
  • Check antivirus blocking child processes spawned by Cursor
  • Prefer npx -y to avoid interactive install prompts hanging stdio

Tools listed but never called

  • Improve tool descriptions in custom servers. The model picks based on name + description match
  • Ask explicitly: "Use the GitHub MCP tool to list issues"
  • Reduce competing tools. Too many overlapping search_* tools confuse selection

Hallucinations persist after MCP

  • MCP is not automatic grounding. The model may skip tools unless the task requires them
  • Add resources (schemas, STYLE.md, ARCHITECTURE.md) not only reactive tools
  • Break tasks into steps: "First read file X, then propose patch"

Path and transport mismatches

  • stdio servers must speak JSON-RPC on stdout. Debug console.log in servers breaks the protocol (use stderr for logs)
  • Remote HTTP+SSE servers need matching client support in your host version. When in doubt, stdio locally

Postgres connection errors

  • Use SSL params your cloud provider requires
  • Verify VPN for internal replicas
  • Test with psql first. MCP errors are often just connection strings

Team rollout: project config in git

I check in .cursor/mcp.json with:

  • Server names and commands
  • Placeholder env vars documented in README
  • No tokens, no machine-specific absolute paths when avoidable

For mixed OS teams, document path overrides in a mcp.example.json and let developers copy locally. Some teams generate per-dev paths with a small setup script.

Code review for MCP config is like code review for CI: question new write tools, new network egress, and broad filesystem roots.

Shared mcp.example.json pattern

{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem", "/ABSOLUTE/PATH/TO/REPO"]
    }
  },
  "_comment": "Copy to .cursor/mcp.json and replace path. Do not commit tokens."
}

Document required env vars in your repo README: GITHUB_PERSONAL_ACCESS_TOKEN, DATABASE_URL, etc. New hires should be productive in one cp and one export, not a tribal Slack thread.

Building a custom server when reference ones fall short

Reference servers cover generic cases. Internal APIs need a thin custom MCP server.

Workflow I use:

  1. One tool = one side effect (e.g., get_staging_deploy_status)
  2. JSON Schema with tight enum and maximum bounds
  3. Stdio transport for local dev; HTTP only if shared
  4. Golden tests: prompt → expected tool → mocked HTTP

The MCP TypeScript SDK and Python SDK are enough for most wrappers. You are writing an adapter, not a new protocol.

flowchart LR
  A[Developer prompt] --> B[Cursor Agent]
  B --> C{Tool needed?}
  C -->|yes| D[MCP client]
  D --> E[Custom internal server]
  E --> F[Internal REST API]
  F --> E
  E --> D
  D --> B
  B --> G[Answer with live data]

MCP in Cursor vs built-in codebase indexing

Cursor already indexes your repo for chat. MCP still matters because:

  • Indexing is opaque; MCP tools are explicit and auditable
  • MCP reaches outside the repo (GitHub, DB, tickets, staging APIs)
  • You control scopes and credentials per server
  • Custom tools encode team workflows, not just file search

Use both. Indexing for fuzzy navigation; MCP for structured actions and authoritative reads.

Measuring whether MCP is worth it

Before you add ten servers, pick one metric:

  • Hallucination rate on file paths: should drop to near zero with filesystem MCP
  • Time to answer schema questions: should beat opening pgAdmin or a wiki
  • PR triage time: GitHub MCP should return real URLs you can click

I run a simple log for a week: did the agent call the right tool, did I approve a bad write, did I revert generated code? If MCP only saves thirty seconds per day, skip complexity. If it prevents one bad deploy suggestion per week, keep it.

Cost matters too. Tool results inflate context. Long SQL outputs or huge file reads burn tokens. Set server-side limits (line caps, LIMIT 50, truncate diffs) before the model sees them. This is the same discipline as pagination in REST APIs.

Prompt patterns that respect MCP limits

Bad prompt: "Fix everything wrong with auth."

Better prompt: "Read src/lib/auth.ts and prisma/schema.prisma. List three concrete bugs. Propose a patch for the highest severity only."

The second prompt nudges filesystem tools first, keeps scope bounded, and produces reviewable output. MCP enables grounding; your prompt still steers cost and quality.

For agent loops that chain multiple tools, see Building AI agent workflows with MCP. The approval and logging patterns there apply directly to Cursor sessions that start feeling too autonomous.

FAQ

Where does Cursor store MCP configuration?

Project-level: .cursor/mcp.json in your repo root. Global settings also exist under Cursor's app data directory on your OS. I use project config for team parity.

Can I use MCP without paying for Cursor Agent?

MCP tool use is tied to the host feature set. Cursor's Agent mode is where I see consistent tool invocation. Check your plan and Cursor docs for current limits; they change.

Does Claude Desktop support the same servers as Cursor?

Yes for most stdio servers launched via npx. The config file path and restart steps differ. HTTP+SSE support depends on host version.

How many MCP servers should I run at once?

Start with two to three. filesystem + one external system (GitHub or Postgres) is a solid baseline. Add custom servers when you have a repeated workflow, not before.

Written by Rohit Singh, software developer in Jaipur. More on the blog. I also build Study Stream Black, an offline desktop app for course libraries and timestamped notes.