MCP error -32000: Connection closed

What it means

The client started your server as a child process, and that process exited. The client’s pipe to it closed, so the request it was waiting on failed.

We reproduced it with a server that prints an error and exits during startup:

Client SDK	What it reported
TypeScript v1 (@modelcontextprotocol/sdk 1.32.2), used by many existing clients	MCP error -32000: Connection closed
TypeScript v2 (@modelcontextprotocol/client 2.4.0)	Connection closed (error code CONNECTION_CLOSED)

Both arrived within 15 ms of starting the process: the server did not hang, it died.

Not the same as a timeout

If the client waits and then reports MCP error -32001: Request timed out, the process is still running but never answered. In our tests that happened when the server wrote a startup banner to stdout (from console.log or print) and never replied. Some clients report stdout pollution as a closed connection instead, so if the steps below do not find a crash, check stdout too.

Find the cause in this order

Terminal1. Run the exact command from the client's config

Copy command and args from the client’s configuration, unchanged, and run them in a terminal:

node /absolute/path/to/server.js

ExpectedThe process starts and waits silently. Messages on stderr are fine. If it exits, the error it prints is your cause.

MCP client2. Read the client's log

The server’s stderr usually ends up in the client’s log. Claude Desktop, for example, writes files named mcp*.log; on Windows they are under %APPDATA%\Claude\logs. Where clients write MCP logs lists the other clients.

Terminal3. Start it through the Inspector

npx -y @modelcontextprotocol/inspector@2.12.0 --cli \
  node /absolute/path/to/server.js --protocol-era auto --method tools/list

ExpectedThe Inspector lists the tools. If it does, the server is fine and the client configuration is the problem.

The server crashes on start

The most common cause. Typical reasons:

• A required environment variable is missing. Your shell has the API key; the client does not pass it. Set it in the client’s env section for that server.
• A dependency is missing in the environment the client uses, such as a different Python virtual environment.
• The SDK major version does not match the code. Code written for an older SDK can fail at import time. With the Python SDK 2.x, from mcp.server.fastmcp import FastMCP raises ModuleNotFoundError: No module named 'mcp.server.fastmcp', because version 2 renamed FastMCP to MCPServer. With the TypeScript SDK, version 1 imports from @modelcontextprotocol/sdk do not exist in the version 2 packages.
• The runtime is too old. For example, the TypeScript SDK v2 needs Node.js 20 or later.

The command or path is wrong for the client

A command that works in your terminal can fail in the client:

• Relative paths. The client does not start the server in your project directory. Use absolute paths in args, or set the client’s working directory option if it has one.
• PATH is different. Desktop applications are not started from your shell, so they do not read .zshrc, .bashrc or nvm’s setup. Use the full path to node, python, uv or npx. When the command itself cannot be found, many clients report spawn … ENOENT instead of this error.

Windows: npx is not an executable

On Windows, npx is a batch script (npx.cmd), not an .exe. Some clients cannot start it directly. Two common fixes:

{ "command": "cmd", "args": ["/c", "npx", "-y", "your-mcp-server"] }

or point command at the full path of npx.cmd. We have not yet tested this on our Windows lab machine, so treat it as documented community practice.

Related

• Test a server with the MCP Inspector
• Your first server in TypeScript
• spawn … ENOENT: the program never started.
• Request timed out: the server is running but does not answer.