MCP Servers in Cursor: Setup, Configuration, and Security (2026 Guide)

Out of the box, Cursor's AI agent only knows about your codebase. That's it. It can't see your Postgres tables, has no clue what GitHub issues are piling up, and definitely can't pull design tokens from Figma. MCP servers are what bridge that gap. They're lightweight programs that plug external tools into Cursor through one standardized protocol—the Model Context Protocol—so the agent can query databases, file issues, or fetch API data right from the editor.

Some quick history. Anthropic open-sourced MCP in November 2024. OpenAI adopted it by May 2025, and Google DeepMind brought Gemini support in April. Then, in December 2025, Anthropic donated the whole thing to the Agentic AI Foundation (under the Linux Foundation), co-founded with Block and OpenAI. That move was significant. MCP went from being Anthropic's project to a genuinely vendor-neutral standard.

Cursor has emerged as one of the go-to MCP clients among IDEs. But getting it set up properly—and understanding what can go wrong from both a config and security standpoint—takes more than just pasting a JSON snippet you found on Reddit.

How MCP Actually Works Inside Cursor

MCP defines three moving pieces. Hosts are the application—Cursor. Clients are connectors inside the host that handle individual server connections. Servers are the lightweight programs on the other end, exposing tools via JSON-RPC 2.0.

Image source

In practice? You open Cursor. Its Agent scans your enabled MCP servers, loads the tools they expose, and figures out which ones to call as part of whatever task it's working on. Head over to Cursor Settings > Tools & MCP and you'll see every loaded server with a status indicator. You can flip individual tools on or off from that panel.

Servers can expose three types of things:

• Tools are the big one—executable functions like create_issue or run_query. Cursor has supported tools since the early days of its MCP integration.
• Resources are contextual data: file contents, database schemas, configuration details. Support for resources arrived in Cursor v1.6 (September 2025).
• Prompts let servers offer reusable templates and predefined workflows to the client.

For a more thorough walkthrough of MCP architecture and server primitives, check out our guide on MCP and How It Works.

Transport Types: How Cursor Talks to MCP Servers

Three options here. Which one you pick depends on a simple question—local server or remote?

Our recommendation: stdio for local experimentation. Streamable HTTP for literally everything else.

Setting Up MCP Servers

The Easy Way: One-Click Deep Links

More and more MCP servers now have an "Add to Cursor" button sitting right on their docs page. Click that, and Cursor opens a dialog with the server name, transport, and URL already filled in. Click Install. That's the whole process.

Servers requiring authentication will trigger a browser-based OAuth flow, and Cursor stores the resulting credentials for you. If you're a server developer wanting to add these deep links, the Cursor MCP documentation explains how.

Manual Setup: stdio for Local Servers

Open Cursor Settings > Tools & MCP, hit New MCP Server (which drops you into mcp.json), or just create the file manually. Put it at .cursor/mcp.json inside your project for project-scoped config, or ~/.cursor/mcp.json for global.

Here's what a GitHub MCP server looks like running through Docker:

{
  "mcpServers": {
    "github": {
      "command": "docker",
      "args": [
        "run", "-i", "--rm",
        "-e", "GITHUB_PERSONAL_ACCESS_TOKEN",
        "ghcr.io/github/github-mcp-server"
      ],
      "env": {
        "GITHUB_PERSONAL_ACCESS_TOKEN": "<YOUR_TOKEN>"
      }
    }
  }
}

The fields, briefly:

• "command" — What Cursor runs to start the server. npx, docker, python, node—whatever the server expects.
• "args" — Arguments forwarded to that command.
• "env" — Environment variables passed in at runtime. Put API keys here. Not in your shell profile, not in a .env file that gets committed accidentally—here.

Manual Setup: Streamable HTTP for Remote Servers

Way simpler. Just a URL and optional headers:

{
  "mcpServers": {
    "remote-api": {
      "url": "https://mcp.example.com/mcp",
      "headers": {
        "Authorization": "Bearer <YOUR_API_KEY>"
      }
    }
  }
}

No command. No args. Cursor hits the HTTP endpoint directly.

Project-Level vs. Global Config

