MCP Servers in Cursor: The 6 That Actually Change How You Build

What MCP Actually Does for Cursor

Cursor's AI agent is genuinely useful out of the box. It can read your code, suggest changes, and reason about architecture. What it cannot do is talk to anything outside the editor: your database, your GitHub repos, the live web, your error monitoring. Without a way to reach those systems, the agent is limited to whatever context you manually copy and paste in.

MCP (Model Context Protocol) fixes that. It is an open standard created by Anthropic that lets AI tools connect to external services through a unified interface. When you configure an MCP server in Cursor, you give the agent a set of real capabilities. It can run a database query, create a GitHub issue, search the live web, or debug a Sentry error directly from the chat window.

The ecosystem now has thousands of MCP servers. Most of them are not worth your attention. This guide covers the six that deliver the most immediate workflow improvement for developers building with AI.

How MCP Works in Cursor

The architecture is straightforward. When you configure an MCP server, Cursor launches it as a child process (for local servers) or connects to it over HTTP. The server registers a list of actions it can perform. Those tools become part of the agent's available toolset, and the agent decides when to use them based on what you ask.

Your Prompt
    |
    v
Cursor Agent
    |
    v
MCP Client (built into Cursor)
    |
    v
MCP Server (GitHub / database / browser / etc.)
    |
    v
The actual tool (GitHub API, your DB, the web)

There are two configuration levels:

• Global (~/.cursor/mcp.json): servers available across all your projects. Good for GitHub, web search, and general-purpose tools.
• Project-level (.cursor/mcp.json in your repo root): servers scoped to a specific codebase. Good for database connections and project-specific APIs. Commit the file with placeholder credentials so your teammates get the same setup without exposing secrets.

Start with a few focused servers and add more only when a workflow calls for them. A smaller toolset makes it easier to understand what the agent can access and to keep irrelevant tools disabled.

Adding Your First Server

The fastest path: open Cursor Settings with Cmd+, (Mac) or Ctrl+, (Windows/Linux), navigate to Tools & MCP, click + Add New MCP Server, and fill in the command. Alternatively, create the config file directly. A local stdio server uses this basic shape. Remote servers use a URL instead, as the GitHub example below shows.

{
  "mcpServers": {
    "server-name": {
      "command": "npx",
      "args": ["-y", "package-name"],
      "env": {
        "API_KEY": "your-key-here"
      }
    }
  }
}

Keep API keys out of version-controlled files. For project-level configs you commit to git, use placeholder values and document the required environment variables in your README.

The 6 MCP Servers Worth Installing

1. GitHub MCP: Stop Switching to the Browser

The official GitHub MCP server is the single most impactful addition for most developers. Once connected, the agent can create issues, search repos, manage pull requests, and check workflow runs without leaving the editor.

The practical value: you are debugging and you find a bug in a dependency. Instead of opening a browser, navigating to GitHub, and creating an issue manually, you prompt: "Create a GitHub issue for this. The createUser function silently swallows validation errors when the email field contains a plus sign." Done in 10 seconds.

{
  "mcpServers": {
    "github": {
      "url": "https://api.githubcopilot.com/mcp/",
      "headers": {
        "Authorization": "Bearer YOUR_GITHUB_PAT"
      }
    }
  }
}

Create a dedicated personal access token and grant only the permissions required by the tools you plan to use. Never reuse a token with broader access than you want the agent to have.

Example prompts that work well:

• "Search this repo for all places where we call the Stripe webhooks handler and check they all validate the signature first."
• "What PRs are open against main right now? List them with their status checks."
• "Create an issue for the bug I just fixed: describe what was broken based on this commit."

2. SQLite MCP: Query a Local Database From Chat

Database questions are one of the most common tasks where developers context-switch out of the editor. Running a query to understand data shape, checking what a migration actually changed, or investigating why a user's account is in a broken state often means opening a separate client.

For a local SQLite database, the archived MCP reference server can query the file directly. It is a reference implementation for local development and evaluation, not a maintained production connector. Install uv first so the uvx command is available.

{
  "mcpServers": {
    "sqlite": {
      "command": "uvx",
      "args": ["mcp-server-sqlite", "--db-path", "/path/to/database.db"]
    }
  }
}

Security rule that matters: Connect to your development or staging database, not production. The agent will run whatever queries it thinks are relevant. Giving it production credentials turns one bad prompt into an expensive mistake. Production access should require explicit approval flows, not an always-on MCP connection.

Example prompts that work well:

• "Show me the schema for the users table and explain any columns I should know about."
• "User ID 4521 can not log in. Query the database and tell me what state their account is in."
• "How many users signed up this week versus last week? Break it down by day."

3. Context7 MCP: Version-Accurate Documentation

This one fixes a problem you have probably hit without realizing what caused it: asking the agent how to do something in a framework and getting an answer that was correct in an older version but is now wrong or deprecated.

Context7 fetches current, version-specific documentation at query time and injects it into the agent's context. Instead of relying on training data alone, you can retrieve current docs for the version you are using.

{
  "mcpServers": {
    "context7": {
      "command": "npx",
      "args": ["-y", "@upstash/context7-mcp@latest"]
    }
  }
}

No API key is required for basic use. Context7 documents an optional key for higher rate limits and private repositories.

Example prompts that work well:

• "Using Context7, look up how to implement route handlers with streaming in Next.js 15 App Router."
• "What changed between React 18 and 19 for concurrent rendering? Use current docs."
• "Get the current Prisma docs for composite unique constraints."

