Best MCP servers for Cursor in 2026

TL;DR:

• The best MCP server for Cursor depends on the job: Filesystem MCP handles local file access, GitHub MCP automates repos, and Playwright MCP controls browsers.

• Running 10+ individual servers creates tool-selection errors, token refresh races, and context window bloat.

• Composio's MCP server gives Cursor one endpoint for 1,500+ apps with managed auth, structured schemas, and dynamic tool routing.

• Composio has connected over 1 million accounts, with 1B+ tool calls run on the platform.

• Self-learning capabilities distilled from these calls make repeat tasks 30% more accurate on 2× fewer tokens.

• Composio's free tier includes 100K tool calls/month with no credit card required.

Connecting Cursor to external tools fails in predictable ways. A GitHub MCP server authenticates correctly but returns unstructured data the model can't reason over. A Slack server routes the right message but never verifies delivery. A database server runs a query but silently times out mid-workflow. Auth is one part of the problem. The harder part is reliable execution: planning which tools to call, routing to the right one, authorizing the request, executing it, and verifying the result came back correctly.

This article breaks down the MCP servers worth installing in Cursor by job, shows how to configure them securely, and explains when to consolidate into a managed gateway that handles auth, schemas, and tool routing across hundreds of apps through one MCP endpoint.

What MCP servers do in Cursor

MCP servers connect Cursor to external tools. Think of MCP as a universal connector that lets your AI assistant read files, query databases, control browsers, and interact with SaaS apps without leaving your IDE.

Defining the Model Context Protocol

MCP standardizes how AI models connect to external data sources and tools. At a high level, an MCP server exposes a set of tools (functions the AI can call) and resources (data the AI can read). When you ask Cursor to "search my GitHub issues," the MCP server translates that request into a GitHub API call, executes it, and returns structured results the model can reason over.

Every MCP server offers Cursor three things: tools, resources, and prompts. Tools are actions the agent can call: create_issue, send_message, run_query. Resources are data the agent can read: file contents, database rows, channel history. Prompts are reusable instruction templates that pre-fill common requests. When you ask Cursor to search your GitHub issues, it calls a tool, reads a resource, and optionally applies a prompt template, all defined by the GitHub MCP server for that specific job.

Configuring Cursor for MCP servers

Cursor supports MCP servers through a configuration file at .cursor/mcp.json in your project root (or ~/.cursor/mcp.json for global config). The Cursor MCP documentation shows you can add servers manually or browse the Cursor Marketplace for one-click installs.

Here's a minimal config for the filesystem server:

{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem", "/path/to/allowed/dir"]
    }
  }
}

Restart Cursor after editing the config. The MCP server starts automatically when Cursor launches.

Scaling Cursor integrations with MCP

Individual MCP servers work well for single-purpose tasks. But when you connect 10+ servers to Cursor, four problems emerge:

1. Tool-selection errors: The model sees dozens of available tools and picks the wrong one. You asked for a Gmail action, but the agent tries to use Slack because both involve "sending messages."

2. Token refresh races: OAuth tokens expire mid-workflow and multiple concurrent calls can collide on refresh, breaking the tool call silently.

3. Context window bloat: Each MCP server injects its tool schemas into the model's context. A Gmail search returns a wall of JSON. Ten servers can consume 50K+ tokens before your agent starts reasoning.

4. No execution verification: Individual MCP servers call an API and return a response, but they don't verify whether the action completed correctly. A create_issue call returns a 200 status even when the issue was created in the wrong repo, missing required fields, or duplicated from a prior call. Without a verification step, agents retry successful actions or proceed on bad data.

Selecting the right MCP servers for Cursor jobs

The best Cursor MCP servers depend on what you're building. Here's a breakdown by use case.

1. Scaling tooling with Composio MCP

Best for: Production workflows connecting 3+ SaaS apps. Skip if: You only need local file access or a single API.

