How Does Cursor Implement MCP, and What Are Its Real Limits?

Cursor implements the Model Context Protocol (MCP), the open standard Anthropic created in November 2024, as a first-class feature of its AI IDE: servers plug into the agent through a config file or a click, and their tools become actions the model takes inside the editor. Cursor documents the integration in its official MCP docs, ships a plugin marketplace around it, and supports the protocol across stdio, SSE, and streamable HTTP transports.

The implementation has edges the documentation states quietly and this page states plainly. Cursor caps active tools at 40 across all connected servers (the ceiling independent testing reports; TrueFoundry, April 2026), and past the cap the agent loses access to tools without telling you which. Two config files can define the same server, and one silently wins. The free plan connects no custom servers at all.

This page covers how Cursor speaks the protocol, where the configuration lives and which scope takes precedence, the tool ceiling and its mitigation, the 2026 plugins and marketplace ecosystem, which servers pair best, what MCP costs on each plan, and how Cursor’s MCP experience compares with the other clients. The install steps and the error fixes live on the dedicated Cursor setup guide.

All MCP clients compared · What MCP is and how it works

What Is MCP in Cursor?

MCP in Cursor is the protocol layer that connects the IDE’s AI agent to external tools and data sources: databases, GitHub, Figma, browsers, and any other MCP server. Cursor contains the MCP client; you add the servers; the agent discovers their tools and calls them while it codes.

The division of labor follows the protocol’s standard shape. Cursor hosts the model and speaks MCP on its behalf. Each server exposes one tool or data source. The model decides when a task needs a tool, Cursor formats the call, and the result returns into the agent’s context.

Invocation is implicit, which surprises people coming from plugin systems: you do not call a tool, you ask for an outcome. MCP tools belong to Cursor’s agent, the agent reads every connected server’s tool descriptions, and “check the open issues on this repo” triggers the GitHub server because the description matches the task. Naming the server in the prompt steers the choice when two servers overlap. Everything below is what Cursor specifically does with them.

Which Transports and Primitives Does Cursor Support?

Cursor supports all three MCP transports, stdio for local servers and SSE and streamable HTTP for remote ones, with OAuth handled in the browser on first connection to a remote server.

When did Cursor add MCP support?

Cursor has supported MCP since early 2025, and the implementation gained deeplinks, elicitation, resources, and a plugin marketplace within eighteen months. Community setup guides date from February 2025, one-click deeplink installs were documented by June 2025, elicitation support landed in v1.5 in August 2025, resources followed in v1.6 in September 2025, and the plugins marketplace turned MCP into a distribution layer in 2026, the same year Cursor retired its own server list in favor of cursor.directory. The trajectory matters for one practical reason: a Cursor MCP tutorial ages in months, and the publication date is the first thing to check on any guide.

How does Cursor approve tool calls?

Cursor asks before each tool call by default: the agent proposes the call, you approve it, and the result returns to the conversation. An auto-run option removes the per-call prompt for users who accept the tradeoff, and the tradeoff is real: approval is the last human control between an injected instruction and an executed action, the pattern every server page on this site prices. Write-capable servers argue for keeping the prompt; read-only ones are where auto-run costs least.

The primitive support is the quiet differentiator. Resources and elicitation shipped in consecutive releases in late 2025 (TrueFoundry, April 2026), and most clients still expose tools alone, so a server’s richer capabilities work in Cursor where they silently vanish elsewhere.

Where Does Cursor Store MCP Configuration?

Cursor reads MCP servers from two files: .cursor/mcp.json in the project root and ~/.cursor/mcp.json in your home directory, and the project file wins when both define the same server (TrueFoundry, April 2026).

The two scopes are a feature, not redundancy:

• Project scope (.cursor/mcp.json) commits with the repository, so every developer who clones the project inherits its servers. A team’s Postgres, GitHub, and Playwright setup becomes part of the codebase, configuration as code.
• Global scope (~/.cursor/mcp.json) follows you across projects, the right home for personal servers a repo should not impose on teammates.

Which mcp.json wins when both define a server?

