Cursor MCP Not Working? Fix Servers That Won't Connect

Jump to: quick triage · server shows no tools · a server you added is missing · stuck on sign-in or blocked by your team · broke after updating Cursor · things worth clarifying

Start Here: Three Checks Before You Touch Any Config File

1. Open Customize (sidebar) and check the server's toggle. This is where servers are enabled, disabled or removed. (A new server is installed separately, by clicking "Add to Cursor" on its entry in the Cursor Marketplace.) A toggled-off server won't load, which looks identical to a broken one from the Agent's side.
2. Open the MCP Logs. Open the Output panel (Cmd+Shift+U on macOS) and choose "MCP Logs" from the dropdown. Cursor's docs point to this panel for connection errors, authentication issues and server crashes — it's the fastest way to tell which of those three you're dealing with before changing anything.
3. Work out whether the server is local or remote. A stdio server runs locally as a shell command, for a single user. An SSE or Streamable HTTP server runs locally or remotely, supports multiple users, and connects through a URL plus OAuth. The two fail for different reasons, so the rest of this guide splits on that.

Error 1 - A Server Shows No Tools, or the Agent Says It Has No Access

What you see: the server appears enabled in Customize, but it exposes zero tools, or the Agent reports it can't access something you configured.

Why it happens

Cursor's docs treat this as a startup problem, not a permissions problem: a server that exposes no tools either never started, or started and then exited. For a local (stdio) server, that's almost always the configured command — the executable isn't on the system path, the path is wrong, or a required package isn't installed. For a remote (SSE or Streamable HTTP) server, the same symptom usually traces back to a wrong endpoint URL, a missing or expired OAuth token, or a missing environment variable the server needs to start.

How to fix it

1. Check the MCP Logs first (see triage) — Cursor's docs list connection errors, authentication issues and server crashes as what shows up there, so start by seeing which one it is.
2. For a local server, confirm the command field points to a full path rather than relying on it being on your system's PATH.
3. For a remote server, confirm the url is correct, and re-authenticate if the log shows an authentication issue.
4. Check that any environment variable or API key the server needs is actually set where Cursor can see it — a server that needs one to start will exit immediately without it.

What you should see: the server's tools appear in Customize, and the MCP Logs stop showing a crash or connection error for it.

Error 2 - A Server You Added Doesn't Show Up

What you see: you added or edited a server, but it's missing from Customize, or an edit to its config doesn't seem to change anything.

Why it happens

Cursor reads MCP servers from two files: a project one, .cursor/mcp.json, for tools specific to that project, and a global one, ~/.cursor/mcp.json, for tools available everywhere. Editing the wrong one for what you're trying to do is the most common reason a change "doesn't take effect" — for example, editing the global file while expecting a project-only server to appear. Cursor's documentation doesn't spell out what happens when the same server name exists in both files, so don't rely on one taking priority over the other.

How to fix it

1. Decide which file the server belongs in: .cursor/mcp.json in the project root if it's specific to that codebase, ~/.cursor/mcp.json if it should follow you everywhere.
2. If the same server name exists in both files, remove the duplicate from one of them instead of assuming Cursor will pick the one you meant.
3. Reopen the project (or restart Cursor) after editing either file, then check Customize again.

What you should see: the server appears in Customize with its tools listed, in the scope you intended.

Error 3 - Stuck Asking to Sign In, or Missing Only Inside Your Org

What you see: a remote server keeps prompting for sign-in without completing, or a server is available to you personally but missing inside your company's Cursor workspace.

Why it happens

SSE and Streamable HTTP servers authenticate through OAuth, started by clicking "Add to Cursor" on a Marketplace entry. If that handshake doesn't complete, the server can't start. Separately, teams manage shared servers under Dashboard > Plugins & MCPs, and on Cursor's Enterprise plan, admins can additionally restrict which servers are allowed at all through an Allowlist under Team Settings > MCP Configuration. A server blocked by that Allowlist won't work for anyone in the org, regardless of how it's configured locally — which looks identical to a broken config from the outside.

How to fix it

1. Check the MCP Logs for an authentication issue, and retry "Add to Cursor" from the Marketplace entry to redo the OAuth sign-in.
2. If the server is meant to be shared with your team, confirm it's actually set up under Dashboard > Plugins & MCPs rather than only in your own config.
3. If your organization is on Cursor's Enterprise plan and a server won't work no matter what you change locally, ask your admin to check whether it's missing from the MCP Allowlist under Team Settings > MCP Configuration.