Project config (.cursor/mcp.json in the repo root) affects only that project. Global config (~/.cursor/mcp.json) applies everywhere. Same server defined in both files? Project-level wins.

When Things Break: Troubleshooting MCP in Cursor

The 40-Tool Limit

Cursor has a ceiling of roughly 40 active tools across all your MCP servers combined. Exceed it and two things happen: you get a warning, and the agent silently loses access to some tools. It just can't see them anymore.

Why does the limit exist? Each tool definition burns context tokens. And once you shove 40+ tool descriptions into a prompt, the LLM's ability to pick the right one deteriorates noticeably.

What to do about it: open each server in settings and switch off the tools you're not actively using. And as a general rule, a server exposing 5 to 10 well-defined tools will serve you better than one megaserver trying to do 30 things.

"No Tools Found" or Silent Failures

Your MCP server didn't start. Cursor shows no error. No warning. Nothing. You just notice that tools aren't showing up.

Nine times out of ten, the problem is one of these: Node.js or Python isn't installed (or isn't on your PATH). The package version in your config doesn't exist. Or an environment variable you referenced is either empty or completely missing.

Fastest way to debug: copy the command from your mcp.json verbatim and run it in a terminal. Like this: npx -y @modelcontextprotocol/server-postgres postgresql://localhost/mydb. Whatever error Cursor was swallowing will print right to your screen.

SSH and Remote Environments

stdio transport and remote environments do not get along. The subprocess launches on the remote side, but Cursor expects it locally. You end up with intermittent connection failures that are incredibly annoying to track down.

Just use Streamable HTTP. Deploy the MCP server as a hosted endpoint and point Cursor at the URL. Saves hours of debugging.

Tiny Config Mistakes That Waste Your Afternoon

We keep running into the same three:

• Server name + tool name over 60 characters. Cursor throws an error, but the message isn't particularly helpful.
• Missing the "mcpServers" root key. No error. No warning. Cursor just ignores the entire file. You'll stare at your perfectly formatted JSON wondering why nothing is loading.
• Forgetting -y with npx. The process hangs forever. Why? Because npx is waiting for you to confirm a package install, but there's no interactive terminal for you to type "y" into.

MCP Security: The Part You Can't Afford to Skip

MCP servers run code with your credentials. Let that sink in for a moment. Whatever permissions you hand a server—database access, GitHub tokens, API keys—it will use them. Every MCP server is, for all practical purposes, a fully trusted integration. If a server is compromised or malicious, it has everything you gave it.

2025 was a rough year for Cursor MCP security. Researchers published multiple critical CVEs, and each one exposed a fundamentally different attack surface:

• CVE-2025-54136, dubbed "MCPoison" — Check Point Research uncovered that Cursor pinned trust to the MCP server's key name in the config file, not to the actual command being run underneath. Concrete impact: someone could push a modified .cursor/mcp.json to a shared repository, swapping a legitimate command for a malicious one. Cursor would still run it without asking for approval, because the key name hadn't changed. Fixed in Cursor 1.3, July 2025.
• CVE-2025-54135, called "CurXecute" — AIM Security pulled off something wild. They showed that poisoned content inside Slack messages, when summarized by Cursor's agent, could rewrite your MCP configuration file and auto-launch rogue servers. A Slack message. That's the attack vector. Fixed in Cursor 1.3.9.
• CVE-2025-59944 — Lakera found a case-sensitivity trick targeting macOS and Windows. Attackers could overwrite .cursor/mcp.json by writing to .cUrSoR/mcp.json—the filesystem treated them as the same path. Fixed in Cursor 1.7.
• CVE-2025-64106 — Cyata Security discovered that the MCP installation dialog in Cursor could be spoofed. It would show a trusted name like "Playwright" to the user while executing completely different, attacker-controlled commands behind the scenes. Cursor shipped a fix in version 2.0. Took them just 48 hours from disclosure.

Security Best Practices

