Best MCP servers for Cursor in 2026

TL;DR. The best MCP servers for Cursor in 2026 are the official, remote ones that do one job well: GitHub for repos and CI, Supabase or Hatchable for a database and a live app, Playwright for a browser, Context7 for current docs, Sentry for errors, Linear and Notion for the team's work, Stripe for payments, Cloudflare for edge infrastructure. Each is a few lines in ~/.cursor/mcp.json or a one-click "Add to Cursor" link, most sign in with OAuth on Cursor 1.0 and later, and the Cursor-specific rule is to keep enabled tools few.

How this list of Cursor MCP servers was chosen

Cursor's agent can call any MCP server, and "best MCP servers for Cursor" lists tend to be long. This one is ten, picked on four rules. The vendor's own server beats a community fork, because it tracks the product's API. Remote Streamable HTTP with OAuth beats a local process with a token in a file: nothing to install, nothing to leak. Each server has to do one job you can name. And each has a documented Cursor config, so each snippet is the vendor's shape, not ours.

General characterisations based on public information as of August 2026; check each vendor for current details.

Every snippet below is one key inside the mcpServers object of ~/.cursor/mcp.json (global) or .cursor/mcp.json in a repo; Cursor Settings, Tools & MCP (older builds: MCP), New MCP server opens the same file. The wrapper, with GitHub as the first entry:

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

First time? How to add an MCP server to Cursor covers the settings page and failure modes; what MCP is covers the protocol.

The best MCP servers for Cursor in 2026

1. GitHub MCP server (source control and CI)

Good for: issues, pull requests, code search, and Actions logs pulled into the agent so it can fix a red build without you pasting anything. GitHub's official server, hosted by GitHub, with toolsets you can narrow and a read-only mode. The entry is the one in the wrapper above.

Caveat: GitHub's own Cursor guide says the remote server still needs a personal access token in Cursor, even though Cursor does OAuth for other servers. Keep it fine-grained and reference it as "Bearer ${env:GITHUB_PAT}" rather than pasting it into the file.

2. Supabase MCP server (hosted Postgres)

Good for: an app whose backend already lives on Supabase. The agent can inspect the schema, run SQL, write migrations, manage branches, deploy edge functions and read logs through one remote endpoint with OAuth sign-in.

"supabase": { "url": "https://mcp.supabase.com/mcp?read_only=true" }

Caveat: real queries against a real project. Supabase's docs recommend a development project rather than production and keeping read_only=true on until you need writes. Treat every write tool as a deploy.

3. Hatchable (build, deploy, host, and a database)

Good for: when Cursor should build the whole app and put it live, not just talk to a backend you already run. One OAuth sign-in at https://hatchable.com/mcp, no API key, and the agent can create a project, write the files, deploy, and hand back a live URL at your-app.hatchable.site. Every project comes with its own private Postgres database, sign-in for the app's users, email, scheduled jobs and file storage. The free plan is unlimited private projects and one published app, no card.

"hatchable": { "url": "https://hatchable.com/mcp" }

Caveat: the OAuth flow needs Cursor 1.0 or later; older builds use a token header instead, shown on the connect Cursor page along with a one-click installer. Hatchable hosts web apps written in HTML, JavaScript, SQL and TOML on its own platform (tool list on the MCP feature page); it is not a Python or Docker host and does not run long-lived processes.

4. Playwright MCP (browser automation)

Good for: letting the agent check its own UI work: navigate, click, fill forms, take screenshots, all through accessibility snapshots so the model reads the page structurally instead of guessing from pixels. Microsoft maintains it; there is a one-click Cursor install.

"playwright": { "command": "npx", "args": ["@playwright/mcp@latest"] }

Caveat: a local stdio server: Node.js 20 or newer, a real browser on your machine (headed by default; add "--headless" to the args), and a persistent profile unless you pass --isolated. A browser that remembers your logins is one the agent can use; mind where you point it.

5. Context7 (current library docs)

Good for: version-specific documentation pulled into context when the agent needs it, which tends to cut the "that API changed two releases ago" class of bug. Remote endpoint, optional API key.