What you should see: the server shows as connected without re-prompting for sign-in, and teammates see the same server if it's meant to be shared.

Error 4 - MCP Stopped Working After a Cursor Update

What you see: servers that worked before a Cursor update now show no tools, or the Agent says it has no access to any of your custom servers except built-in ones like GitHub.

Why it happens

Be precise about what's confirmed here, because the two reports aren't the same bug. One is confirmed: a Cursor staff member (Dean Rie) acknowledged on Cursor's forum, "This is a known bug," describing remote (non-stdio) MCP servers that don't pick up a new tool list after you edit mcp.json or hit reconnect/reload. As of late August 2026 it was still open with no ETA, and staff pointed to 3.11.25 as the last build before the tool-refresh problems started. The other is unconfirmed: a separate forum report on Cursor 2.0.77 describes the Agent losing access to every custom MCP server except GitHub, after the user upgraded from 2.0 to 2.3 and reverted — no staff reply appears in that thread, so treat it as an open report, not a documented bug.

How to fix it

1. Rule out the config issues in Error 1 and Error 2 first — they produce the same symptom and are far more common than either forum report below.
2. If a remote server's tool list looks stale after editing mcp.json or clicking reconnect, that matches the confirmed bug above. Cursor staff described a full restart as "the only reliable way to pick up a new tool list" for it, and separately confirmed that moving the affected server to your user-level ~/.cursor/mcp.json makes Cursor pick it up; downgrading to 3.11.25 was offered only as a temporary workaround, not a fix.
3. If instead every custom server is suddenly inaccessible except a built-in one like GitHub, that matches the unconfirmed 2.0.77 report. Check the MCP Logs first; if they show nothing wrong, the only reported workaround is a full restart of your computer, which isn't guaranteed to work.
4. If none of that helps, that's exactly when to report it on Cursor's forum with your exact version number, rather than continuing to try config changes.

What you should see: for the confirmed bug, tools reappear after a restart or after moving the server to the user-level config; for the unconfirmed report, this is a case to report on the forum if a restart doesn't fix it, rather than keep debugging locally.

Things Worth Clarifying

• One failed tool call doesn't mean the server is broken. Cursor's docs say a failed tool call shows an error in chat and marks that call as failed, but lets you retry — and other servers keep working. Don't disable or reconfigure a server over a single failed call.
• "No tools found" and "needs sign-in" are different problems. The first means the server process isn't running or isn't exposing anything; the second means it's running but waiting on OAuth. Check the MCP Logs to tell which one you have before changing config.
• Supabase, GitHub, Playwright, Figma, Atlassian and similar MCP servers aren't special cases inside Cursor. Cursor treats every server the same way, as either local (stdio) or remote (SSE/Streamable HTTP). If a specific one of these isn't working, the two error categories above still apply — the vendor-specific part (which API key it needs, what its exact command or URL should be) is documented by that server's own project, not by Cursor.

When It Isn't a Bug

• A local (stdio) server stopping when its underlying app closes isn't a bug. A stdio server for something like a browser-automation or design-tool integration depends on that app or process staying open; closing it is expected to break the connection until it's reopened.
• Being asked to sign in again after a long gap isn't a bug. OAuth sessions for SSE/Streamable HTTP servers expire; re-authenticating through "Add to Cursor" is the expected recovery, not a failure.
• A server missing only in one project isn't necessarily a bug. If it was added to a project's .cursor/mcp.json rather than the global one, not seeing it in a different project is working as configured.

What to Include When You Ask for Help

• what Customize shows for the server (enabled, disabled, or not listed at all);
• what the MCP Logs say for that server at the time it failed;
• whether it's a local (stdio) or remote (SSE/Streamable HTTP) server, and which config file it's defined in — .cursor/mcp.json or ~/.cursor/mcp.json;
• your Cursor version, and whether it was working before a recent update.

Related

For other Cursor problems unrelated to MCP — rule files being ignored, the agent getting stuck on a file, or stuck in a rewrite loop — see the full Cursor troubleshooting guide and the guide to stopping Cursor's agent apply loops. For an overview of what Cursor covers as a platform, see the Cursor platform page. If you're hitting this on Claude Code instead of Cursor, its MCP setup and config file are different — see the Claude Code MCP troubleshooting guide.

Frequently Asked Questions

Sources

Checked on October 12, 2026:

• Cursor docs: Model Context Protocol (MCP)
• Cursor forum: "MCP doesn't work"
• Cursor forum: "MCP server regression - does not reload tools, 'disconnect' does nothing, ignores mcp.json changes, etc" (Cursor staff reply)