Ad space · Your tool here
PluginStack
Setup guide

Fix MCP error -32000: "Connection closed"

Checked against the official docs:

You add an MCP server, restart your client, and get MCP error -32000: Connection closed. The message is accurate but unhelpful: it only says that the connection to the server ended. The cause is almost always on the server side, usually in the first second after it launches. This guide shows how to find it fast.

Quick answer

-32000 is the code the MCP SDKs use for ConnectionClosed. For a local (stdio) server it means the server process exited, or its pipe closed, before the client finished talking to it. So the job is to find out why the server stopped:

  1. Copy the exact command, args and env from your config and run that command yourself in a terminal.
  2. Read what it prints. A healthy stdio server starts and then waits silently for input. If it prints an error and returns to the prompt, that error is your answer (wrong Node version, missing package, missing API key, bad path).
  3. Fix that, then restart the client fully. If you are on Windows and the command starts with npx, try the `cmd /c` fix first.

The rest of this page covers the usual causes, where to find each client's logs, and how to test a server without any client.

Free: MCP Starter Checklist

One page: Inspector smoke-test, Claude Code + Cursor connect steps, and the stdout gotcha. Join the list and download it free.

Markdown download + occasional PluginStack updates. No spam. Privacy policy.

What the error means

MCP clients talk to a local server over its standard input and output. When the process behind that pipe ends, the SDK rejects every pending request with MCP error -32000: Connection closed. We reproduced it with the official TypeScript SDK: a server command that starts and then exits with an error code produces exactly that message. A command that does not exist at all produces a different one, a spawn ... ENOENT error, because the client could not even start the process.

The error comes from the client, not the server, so the same server can show it in Claude Code, Claude Desktop, Cursor, VS Code and Codex. What differs between clients is only where the useful detail is logged.

Step 1: run the server by hand

This is the same test the Claude Code docs recommend. Run the server's command exactly as written in your config, with the same environment variables:

bash
# example: the official Memory server
npx -y @modelcontextprotocol/server-memory
  • It starts and sits there: the server itself works (press Ctrl+C to stop it). The problem is how the client launches it: the path, the environment, the working directory, or Windows npx (next section).
  • It prints an error and exits: the message names what is missing, such as a Node.js version, a package, or an environment variable. That is the real cause.

Set any env values from your config in the same terminal first (for example export API_KEY=... on macOS and Linux, or $env:API_KEY = "..." in PowerShell).

Step 2: the common causes

Windows and `npx`

On native Windows, a client that launches npx directly can fail to start it. One of the first reports of this exact MCP error -32000: Connection closed was Claude Code issue #3369 on native Windows. Wrap the command in cmd /c: see Fix "spawn npx ENOENT" for MCP servers on Windows.

The runtime is missing or too old

The server needs Node.js, Python or uv, and the client cannot find it or finds an old copy. Check node --version in the same environment the client uses. The official TypeScript reference servers declare Node 24 or newer from v2.0.0 (see what changed in the MCP reference servers v2), and a server that needs uvx needs uv installed. After installing a runtime, quit and reopen the client so it sees the new PATH.

A required API key or setting is missing

Many servers exit immediately if a required environment variable is not set. Check the server's README for its variables, and set them in the config's env block, not only in your shell. Claude Code's troubleshooting notes that a server may miss variables that are not in its own config entry, because the client passes a limited environment to stdio servers.

A wrong or relative path

Use absolute paths for local scripts and folders. Claude Code's docs say relative paths in command or args are a frequent cause of failed starts, because they resolve against the folder you launched the client from, not the config file's folder. Programs on your PATH, such as npx or uvx, are fine as they are.

The command was added wrongly (Claude Code)

With claude mcp add, everything after the -- separator is the server command. If you leave out the --, or quote the whole command as one string, Claude Code parses the pieces wrongly. Run claude mcp get <name> and check that the command shown is what you intended; if not, claude mcp remove <name> and add it again.

The package cannot be downloaded

The first npx -y run downloads the package, which can fail on an offline machine, behind a proxy, or with a broken npm cache. Running the command by hand (Step 1) shows the npm error. A slow first download can instead end as a startup timeout; Claude Code's default is 30 seconds and can be raised with MCP_TIMEOUT=60000 claude, and Codex's default is 10 seconds, raised with startup_timeout_sec in config.toml.

The server crashes on startup, or writes to stdout

If you wrote the server yourself, remember that a stdio server must never print logs to standard output: the MCP docs warn that it corrupts the JSON-RPC messages and breaks the server. Use stderr (console.error in Node, the logging module in Python). A plain crash on startup, such as an import error, also ends the connection.

Step 3: read the client's logs

  • Claude Desktop: logs are in ~/Library/Logs/Claude on macOS and %APPDATA%\Claude\logs on Windows. mcp.log covers connections and failures, and mcp-server-<name>.log holds that server's stderr output.
  • Claude Code: run /mcp to see which server failed. claude mcp list and claude mcp get <name> show failure details. For a server's stderr, run claude --debug=mcp and read the log under ~/.claude/debug/.
  • Cursor: open the Output panel (Cmd+Shift+U on Mac, Ctrl+Shift+U on Windows and Linux) and choose MCP Logs. See how to add an MCP server to Cursor.
  • VS Code: run MCP: List Servers from the Command Palette, pick the server, and choose to show its output.
  • Codex: run codex mcp list to check the entry, and type /mcp in the terminal UI to see active servers.

Step 4: test the server without a client

The MCP Inspector runs your server and lets you list and call its tools in a browser, with the client taken out of the picture. If the server works there, the problem is your client config; if it fails there too, the server is the problem.

Inspector, then your server's command and arguments (this example launches a locally built Node server)
bash
npx @modelcontextprotocol/inspector node build/index.js

FAQ

Is -32000 always a local server problem?

The code means "connection closed", which can also happen with a remote server if the connection drops. The advice above is for local stdio servers, which is where this error shows up most. For a remote server that needs sign-in, see Claude Code MCP "needs authentication".

It worked yesterday. What changed?

Usually the runtime or the package. With npx -y and no version, npx fetches the latest release on each launch, so a server update (or a Node update on your machine) can change behaviour. The official reference servers moved to v2 in October 2026; pinning a version with package@version is a quick way to test.

Does a stdout log line cause this error?

The MCP docs say writing to stdout from a stdio server corrupts the protocol and breaks the server. We could not show that a stray stdout line by itself produces -32000 in our own test, so treat it as a likely cause for a custom server and rely on Step 1 to confirm it.

Sources

Commands and config above come from these official docs. Tools change often, so check them for the latest steps.

PluginStack is independent and not affiliated with or endorsed by the companies mentioned. Spotted something out of date? Email pluginstackai@gmail.com.