"context7": { "url": "https://mcp.context7.com/mcp" }

Caveat: coverage depends on whether a library is indexed, and Context7's docs describe tighter rate limits without a key (add it as an Authorization: Bearer header). A second opinion, not a substitute for reading the source when it matters.

6. Sentry (errors and performance)

Good for: production bugs: the agent pulls the latest unhandled exception, reads the stack trace and release, and proposes the fix in the same thread. OAuth, and the URL can be scoped to one org or project.

"sentry": { "url": "https://mcp.sentry.dev/mcp" }

Caveat: only useful for apps that already report to Sentry, and error payloads often carry user data that then flows into the model's context. Scope the URL to the project you are working on.

7. Linear (issue tracking)

Good for: "implement ENG-4521" without leaving the editor. The agent reads the issue, updates status, leaves comments and creates follow-ups. Linear added initiatives, milestones and project updates in early 2026 and lists the server on Cursor's MCP tools page.

"linear": { "url": "https://mcp.linear.app/mcp" }

Caveat: writes land in your real workspace. Linear documents a read-only endpoint at /mcp/readonly, and its older SSE endpoint is deprecated in favour of /mcp.

8. Notion (specs and internal docs)

Good for: reading the PRD, runbook or meeting notes that explain why the code is the way it is, and writing pages back. Notion's hosted server is OAuth only; Cursor prompts for sign-in on first use.

"notion": { "url": "https://mcp.notion.com/mcp" }

Caveat: Notion's docs say the OAuth flow must be completed interactively, and the server reads whatever the signed-in account can read, so sign in with the account whose visibility you mean to grant.

9. Stripe (payments)

Good for: a payments integration with the real API in reach: search Stripe's docs, read customers, subscriptions and invoices, create products, prices and payment links. Stripe offers a one-click Cursor install; OAuth by default, or a restricted key via a header.

"stripe": { "url": "https://mcp.stripe.com" }

Caveat: write tools move real money (refunds, subscription changes). Stripe's docs say to keep human confirmation of tools on and be cautious running it beside other servers, since a prompt injection elsewhere can reach it. Start in a sandbox.

10. Cloudflare (edge infrastructure and docs)

Good for: Workers and Pages projects. Cloudflare ships small remote servers: documentation for accurate platform answers, Workers Bindings to create KV, D1 and R2 resources, Observability for logs and analytics.

"cloudflare-docs": { "url": "https://docs.mcp.cloudflare.com/mcp" }

Caveat: the docs server needs no sign-in; the account-level servers (bindings, observability and the rest) use OAuth and each adds its own tools, which matters more in Cursor than elsewhere (see below). Add the two or three you use, not the full catalogue.

Cursor MCP servers compared

How to pick MCP servers for Cursor

Start from a gap, not a list. The right Cursor MCP server is the one whose data you keep pasting into the agent panel: stack traces, Sentry; the ticket, Linear; apps that get built and then sit on your laptop, a server that can deploy.

Watch the tool count. Cursor warns when the tools enabled across all your servers pass its limit (community threads have cited a ceiling of 40), and tools past the line can silently fall out of the agent's reach. Switch off individual tools on each server's row under Tools & MCP. Four to six servers, trimmed, beats twelve at full width.

Prefer remote, OAuth, and the right file. Cursor 1.0 and later completes OAuth for Streamable HTTP servers in a browser tab on first use, so nothing sensitive lives in mcp.json. Where a vendor still needs a token, reference it as ${env:NAME} in the headers. A project's own .cursor/mcp.json scopes servers to that repo and lets teammates share the config through version control.

Name the tool in the prompt. Cursor's agent only reaches for an MCP tool when the conversation clearly needs it: "deploy this" or "open the Linear issue" works; "help me with this file" does not.

Two sensible starter kits. Maintaining an existing codebase: GitHub, Sentry, Linear, Context7, Playwright. Shipping new apps from a prompt: Hatchable for build, deploy and database, GitHub for the repo, Playwright to check the result. The same servers work in Claude Code and Codex; only the config shape changes.