The project file wins: when .cursor/mcp.json and ~/.cursor/mcp.json define the same server, Cursor loads the project’s version. The precedence cuts both ways: a project file pins the team to a known-good config, and a stale project file silently overrides the fixed global one you just corrected. The symptom is a server that works in every project except one, and the project’s .cursor/mcp.json is the first place to look, because the global file you edited never loaded for that workspace.

The file behaves identically across macOS, Windows, and Linux, with one Windows-specific edge: Cursor is a Windows GUI application, so the stdio servers it launches run with Windows-side runtimes, not the Node inside your WSL distribution. A server installed only in WSL is invisible to Cursor’s spawn call, the same GUI-versus-shell gap behind the error strings routed to the setup guide.

The file’s canonical shape is the same in both scopes, one entry per server:

{
  "mcpServers": {
    "github": {
      "command": "docker",
      "args": ["run", "-i", "--rm", "-e", "GITHUB_PERSONAL_ACCESS_TOKEN", "ghcr.io/github/github-mcp-server"],
      "env": { "GITHUB_PERSONAL_ACCESS_TOKEN": "$GITHUB_TOKEN" }
    },
    "slack": {
      "type": "http",
      "url": "https://mcp.slack.com/mcp"
    }
  }
}

A local server carries a command, args, and env; a remote server carries a type and a url, with OAuth handled in the browser. The shape is the reference.

Secrets follow the scope rule’s sharp edge: a project file commits to the repository, so keys belong in environment references, never in literal strings inside .cursor/mcp.json.

What Is Cursor’s Tool Limit?

Cursor caps active tools at 40 across all connected MCP servers combined. Past the cap, Cursor shows a warning and the agent silently loses access to some tools (TrueFoundry, April 2026). The failure mode is the dangerous part: nothing errors, the model simply cannot see tools it could see yesterday.

Why does the 40-tool limit exist?

The limit exists because tool definitions consume context tokens on every request, and tool choice degrades as the lineup grows. Every definition consumes tokens before any call happens: name, description, and parameter schema travel in the prompt on each request, and a single verbose server’s definitions run to thousands of tokens, the cost the GitHub server’s 17,600-token default toolset demonstrates. Past 40 descriptions, two costs compound: the fixed token spend rises, and the model’s ability to pick the right tool from the lineup measurably degrades. The cap trades raw tool count for tool-choice quality, the same tradeoff behind every client’s tool-loading strategy.

Three practices keep a working setup under it:

1. Toggle per-server tools off in settings. Each server’s entry in Cursor Settings exposes its tool list; switch off what the current work does not use.
2. Prefer focused servers. A server exposing 5 to 10 well-defined tools serves the agent better than a megaserver exposing 30, and it spends a fraction of the budget. The GitHub server’s configurable toolsets exist for exactly this.
3. Scope heavyweight servers to the projects that need them. The project file makes this mechanical: the browser-automation stack loads in the web project and nowhere else.

How Do Plugins, Deeplinks, and the Marketplace Change Cursor MCP?

As of 2026, Cursor wraps MCP in a distribution layer: one-click deeplinks install single servers, plugins bundle servers with rules and skills, and the Cursor Marketplace distributes both. Manual mcp.json editing remains the fallback and the power path; the ecosystem grew around it, not over it.

Three layers, smallest to largest:

• Deeplinks install one server with one click. The format is documented and stable: cursor://anysphere.cursor-deeplink/mcp/install?name=$NAME&config=$BASE64_ENCODED_CONFIG, the config being the same JSON an mcp.json entry holds, Base64-encoded (Cursor docs). Server vendors embed the link as an Add to Cursor button, the path the Slack integration repo ships.
• Plugins bundle MCP servers with rules, skills, agents, commands, and hooks in a directory carrying a .cursor-plugin/plugin.json manifest, installable at project or user scope. A team’s whole working setup ships as one unit.
• The Cursor Marketplace distributes plugins publicly, with MCP coverage spanning messaging, voice, verification, and 30+ products at launch, and team marketplaces distribute them privately from a GitHub repository through the dashboard (Cursor docs, plugins).

The discovery layer consolidated in 2026: Cursor’s own cursor/mcp-servers GitHub list was deprecated on March 19, 2026 in favor of cursor.directory, the third-party directory that now serves as the de facto catalog. The succession is a maintenance-recency lesson applied to lists themselves, and the cross-client directory with one evaluation rubric stays the MCP server directory.