Composio's MCP server gives Cursor one endpoint for 1,500+ apps, with auth, schemas, and tool routing handled automatically. See the Composio MCP section below for full architecture details.

Composio handles OAuth 2.0, API keys, and JWT tokens across all integrations. When an agent needs access mid-conversation, it returns a Connect Link URL, the user authenticates once, and credentials persist for all future sessions.

2. Enabling filesystem MCP in Cursor

Best for: Reading and writing local project files without leaving Cursor. Skip if: You need access to remote services or SaaS APIs.

The official filesystem MCP server gives Cursor read and write access to local directories. Install it with:

npx -y @modelcontextprotocol/server-filesystem /path/to/allowed/dir

Add the config to .cursor/mcp.json and specify which directories the server can access. This prevents the agent from reading sensitive files outside your project.

The filesystem server repository includes options for read-only mode and file filtering. Use read-only mode when you want the agent to analyze code without modifying it.

3. Automating GitHub via Cursor MCP

Best for: Automating issues, PRs, and code search within a single repo. Skip if: You're managing multiple repos or need OAuth token refresh handled automatically.

The npm package @modelcontextprotocol/server-github was deprecated in April 2025. Use GitHub's hosted remote server (recommended, requires Cursor v0.48.0+) or the official Docker image instead.

Option 1: Hosted remote server (recommended)

Add the following to .cursor/mcp.json:

{
  "mcpServers": {
    "github": {
      "url": "https://api.githubcopilot.com/mcp/",
      "headers": {
        "Authorization": "Bearer YOUR_GITHUB_PAT"
      }
    }
  }
}

Option 2: Docker image

{
  "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"
      }
    }
  }
}

Replace YOUR_GITHUB_PAT or YOUR_TOKEN with a personal access token that has repo scope. The server exposes tools like create_issue, search_repositories, and get_file_contents.

For teams managing multiple repos, Composio's GitHub toolkit provides 800+ methods across issues and PRs, with each method returning LLM-optimized JSON your agent can reason over immediately.

4. Automating web tasks with MCP

Best for: UI testing, scraping, and form automation against live pages. Skip if: You need a sandboxed, dependency-free execution environment.

The @modelcontextprotocol/server-puppeteer reference implementation has been archived and moved to modelcontextprotocol/servers-archived. Use Microsoft's officially maintained Playwright MCP server instead:

npx @playwright/mcp@latest

The server exposes tools like browser_navigate, browser_take_screenshot, and browser_click. Use it to test UI changes, extract data from web pages, or automate form submissions.

5. Query databases via MCP agents

Best for: Running read-only SQL queries against a local or development database. Skip if: You need write access controls or production-grade connection pooling.

The @modelcontextprotocol/server-postgres reference implementation has been archived and moved to modelcontextprotocol/servers-archived. Community-maintained alternatives exist for most database types: verify the package you choose is actively maintained before adding it to a production config.

Database MCP servers let Cursor run SQL queries against Postgres, MySQL, SQLite, and other databases. The exact setup depends on your database type, but most use connection strings passed as environment variables.

Here's a Postgres example:

{
  "mcpServers": {
    "postgres": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-postgres", "postgresql://user:pass@localhost:5432/db"]
    }
  }
}

Limit the database user to read-only permissions unless you explicitly need write access. This prevents the agent from accidentally dropping tables or modifying production data.

6. Slack MCP for agent messaging

Best for: Sending messages and searching channels with a dedicated bot token. Skip if: Your agent runs continuously and needs automatic token rotation handling.

The @modelcontextprotocol/server-slack reference implementation has been archived and moved to modelcontextprotocol/servers-archived. The maintained community version is now published by Zencoder at github.com/zencoderai/slack-mcp-server. Follow their README for the current install command, then configure it in .cursor/mcp.json:

Set the SLACK_BOT_TOKEN and SLACK_TEAM_ID environment variables. The bot token needs chat:write and channels:read scopes. If you need search functionality, that requires a user token with the search:read scope.

