Cursor MCP servers that are worth the context

The trade nobody tells you about

Model Context Protocol lets Cursor talk to systems outside the editor: your issue tracker, your database, your browser, your docs. You add a server, the agent gains a set of tools, and it can now fetch a ticket instead of asking you to paste it.

The cost is that tool definitions live in the prompt. Names, descriptions, and parameter schemas for every enabled server, on every turn. A single well-behaved server with six tools is cheap. Four sprawling servers with twenty tools each is not, and the symptom is subtle: the agent gets slightly worse at the coding task, picks the wrong tool, or forgets an instruction you gave it ten messages ago. Nobody connects that to the MCP config, because the config was working fine last month with two servers.

Which Cursor MCP servers actually earn their slot

The ones that close a loop the agent otherwise cannot close. From what we see in teams:

• A database server against a read-only replica. The agent checks the real schema instead of guessing from a stale migration file. This one changes behaviour more than any other.
• An issue tracker, but only if your tickets contain real acceptance criteria. If your tickets say "fix login", the server adds nothing but tokens.
• A browser or preview server for frontend work, so the agent can see what it built rather than assert that it works.
• Documentation servers for fast-moving frameworks, where the model's training data is behind your actual version.

The servers that disappoint are the ones wrapping something the terminal already does. A git MCP server is usually worse than letting the agent run git log --oneline -20, because the shell version is flexible and the wrapper is not.

Configure it per project, not globally

Put the config in the project, commit it, and keep the enabled set narrow. Cursor reads MCP configuration from a JSON file, and the shape is the same one most MCP clients use:

{ "mcpServers": { "docs": { "command": "npx", "args": ["-y", "some-docs-server"] } } }

Never put credentials in a committed file. Use environment variables and document which ones a new joiner needs. We have walked into repos where an API token sat in a checked-in MCP config for months. It happens because the file feels like editor settings rather than code, and nobody reviews editor settings.

Where this breaks

Servers fail quietly. If a process crashes on startup, the tools disappear and the agent carries on without them, usually by guessing. If the answers suddenly get vague, check that the server is actually running before you blame the model.

Permissions are the other one. An MCP server runs with your access. A database server pointed at production with write access is a genuine incident waiting for a confused agent and a badly worded prompt. Read-only replica, always, or a scoped account at minimum.

And treat tool output as untrusted input. Text returned by an external server can contain instructions aimed at the agent. That is not paranoia, it is the same reason you do not eval a webhook body.

What to do next

Open your current MCP config and disable everything you have not consciously used in the past two weeks. Work for three days. If nothing hurts, that is your baseline. Then add servers back one at a time, and only when you can name the specific question the agent kept getting wrong without it.

If you want help putting this into practice, talk to us.