How to Fix npx-Based MCP Servers That Fail to Start on Windows in Cursor and Claude Code

When a Model Context Protocol (MCP) server fails to start in Cursor or Claude Code on Windows, check how the client launches npx. An MCP server is a local program that gives a coding client access to tools or data. Many MCP servers send and receive data through standard input and output, known as stdio.

On Windows, npm provides npx as a .cmd batch file. Some programs that launch commands directly cannot run this file like a regular executable. First, try launching npx through cmd /c. If the server starts but the client still cannot connect, try running the server with Node.js and its JavaScript entry point.

Why a direct npx command can fail

npx runs a command from an npm package and downloads the package when needed. On Windows, npm provides the command through npx.cmd. Node.js documents that some child-process methods cannot launch Windows .cmd and .bat files directly. Those methods need a shell such as cmd.exe to run the files. This mismatch can cause an error such as spawn npx ENOENT or prevent the configured server from connecting. The Node.js child-process documentation describes this Windows limitation.

This explanation applies to failures that occur when the client launches the server. Other problems can also prevent an MCP connection: the package name may be wrong, the configuration may be invalid, an argument may be missing, or the server may fail during startup. First, confirm that the client reads the configuration file you edited and that the JSON is valid. Cursor uses an mcp.json configuration. Claude Code has its own MCP configuration and scopes. Follow the relevant Cursor MCP documentation or Claude Code settings documentation, rather than using one client’s file location for the other.

Try cmd /c first

Set the server’s command to cmd and put /c before npx. The /c option tells Windows Command Prompt to run the command that follows and then exit. The MCP reference filesystem server uses this Windows launch pattern in its setup instructions.

For a configuration that uses the mcpServers structure, the pattern looks like this:

{
  "mcpServers": {
    "example": {
      "command": "cmd",
      "args": [
        "/c",
        "npx",
        "-y",
        "PACKAGE_NAME",
        "PACKAGE_ARGUMENTS"
      ]
    }
  }
}

Replace PACKAGE_NAME and PACKAGE_ARGUMENTS with the package name and arguments listed in the server’s setup instructions. If the server takes no extra arguments, remove the argument placeholder. Put each argument in its own item in the args array. Keep any required environment variables and working-directory settings.

Use the configuration format and location for the client you are running. Both clients can use the same launch pattern, and each has its own configuration files and management tools. The MCP project’s Windows launch discussion also describes the cmd /c workaround.

Check the command before changing more settings

Run the server’s documented command with its arguments in a terminal. If the command fails, verify the package name and required arguments. Check the credentials and inspect the server startup error before changing Cursor or Claude Code settings. The MCP quickstart recommends running the command manually and checking configuration paths and logs.

If the command works in the terminal but fails in the client, confirm that the client reads the file you edited and that its command and paths match the working terminal command. The client may launch the command with a different environment or path, which can cause it to fail. Check the client’s server status and diagnostics too. Claude Code documents /mcp for checking MCP servers and /doctor for broader troubleshooting in its troubleshooting documentation. Cursor’s diagnostic steps can vary by version, so use the tools available in your installed version. Claude Code’s commands may not apply to Cursor.

Run Node directly if the wrapper does not connect

The cmd /c wrapper handles the Windows .cmd launch issue, but it does not ensure that every server connects over stdio. In a report about Playwright MCP and Claude Code, the wrapper started the process, but the MCP connection still failed. The reporter worked around the problem by running Node.js directly with the server’s JavaScript entry point. This report covers one setup, but it shows why direct Node.js execution is a useful next test. See the Playwright MCP issue report.

A direct launch uses the paths for the Node executable and the server entry point:

{
  "mcpServers": {
    "example": {
      "command": "C:\\Path\\To\\node.exe",
      "args": [
        "C:\\Path\\To\\server\\entrypoint.js",
        "SERVER_ARGUMENTS"
      ]
    }
  }
}

Replace both paths with locations on your machine, and replace or remove the argument placeholder. In JSON, double each backslash in a Windows path. Each package determines its own entry-point path, so no single path works for every MCP server. Install the package in a stable location because this approach skips npx’s package-fetching behavior.

What I'm building

Delegate tasks. Get software.

Give Vroni a GitHub issue, bug report, spec, or rough idea. It reads the repo, plans the change, writes code, runs checks, and works toward a review-ready pull request.

Take a look at vroni.com