For teams running Slack alongside GitHub, Notion, or Salesforce in the same workflow, Composio's Slack toolkit is one of 50,000 agent-ready tools available through a single MCP endpoint, each schema-formatted for direct LLM consumption.

Composio MCP: Connect 1,500+ apps through one server

Running 10+ individual MCP servers creates maintenance overhead that compounds over time. Each server brings its own auth flow, schema format, and update cycle. When a provider changes their API, you patch the integration. When a token expires, you debug the refresh logic. Composio's MCP server consolidates this into one endpoint backed by 50,000 agent-ready tools, and its Tool Router dynamically loads only the tools relevant to the current task.

How Composio's Tool Router eliminates conditional logic

Composio's Tool Router inspects incoming requests and routes them to the appropriate toolkit based on the user's authenticated connections. When an agent needs to "send an email," Composio's Router determines whether to use the Gmail API, Outlook API, or SMTP based on which services the user has connected. This eliminates conditional logic in your agent code.

You don't write branching statements to check whether a user authenticated Notion vs. Google Docs before exposing the relevant tool. The Router handles it.

How Composio's execution layer works

Composio's Tool Router is part of a five-step execution trace that runs on every tool call:

• Plan: The agent identifies the task (e.g., "create a GitHub issue from this Slack message").

• Route: Composio's Tool Router inspects the request and selects the correct toolkit based on the user's authenticated connections. It picks GitHub over Jira because that's what this user has connected.

• Authorize: Composio checks scopes and refreshes credentials before execution, not after failure.

• Execute: The tool call runs against the live API with structured, LLM-optimized parameters.

• Verify: Composio returns a structured result with success status, response payload, and latency. If the action fails, the agent gets a typed error it can reason over, not a silent timeout.

This trace is logged per call. For production debugging, every execution includes tool name, latency, and error classification, not just a status code.

Composio's MCP server separates tool discovery from tool execution. The gateway searches the catalog, inspects schemas, authenticates users, and executes app tools without loading every possible tool into context. This keeps your context window small and reduces tool-selection errors.

Top MCP servers for Cursor workflows

Here's how individual servers compare to our managed approach:

Individual servers work fine for single-purpose tasks. But when you need Gmail, Slack, GitHub, Notion, and Salesforce in the same workflow, Composio's managed auth layer saves days of OAuth debugging.

Security standards for Cursor agents

Composio holds SOC 2 Type II and ISO 27001 certifications with all data encrypted in transit and at rest. Composio's MCP server provides centralized execution control and credential isolation across all connected apps.

When connecting a third-party app through Composio, credentials are stored in a managed auth layer. Tokens refresh automatically without race conditions. Scope limiting ensures the agent only accesses the APIs it needs.

Composio tools are pre-built and AI-optimized, but they're closed-source. If you need to inspect or fork integration code for a specific app, you'll need to build and maintain your own MCP server for that integration.

Configuring Composio via CLI

Install the Composio CLI with:

curl -fsSL https://composio.dev/install | sh

Authenticate with:

composio login

There are two ways to connect Cursor. Install the Composio plugin from the Cursor Marketplace for one-click setup, or add the following to .cursor/mcp.json manually:

The first call opens an OAuth prompt to authorize access. After that, Cursor connects to the Composio MCP endpoint automatically.

{
  "mcpServers": {
    "composio": {
      "url": "https://connect.composio.dev/mcp"
    }
  }
}

How to manage multiple MCP servers for Cursor

Running 10+ MCP servers in production requires centralized auth, monitoring, and error handling. Here's how to scale without turning your IDE into a maintenance project.

Scaling Cursor MCP with Composio

Individual servers are the right call when you're running one or two integrations with predictable token lifecycles. Move to Composio's MCP server when:

• You're connecting 3+ SaaS apps and OAuth debugging is taking longer than feature work.

• You need audit logs across your full agent tool-call history.

