Fixing "spawn npx ENOENT" in Cursor's MCP config

ENOENT is "Error NO ENTity" — the operating system could not find the file it was asked to execute. When Cursor prints spawn npx ENOENT, the missing file is npx itself, not your MCP server. The server never started, so nothing about the server's code or config is at fault yet.

This matters because the obvious next move — reinstalling the MCP server, or rewriting its arguments — cannot possibly help. The failure happens one step earlier, when Cursor tries to launch the process at all.

The reason it happens on a machine where npx clearly works: a GUI application launched from Finder, Spotlight or the Dock does not inherit the PATH from your shell profile. Your terminal reads ~/.zshrc and picks up nvm, Homebrew or fnm; Cursor, launched by the window manager, gets a much shorter system PATH that usually contains only /usr/bin, /bin, /usr/sbin and /sbin. If node was installed through a version manager, it lives somewhere else entirely and is invisible to Cursor.

Run `which npx` in your terminal and note the path. If it contains .nvm, .fnm, .volta, or /opt/homebrew, you have just confirmed the diagnosis: that directory is almost certainly not on the PATH Cursor sees.

For a definitive check, open Cursor's own integrated terminal and run `echo $PATH` there, then compare it with `echo $PATH` in your normal terminal. On macOS the two are frequently different. The integrated terminal usually does load your profile, so it is not a perfect proxy for what the MCP subprocess sees, but a difference here is a strong signal.

Rather than hoping Cursor can resolve npx, tell it exactly where the binary is. Take the output of `which npx` and put it in the command field verbatim.

This is the fix we recommend first because it does not depend on shell configuration, survives restarts, and behaves identically whether Cursor was opened from the Dock or the command line. Its one downside is that the path embeds a Node version if you use nvm, so it will need updating when you upgrade Node — a worthwhile trade for a config that actually works.

The same applies to uvx for Python-based servers: use the absolute path there too.

Starting Cursor with the `cursor` command from a shell means it inherits that shell's full environment, including the PATH that makes npx resolvable. This is useful for confirming the diagnosis quickly, but it is a poor permanent fix: the moment you open Cursor from the Dock out of habit, the error is back.

Treat this as a diagnostic step rather than a solution. If launching from the terminal fixes it, you have proven the problem is PATH inheritance and can then apply fix 1 or 3 properly.

If you do not need multiple Node versions, installing Node from the official installer places it in /usr/local/bin, which is on the default PATH that GUI applications see. This removes the class of problem entirely rather than working around it.

This is the wrong choice if you rely on nvm to switch versions per project, since a system-wide install can shadow your managed versions and cause confusing mismatches. For most people who hit this error while just trying to get one MCP server running, it is the simplest permanent answer.

Check that the package name in your config actually exists. A typo produces a different but easily-confused error: npx will resolve fine, then fail to find the package, which surfaces as a non-zero exit rather than ENOENT. If the message changed after applying a fix above, you have made progress and are now debugging a different problem.

On Windows, ENOENT more often means npx.cmd rather than npx — the extension matters, and some configs need the full `npx.cmd` name or a shell wrapper.

Finally, verify the server itself is installable at all by running the exact command from your config in a terminal. If it fails there too, the problem is the server or the package, and the Cursor configuration was never the issue.