Cursor's MCP integration is specifically tuned for an IDE workflow — tools that read your project, query external services, or take actions relevant to active development — which shapes what's actually worth connecting compared to a general-purpose chat client.
Cursor supports MCP servers configured per-project or globally, exposing their tools to Cursor's AI features within the IDE context. This lets Cursor's model call out to project management tools, documentation search, databases, or any other MCP-exposed capability directly during a coding session, without leaving the editor.
Why MCP With Cursor Matters (and When Built-In Tools Suffice)
For development workflows needing access beyond what Cursor's built-in capabilities (file editing, terminal, codebase search) cover — querying a project management tool for ticket context, checking a database schema, searching internal documentation — MCP servers extend the IDE's AI assistant with exactly the external context or actions your workflow actually needs.
Built-in tools suffice, and adding an MCP server is unnecessary, for capabilities Cursor already handles natively (file operations, running terminal commands, codebase-wide search) — check what's already available before building or connecting a server that duplicates existing functionality.
Getting Started with MCP and Cursor
Project-scoped configuration, in .cursor/mcp.json within a project:
{
"mcpServers": {
"linear": {
"command": "npx",
"args": ["-y", "@linear/mcp-server"],
"env": {
"LINEAR_API_KEY": "${LINEAR_API_KEY}"
}
}
}
}
Connecting a remote, URL-based server:
{
"mcpServers": {
"internal-docs": {
"url": "https://docs-mcp.internal.example.com/mcp"
}
}
}
Core MCP With Cursor Concepts Every Developer Should Know
Project-scoped configuration (.cursor/mcp.json in the repo) lets different projects have different connected servers, appropriate since a project's actual external dependencies (which ticket system, which database, which internal APIs) vary — this scoping avoids polluting every project with tools only relevant to one specific codebase.
Environment variable interpolation in the config keeps secrets out of the committed config file itself, referencing environment variables (like an API key) rather than hardcoding sensitive values directly into a file that might be committed to version control — this is a meaningful security practice worth following consistently.
Tool usage within an IDE context benefits from tools that are narrowly scoped to development-relevant actions, since Cursor's assistant is operating within an active coding session — a tool that fits naturally into "look up this ticket," "check this schema," or "search these docs" integrates more usefully than a broad, general-purpose tool that doesn't map onto typical IDE workflow moments.
Server startup and reliability affect the actual development experience directly, since a slow-starting or flaky MCP server introduces friction into every coding session that depends on it — treating connected MCP servers with the same reliability expectations as any other development tool dependency (fast to start, predictable, well-maintained) matters more in an IDE context than in an occasional-use chat client.
Common Mistakes Connecting MCP to Cursor and How to Fix Them
Mistake 1: hardcoding API keys or secrets directly in .cursor/mcp.json, risking accidental commit of sensitive values to version control. Fix: use environment variable interpolation and keep the actual secret values out of the committed config.
Mistake 2: connecting servers globally that are only relevant to one project, cluttering every coding session with tools that don't apply to the current codebase. Fix: use project-scoped configuration for project-specific tools, reserving global configuration for genuinely universal tools.
Mistake 3: connecting an unreliable or slow-starting server, degrading the responsiveness of every coding session depending on it. Fix: verify server reliability and startup time before adopting it as part of a regular development workflow, and remove or fix ones causing friction.
When Should You Use Project-Scoped Configuration Instead of Global?
Use project-scoped configuration (.cursor/mcp.json in the repo) for tools specific to that project's external dependencies — its ticket system, its database, its internal APIs — so other projects aren't cluttered with irrelevant tools. Use global configuration for genuinely universal tools you want available across every project you work on, where the tool isn't tied to any single codebase's specific context.
MCP With Cursor in Production
Keep secrets out of committed configuration files using environment variable interpolation consistently, and scope servers to the project level when their relevance is project-specific rather than universal. Also periodically review connected servers for reliability, since a flaky server degrades the actual coding experience in a way that's easy to underestimate until it's actively causing friction.
If you're setting up Cursor for a project with external dependencies (a ticket system, an internal API, a specific database), project-scoped MCP configuration is the right starting point — check what Cursor already handles natively first before reaching for a new server.