• A third-party API changes and you don't want to own the patch cycle yourself.

Composio has 1B+ tool calls run on the platform. Each call feeds a self-learning layer that improves tool selection, parameter formatting, and retry logic over time. For repeat workflows (daily standups posted to Slack, weekly GitHub issue triage, recurring database exports), the agent progressively uses better-fit tools and smaller context windows. In practice, repeat tasks run 30% more accurately on 2× fewer tokens compared to a cold-start configuration. You don't configure this. It improves as the platform observes patterns across the full call volume.

Composio provides an execution log for every tool call, so you can inspect what ran, when, and whether it succeeded.

Managing credentials and execution reliability

Execution reliability is the harder problem. Composio's gateway retries failed tool calls with automatic recovery, classifies errors by type (auth failure, timeout, malformed response, rate limit), and surfaces them as structured errors the agent can act on. When a Slack message fails to send because the bot token was revoked, the agent receives a typed auth-failure error it can act on rather than a generic 500, so it can re-prompt the user for reauthorization rather than retrying indefinitely.

Credential management is handled as part of the same layer. OAuth tokens from providers like Google expire after 60 minutes. Composio's managed auth layer refreshes them in the background without breaking the agent workflow. Credentials persist across sessions, so users don't need to re-authenticate.

For API keys, rotate them every 90 days. Use a secrets manager to store keys securely and inject them into the MCP server config at runtime.

Debugging MCP server failures

MCP servers fail silently when tokens expire, network requests timeout, or API responses change. Here's how to debug production issues:

1. Enable verbose logging: Set the DEBUG environment variable to * to see all MCP server logs.

2. Monitor token expiration: Track when tokens expire and set up alerts before they fail.

3. Test error handling: Simulate API failures and verify the agent handles them gracefully.

4. Use structured logging: Log tool calls, responses, and errors in a structured format so you can query them later. Composio logs every tool call with latency metrics, error traces, and execution metadata. For production workflows, use a platform that provides observability out of the box.

Get started with Composio and try the Composio Cursor toolkit. The free tier includes 100K tool calls/month with no credit card required.

FAQs

What is the best MCP server for Cursor beginners?

Start with the filesystem MCP server for local file access and the GitHub MCP server for repo automation. Both are officially maintained and have clear documentation. For SaaS app integrations, Composio's free tier (100K tool calls/month, no credit card) connects Gmail, Slack, and Notion through one endpoint with managed auth, structured schemas, and execution verification on every tool call.

Do MCP servers work with Cursor's free plan?

Yes, MCP servers work with all Cursor plans including the free tier. The Cursor MCP documentation shows how to configure servers in .cursor/mcp.json regardless of your plan. Composio's free tier includes 100K tool calls/month with no credit card required.

How does Composio handle tool call failures in production?

Every tool call through Composio's MCP server returns a structured result: success status, response payload, latency, and a typed error if the call failed. Errors are classified by category (auth failure, timeout, malformed response, rate limit) so your agent can respond appropriately instead of retrying a failed auth call or skipping a rate-limited one. For continuous workflows, Composio's managed retry layer handles transient failures with exponential backoff. You can inspect the full execution trace (tool name, latency, and error classification) in the dashboard or via the audit log API.

Glossary

MCP (Model Context Protocol): A protocol that standardizes how AI models connect to external data sources and tools. MCP servers expose tools (actions), resources (data), and prompts (templates) that AI assistants can use.

Tool Router: Composio's dynamic routing layer that inspects incoming requests and routes them to the appropriate toolkit based on the user's authenticated connections. Eliminates conditional logic in agent code.

Context window: The maximum number of tokens an LLM can process in a single request. Each MCP server injects tool schemas into the context, so running multiple servers can consume tokens before the agent starts reasoning.

Managed auth layer: Composio's centralized authentication system that handles OAuth 2.0, API keys, and JWT tokens across all supported apps. Tokens refresh automatically without race conditions or re-authentication loops.