One paragraph on failure, because the search data says it loudly: the two highest-volume Cursor MCP error queries are the literal strings “spawn npx ENOENT” and “specific node not found,” both meaning the same thing, Cursor’s GUI process cannot find the Node.js runtime your shell can. The fixes, with the exact strings and the per-platform PATH repair, are in the Cursor setup guide, alongside the “client closed” and “no tools or prompts” cases.

Which MCP Servers Pair Best with Cursor?

The highest-demand Cursor pairings are GitHub, Figma, Supabase, Playwright, Jira, and Vercel, each covered on its own page. One line each, and the entity pages carry the depth:

• GitHub: issues, PRs, and repo context inside the agent, with toolsets worth pruning against the 40-tool cap.
• Figma: design tokens and frame structure for design-to-code work, the single most-searched Cursor pairing.
• Supabase: the project-scoped database gateway; its read_only and project_ref parameters matter doubly inside an autonomous agent.
• Playwright: the verify-after-edit loop, with snapshot token costs that argue for project scoping.
• Jira and Vercel: issue tracking and deployments in the agent’s reach; both live in the developer-tools and DevOps categories.

Ranked picks with stated criteria are at the best MCP servers shortlist.

A configured Cursor now runs servers under a tool budget. What that costs in subscription terms, and how the experience compares across clients, is the supplementary half of this page.

Is MCP Free in Cursor?

No plan fee attaches to MCP itself, and Cursor’s free plan cannot add custom MCP servers; paid plans can. The gating is the industry pattern, not a Cursor quirk: ChatGPT’s and Claude.ai’s free tiers exclude custom servers the same way, because every MCP call carries real serving cost through the model (MCP Bundles, May 2026).

The full cost picture has three layers, and only the first is Cursor’s:

1. The plan: a paid Cursor subscription is the gate to adding custom servers; current tier names and prices live on Cursor’s pricing page and change often enough that this page does not pin them.
2. The servers: open-source servers cost nothing, and vendor remote servers ship free with the underlying account.
3. The APIs behind them: metered keys are where real spend accumulates, the pattern the Brave Search pricing change made loud in 2026, and each server page on this site carries its own line.

How Does Cursor’s MCP Experience Compare with Other Clients?

Cursor’s MCP profile is config-as-code with a UI on top: the project-scoped file is its differentiator, the tool ceiling is its constraint, and its primitive support runs ahead of most of the field. Claude Desktop trades the repo-portable config for a simpler single file and connectors UI. Claude Code trades the GUI for terminal-native commands and lazy tool loading that sidesteps the ceiling problem. VS Code matches the config-file pattern under a different root key. Windsurf matches the IDE shape with its own enterprise certifications.

Cursor MCP Questions

Does Cursor Support MCP?

Yes. Cursor supports MCP natively across stdio, SSE, and streamable HTTP transports, with tools, resources, and elicitation primitives, documented in Cursor’s official MCP docs. Servers connect through a config file, a one-click deeplink, or a marketplace plugin, and the agent calls their tools during normal coding work.

What Is mcp.json in Cursor?

mcp.json is Cursor’s MCP configuration file, listing each server’s name, launch command or URL, and environment variables. It lives in two scopes: .cursor/mcp.json in the project root, which commits with the repository, and ~/.cursor/mcp.json globally. The project file overrides the global one when both define the same server.

How Many MCP Servers Can Cursor Run?

Cursor’s practical limit is tools, not servers: 40 active tools across all connected servers combined. Three focused servers fit comfortably; one heavyweight server can spend half the budget alone. Past the cap, the agent silently loses access to some tools, so the per-server tool toggles in settings are the control that keeps a larger server set usable.

Does MCP Affect Cursor’s Performance?

Yes, through the context window: every connected server’s tool definitions consume tokens on each request before any tool is called. The cost is fixed per request, which is exactly why the tool ceiling and the per-server toggles exist. A trimmed tool set keeps the agent’s tool choice sharp and its context spent on your code instead of tool descriptions.

Every Cursor MCP decision on this page runs into the same number: a 40-tool budget, spent across every server you connect. Scope the servers to the projects that need them, toggle off what the work does not use, and the limit stops being the thing you discover and becomes the thing you planned around.