Cursor MCP server showing a red dot, an empty tool list or silent failures? Read the logs, repair PATH and JSON mistakes, fix GitHub token scopes, Figma ports and Playwright browser errors, then test any server with the inspector so your agent uses its tools again.
You paste a server block into mcp.json, restart Cursor, and the settings panel shows a red dot, or a green dot beside an empty tool list. The agent carries on as if your GitHub, Figma or Playwright server never existed. That silence is what makes MCP debugging so irritating: nothing crashes, nothing explains itself, and the fix is usually one line you cannot see from the settings screen.
This article walks through the failures behind Cursor MCP servers not working, in the order that finds them fastest. The first section holds four checks that apply to every server. After that come the specific traps for GitHub, Figma and Playwright, then tool limits, approval prompts, and a way to test any server outside the editor. Each fix names its symptom, so you can jump straight to the one that matches your screen.
💡 A note on versions: Cursor and all three servers change quickly. Menu labels, flags and URLs shift between releases, so when a name on your screen differs from this page, trust your log output over this article.
Before blaming one server, rule out the problems that break all of them at once. In most cases, one of these four is the culprit.
Open the Output panel in Cursor and pick the MCP logs channel from the dropdown. The exact label moves around between versions, but it sits with the other Output channels. The log shows the command Cursor ran and whatever the server wrote to stderr before it stopped. Three messages account for most failures:
spawn npx ENOENT: Cursor cannot find the executable. Jump to the PATH fix below.MCP error -32000: Connection closed: the process started and exited at once, usually from a missing token, a bad argument or a crash on launch.Request timed out: the server is alive but slow, often because npx is downloading a package on its first run.💡 Tip: Copy the last 30 lines of the log before you change anything. Each restart overwrites the evidence you need if your first guess is wrong.
Cursor reads two files: ~/.cursor/mcp.json for every project, and .cursor/mcp.json inside the current project. Both need strict JSON, which means no comments, no trailing commas and straight quotes only. One stray comma can make Cursor skip the whole file without a clear message.
{
"mcpServers": {
"github": {
"command": "docker",
"args": ["run", "-i", "--rm", "-e", "GITHUB_PERSONAL_ACCESS_TOKEN", "ghcr.io/github/github-mcp-server"],
"env": { "GITHUB_PERSONAL_ACCESS_TOKEN": "${env:GITHUB_TOKEN}" }
}
}
}
To check a file, run node -e "JSON.parse(require('fs').readFileSync('.cursor/mcp.json','utf8'))". It prints nothing when the JSON is valid and names the exact position when it is not. Recent Cursor builds expand ${env:NAME} placeholders from your environment. If your build passes the literal text instead, the server receives a fake token and fails with an authentication error, so test with a real value in a local, uncommitted file.
Cursor launched from the dock, the Start menu or Spotlight does not read your shell profile. Tools installed through nvm, fnm or Homebrew can be invisible to it even though they work in your terminal, and the log shows spawn npx ENOENT. Replace the bare command with an absolute path. Run which npx on macOS and Linux, or where npx on Windows, and paste the result:
"command": "/Users/you/.nvm/versions/node/v22.11.0/bin/npx"
Windows adds a second trap. npx is a .cmd script, and some launchers cannot run it directly. Wrap it in cmd, and always pass -y so npx never stops to ask permission for a download that nobody can see:
"command": "cmd",
"args": ["/c", "npx", "-y", "@playwright/mcp@latest"]
Editing the file does not always restart a running server. Switch the server off and on under Cursor Settings, Tools & MCP (older builds label it simply MCP), or run Developer: Reload Window from the command palette. If the old state sticks, quit Cursor fully. A leftover process can hold a port or a browser profile and make a fresh start fail for reasons that have nothing to do with your config.
GitHub maintains its own server in the github/github-mcp-server repository, in two forms: a local one that runs in Docker, and a hosted one. If your config still points at the old @modelcontextprotocol/server-github npm package, move off it. That package has been deprecated in favor of GitHub's own server, and the newer one gets the fixes and the new tools.
The most common GitHub failure is a server that connects fine while every tool call returns 401, 403 or a puzzling 404. A 404 on a private repository usually means the token cannot see it, not that the repository is missing. Check four things:
repo scope, and read:org if you query organization data.💡 Tip: Test the token outside Cursor with
curl -H "Authorization: Bearer $GITHUB_TOKEN" https://api.github.com/user. A JSON profile means the token works, and your problem sits in the config.
The local server needs Docker. Three log lines point here: docker: command not found, Cannot connect to the Docker daemon, and a timeout while the image downloads. Start Docker Desktop first, then run docker pull ghcr.io/github/github-mcp-server once in a terminal so Cursor never waits on the first download. Also check the -i flag in your args. It keeps stdin open, and without it the server exits the moment it starts. Behind a corporate proxy, the pull from ghcr.io can fail even when other Docker pulls work.
If Docker keeps fighting you, switch to the hosted server. It needs no Docker, no Node and no PATH setup:
"github": {
"url": "https://api.githubcopilot.com/mcp/",
"headers": { "Authorization": "Bearer ${env:GITHUB_TOKEN}" }
}
A 401 points at the token, and a timeout points at a proxy or firewall. GitHub's server also exposes a large number of tools, which matters for the limits discussed later. Its README documents toolsets, set through the GITHUB_TOOLSETS environment variable on the local server or an X-MCP-Toolsets header on the remote one, so you can load only repos, issues and pull_requests and leave the rest out.
Figma offers two routes. The first is a local server that runs inside the Figma desktop app. The second is a hosted server with browser sign-in. Names, ports and paths have changed since launch, so confirm them against Figma's current documentation when a step below does not match your screen. Failures fall into three buckets.
The local server lives inside the desktop app, not the browser tab. The app must be open, a design file must be loaded, and the MCP server must be switched on from the Dev Mode inspect panel or the preferences, depending on your build. Figma has also tied MCP access to paid plans and specific seat types, so check that your seat allows it before you spend an hour on config. When the app is closed, Cursor shows a refused connection, which looks like a broken server but is really a missing process.
The local server listens on port 3845. Newer builds answer at /mcp, and older ones used /sse. A config that still carries the old path gets a 404 or a refused handshake:
"figma": { "url": "http://127.0.0.1:3845/mcp" }
Use 127.0.0.1 instead of localhost. On some machines localhost resolves to IPv6 first, and a server bound to IPv4 refuses that route. If the port is taken, find the owner with lsof -i :3845 on macOS and Linux or netstat -ano | findstr 3845 on Windows. For the hosted route, point Cursor at https://mcp.figma.com/mcp and finish the browser sign-in when prompted. Closed the sign-in tab by accident? Toggle the server off and on to restart the process.
Local tools act on your current selection or on a link to a frame. Ask the agent to "build this screen" with nothing selected and it receives an empty response, which looks like a dead server while the connection is perfectly healthy. Select a frame in Figma or paste the frame link into your prompt. If a very large frame times out, select a smaller section and build the screen in parts.
💡 Tip: After every Figma change, ask the agent a tiny question first, such as the name of the selected frame. A correct answer proves the whole chain works before you ask for a full layout.
Microsoft's @playwright/mcp is the usual choice, and the minimal config is short:
"playwright": { "command": "npx", "args": ["@playwright/mcp@latest"] }
Because it launches a real browser, it fails in more ways than the other two servers.
A log line such as Executable doesn't exist or Chromium distribution 'chrome' is not found means no matching browser is installed. By default the server asks for Chrome. Either install Chrome the normal way, or run npx playwright install chrome in a terminal. The server also ships a browser_install tool, so you can tell the agent to call it when this error appears. To use another engine, add --browser firefox or --browser webkit to args and install that engine the same way.
The default session uses a persistent profile folder. A second Cursor window, or a Chrome process left over from a crashed run, locks that folder, and the log says the browser is already in use and suggests the --isolated flag. Close the stray processes, or add the flag so every session starts with a fresh in-memory profile:
"args": ["@playwright/mcp@latest", "--isolated"]
Isolated sessions forget logins. If you need to stay signed in to a site, give the server a dedicated profile with --user-data-dir instead.
Containers, WSL, SSH sessions and CI machines usually have no display, so add --headless. As a last resort inside a container running as root, --no-sandbox removes the sandbox error, at the cost of weaker isolation. Check the Node version too, because the package expects Node 18 or newer. Finally, the first launch downloads the package and starts a browser, which can exceed Cursor's timeout. Run npx @playwright/mcp@latest --help once in a terminal to warm the cache, and the next start from Cursor will be fast.
Some failures leave every dot green. The server is connected and the agent never uses it. Two causes account for most of these cases.
Too many tools loaded. Cursor has warned when the combined tool count across all servers grows large, with a historic ceiling around 40 tools that may differ in your build. GitHub alone can expose dozens. When the total crosses the line, tools from some servers may never reach the model. Disable servers you do not need in the current project, use GitHub toolsets, and keep project-level .cursor/mcp.json files lean.
Wrong mode or an unanswered approval. MCP tools run in Agent mode. In Ask mode the model cannot call them. By default every call asks for approval, and if you scroll past the prompt the chat looks frozen. Approve the call, or enable auto-run for servers you trust. Also open the server entry and confirm that individual tools were not switched off.
💡 Tip: A good test prompt is explicit: "Use the playwright tool to open example.com and tell me the page title." Naming the server removes any doubt about which tool the model should pick.
Run the MCP Inspector. The official inspector starts any server and lists its tools without Cursor in the way:
npx @modelcontextprotocol/inspector npx -y @playwright/mcp@latest
If the server connects and lists tools there but not in Cursor, the problem lives in Cursor's environment: PATH, environment variables or the config file. If it fails in the inspector too, the problem sits with the server or your machine, and the error text usually names it.
Let an LLM read the logs. Long logs are tedious, and a language model spots the one relevant line quickly. With Claude Sonnet 5 on PicassoIA:
REDACTED.GPT 5.6 Sol makes a good second opinion on stubborn cases, and Gemini 3.5 Flash handles a quick first pass on very long logs. Whatever you paste into a hosted model leaves your machine, so redact secrets first, every time.
| Symptom | Likely cause | Fix |
|---|---|---|
spawn npx ENOENT | Cursor cannot see Node on PATH | Use the absolute path to npx |
Connection closed right after start | Missing token or crash on launch | Read stderr in the log, check env values |
| Tools listed, calls return 401 or 403 | Expired or under-scoped GitHub token | Rebuild the token, authorize it for SSO |
docker: command not found | Docker missing or stopped | Start Docker Desktop, pre-pull the image |
| Figma refuses the connection | Desktop app closed or MCP server off | Open a design file, enable the server |
| Figma returns 404 | Old /sse path | Switch the URL to /mcp |
| Playwright executable missing | No matching browser installed | Run npx playwright install chrome |
| Playwright browser already in use | Locked profile folder | Close stray processes or add --isolated |
| Green dot, agent ignores tools | Too many tools, or Ask mode | Trim servers, switch to Agent mode |
Once your servers behave, MCP gets interesting well beyond code. PicassoIA also exposes its generation models through its own MCP connection and developer API, built on four models: PicassoIA Image, Image Editor Pro, PicassoIA Video and Seedance 2.5 Lite for video with audio. You set up the connection from the MCP page of your account at picassoia.com/en/mcp/accounts, and it behaves like any other server in Cursor, so every check above applies to it as well.
One limit is worth knowing when jobs seem to stall: an account runs up to 5 predictions at once, shared across all your credentials and MCP connections. A sixth job waits, and from the editor that can look like a hung server.
You do not need an MCP server to start, though. Open the web app, write a prompt and see a result in seconds:
Pick one real need from your last project, such as a hero image for a README, a header for a blog post or a mock product photo for a demo, and generate three versions. Compare them, change one detail at a time, and keep the one that fits. Open Picasso IA, write your first prompt, and see what your next project looks like.
