Cursor supports Model Context Protocol servers, which means the AI inside your editor can do more than read files — it can query your database, hit internal APIs, or check a ticket tracker, all without you copy-pasting data into chat. Setup is simple once you've seen it once; the friction is almost entirely in the first configuration.
Why MCP in Cursor Matters (and When to Skip It)
Without MCP, Cursor's context is limited to what's in your open files and repo. With an MCP server wired in, you can ask "what's the schema for the orders table" and have it actually query Postgres, or "create a Linear ticket for this bug" and have it happen — the AI gains real tools, not just read access to text.
Skip it if your workflow never leaves the codebase itself — if you're not integrating external data or services, an MCP server is unnecessary configuration overhead.
Getting Started
MCP servers are configured in .cursor/mcp.json at the project level or globally in Cursor's settings:
{
"mcpServers": {
"postgres": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-postgres", "postgresql://localhost/mydb"]
},
"github": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-github"],
"env": { "GITHUB_TOKEN": "${GITHUB_TOKEN}" }
}
}
}
Restart Cursor after editing this file. You'll see connected servers listed in Settings → MCP, along with the tools each one exposes. From chat, the AI can now call those tools when relevant — you'll see a tool-call block appear before its response.
Core Concepts Every Developer Should Know
1. Project-scoped vs. global config. .cursor/mcp.json in a repo only applies to that project — commit it (minus secrets) so teammates get the same tools. Global config in Cursor's settings applies everywhere, useful for personal tools like a notes app or calendar.
2. Secrets never belong in the committed file. Reference environment variables (${GITHUB_TOKEN}) rather than hardcoding tokens — Cursor resolves them from your shell environment at launch.
3. Tool approval. By default Cursor asks before executing an MCP tool call that mutates state (creating a ticket, writing a row). Read-only tools can be set to auto-run; keep write operations gated unless you fully trust the server.
4. One server, one domain. Don't build a single MCP server that touches your database, your CI, and your ticket tracker — split by concern so a compromised or buggy server has limited blast radius.
Common Mistakes and How to Fix Them
Mistake 1: Forgetting to restart Cursor. Config changes to mcp.json don't hot-reload — a stale server list is almost always a missing restart, not a broken config.
Mistake 2: Overly broad database credentials. Pointing an MCP Postgres server at a connection string with full write access means one confused prompt can drop data. Use a read-only role for query-only use cases.
Mistake 3: No tool descriptions review. If a community MCP server's tool descriptions are vague, the AI will call them incorrectly. Read the server's tool schema before trusting it in a real workflow.
When Should You Use MCP in Cursor?
Use it when you're repeatedly pasting the same external data into chat — database schemas, API responses, ticket details. If you're doing that more than a few times a week, an MCP server pays for itself immediately.
In Practice
On suhailroushan.com's tooling I run a scoped read-only Postgres MCP server for schema questions during development, and keep write-capable servers (GitHub, deploy tools) behind explicit per-call approval. That split — freely query, carefully mutate — is the pattern I'd recommend to anyone wiring MCP into their own editor.
Start with one read-only server for the data source you reference most, confirm it behaves, then expand.