• Kill auto-run mode. Force the agent to get explicit approval before every tool invocation. Yes, every single one. The friction is worth it.
• Least privilege for credentials, always. Read-only GitHub tokens for anything search-related. Read-only database users for schema browsing. Never grant write access unless the use case absolutely demands it.
• Pin package versions. npx -y mcp-server@1.2.3—not @latest. A compromised latest tag is a real supply-chain attack vector, and you don't want to find out the hard way.
• Read the source code of third-party servers. If you wouldn't run an unvetted npm package in production, you shouldn't run an unvetted MCP server in your IDE either. Same risk profile.
• Stay on the latest Cursor version. Full credit to the Cursor team—they patched every one of these CVEs within days. But those patches only help if you actually update.
• Treat .cursor/mcp.json changes in Git like infrastructure changes. Same review rigor you'd apply to a Terraform file or a GitHub Actions workflow.

More details on these topics in our guides on enterprise MCP security and access control patterns.

Scaling MCP from Developer to Enterprise

For a single developer, MCP is great. Set it up once, enjoy the productivity boost, move on. But scaling to a team of 20? Or 200? That's where the pain starts.

API keys end up scattered across individual laptops. There's no centralized view of which servers and tools are active across the org. Zero audit trail. And when somebody leaves the company—or even just switches teams—you're stuck rotating credentials in dozens of individual Cursor config files spread across who-knows-how-many machines.

An MCP Gateway puts a layer between your agents and your MCP servers that handles all of the above: centralized authentication, role-based access, observability, and policy enforcement.

TrueFoundry's MCP Gateway does exactly that. Developers authenticate once against the gateway. From that point on, the gateway manages every downstream OAuth token and credential for them. Administrators define per-server access controls and permissions through RBAC. Every tool call—every single one—gets logged with full request-level tracing.

One feature worth calling out specifically: Virtual MCP Servers. The gateway can expose a scoped subset of tools from the servers behind it. Suppose you want an agent that can read GitHub issues but must never, under any circumstances, delete a repository. You don't enforce that via a system prompt the LLM might ignore. The gateway enforces it at the protocol level. The "delete repo" tool simply doesn't exist from the agent's perspective.

Organizations already running TrueFoundry's AI Gateway for LLM routing and cost control get native integration with MCP Gateway. One control plane covering models, tools, and agents.

Cursor can also connect directly to TrueFoundry's AI Gateway for centralized LLM routing, cost tracking, and key management.

Wrapping Up

MCP gives Cursor the ability to interact with real, external tools—not just your source files. Individual setup takes minutes. The actual engineering challenge shows up later: governance, credential management, access control, and observability at team scale.

Start small. One or two servers. Use deep links where available. Respect the 40-tool limit. Stay updated to keep ahead of security patches. And if you're deploying MCP across a team or org, look into an MCP Gateway before the credential sprawl problem solves itself by turning into a security incident.

Explore TrueFoundry's MCP Gateway or book a demo to see it in action.

Frequently Asked Questions

What exactly is an MCP server in Cursor?

A lightweight program connecting Cursor's AI agent to an external tool or data source via the Model Context Protocol. It exposes functions (called "tools") that the agent discovers and calls during workflows. GitHub, Postgres, Figma, Slack—they all have MCP servers available.

How do I add one to Cursor?

Three ways. One-click deep-link buttons on the server's docs page (easiest). The Cursor Settings > Tools & MCP > New MCP Server UI. Or manually creating .cursor/mcp.json (project-scoped) or ~/.cursor/mcp.json (global).

What's the tool limit?

Around 40 active tools across all servers. Past that, the agent gets worse at picking the right tool because context fills up. Turn off what you're not using.

Does Cursor handle MCP resources and elicitation?

Yes. Resources shipped in v1.6 (September 2025)—contextual data like schemas and file contents. Elicitation landed in v1.5 (August 2025)—servers can ask for structured user input mid-execution.

Are MCP servers safe to use in Cursor?

Depends on your setup. MCP servers run code with the permissions you provide. Researchers found multiple critical vulnerabilities in 2025, all patched quickly. Keep Cursor current, disable auto-run, restrict credentials, pin package versions, and audit third-party servers before adding them.

How do large teams manage MCP servers?

Through an MCP Gateway. TrueFoundry's gateway centralizes auth, enforces RBAC, and logs every tool invocation. Admins control exactly which teams get access to which servers. See our MCP gateways comparison for a detailed breakdown.