4. Playwright MCP: A Real Browser in Your Workflow

The Microsoft Playwright MCP server gives the agent control over a real browser. It can navigate to a URL, interact with elements, take screenshots, and verify UI behavior. It is a testing tool, but the day-to-day use cases go further.

{
  "mcpServers": {
    "playwright": {
      "command": "npx",
      "args": ["-y", "@playwright/mcp@latest"]
    }
  }
}

No credentials needed for this one. The browser runs locally.

The workflow shift: instead of spinning up your app, opening a browser, manually testing the flow, and then coming back to the editor to fix the bug, you can ask the agent to navigate your local app and tell you exactly what it sees. Bugs that only appear in the real browser, not in unit tests, are the hardest to catch. This makes them catchable without leaving the editor.

Example prompts that work well:

• "Navigate to localhost:3000, log in as test@example.com with password 'test123', and verify the dashboard loads without errors."
• "Take a screenshot of the checkout page at mobile viewport width and flag any layout issues."
• "Walk through the signup flow and tell me the exact error message shown when I submit an invalid email format."

5. Brave Search MCP: Live Web Access With No Tracking

The agent's training data has a cutoff. New library releases, recent CVEs, current benchmarks, and anything that happened in the last few months is not in it. Brave Search gives the agent a live web search capability using Brave's independent search index.

{
  "mcpServers": {
    "brave-search": {
      "command": "npx",
      "args": ["-y", "@brave/brave-search-mcp-server@latest", "--transport", "stdio"],
      "env": {
        "BRAVE_API_KEY": "your_brave_api_key"
      }
    }
  }
}

Create a Brave Search API key at brave.com/search/api.

This server is most valuable for research tasks: understanding what a new library actually does, checking whether a dependency has recent security advisories, or finding current best practices for something the model might have outdated opinions on.

Example prompts that work well:

• "Search for any recent security advisories for Express.js and summarize the critical ones."
• "Find the latest benchmarks comparing Bun and Node.js for HTTP servers. What does the current data say?"
• "Search for the Anthropic MCP spec update from last month and summarize what changed."

6. Sentry MCP: Debug From the Source

If your production app reports errors to Sentry, this server is a significant quality-of-life improvement. The usual debugging loop is: see error in Sentry, copy the stack trace, paste it into the agent chat, describe additional context, get a guess. With Sentry MCP, the agent can pull the stack trace, breadcrumbs, environment, and related events, then work from the real data.

{
  "mcpServers": {
    "sentry": {
      "command": "npx",
      "args": ["-y", "@sentry/mcp-server@latest"],
      "env": {
        "SENTRY_ACCESS_TOKEN": "your_sentry_user_auth_token"
      }
    }
  }
}

Generate a dedicated user auth token in Sentry and grant only the scopes listed in Sentry's MCP documentation. The stdio server reads it from SENTRY_ACCESS_TOKEN. Sentry's AI-powered search tools also require an LLM provider, while the other tools work with the Sentry token alone.

Example prompts that work well:

• "Pull the latest unresolved production errors tagged payment and rank them by frequency."
• "For Sentry issue FRONTEND-4821, get the full context and suggest a fix."
• "Did the error rate spike after our deploy at 14:00? Check Sentry for the last 3 hours."

A Minimal Starting Config

If you are setting up MCP for the first time, start with three servers: GitHub, Context7, and Brave Search. These cover the most frequent context-switching scenarios without touching anything sensitive.

Save this as ~/.cursor/mcp.json to make the servers available across projects:

{
  "mcpServers": {
    "github": {
      "url": "https://api.githubcopilot.com/mcp/",
      "headers": {
        "Authorization": "Bearer YOUR_GITHUB_PAT"
      }
    },
    "context7": {
      "command": "npx",
      "args": ["-y", "@upstash/context7-mcp@latest"]
    },
    "brave-search": {
      "command": "npx",
      "args": ["-y", "@brave/brave-search-mcp-server@latest", "--transport", "stdio"],
      "env": {
        "BRAVE_API_KEY": "your_brave_api_key"
      }
    }
  }
}

Then add the database connector as a project-level config for any codebase with a database, and Playwright when you need it for testing. Sentry goes in when you are actively debugging production issues.

The Security Rules That Actually Matter

MCP servers have real access to real systems. The risks are proportional to what you grant them. Three rules cover most failure modes:

1. Start read-only. For any service that supports it, configure read access first. Observe how the agent uses the tools before giving it write permissions. The GitHub MCP can create issues, merge PRs, and push code, but it does not need all of that for most debugging workflows.
2. Use dedicated tokens with minimum scope. Create a new API key for each MCP server with only the permissions it actually needs. Never reuse a token that has broader access. If the config file is ever accidentally committed or leaked, the blast radius is limited.
3. Never connect to production databases. Connect to dev or staging. Production database access through an always-on agent connection is an operational risk that outweighs the convenience.

What's in Part 3

MCP in Cursor is one piece of the advanced workflow. Part 3 of the Building with Cursor series goes deeper: how to choose between models for different tasks, how to use Cursor Hooks to automate repetitive parts of your loop, and how to run parallel agents on the same codebase using git worktrees. Subscribe to AI Builder Club to get it when it drops.

If this guide got your MCP setup working and you want to keep developing your AI-assisted workflow, join AI Builder Club. It is a community of developers sharing what's actually working in production, not just demos.