MCP error -32000 'Connection closed': what it means and how to fix it

Symptom: The client reports `MCP error -32000: Connection closed` and the server never comes up.
Short answer
-32000 'Connection closed' means the server process started and then died before it finished the MCP handshake — so it's a crash, not a network problem. The cause is almost always a missing dependency, a bad command/path, or an env var the server needs and didn't get. The startup log line tells you which.
Why it happens, ranked by how often it's the real cause
1. Server crashed on startup (missing dependency or env)
The process spawns, throws during init (missing package, missing API key), and exits — the client sees the pipe close mid-handshake and reports -32000.
Fix: Run the config's command directly in a terminal; the real stack trace appears there. Install missing deps and fill required env vars.
2. Wrong command or non-existent package
`npx -y some-package-that-doesnt-exist` exits non-zero immediately, closing the connection.
Fix: Verify the package exists (npm/PyPI) and the command is spelled exactly as on the server's page here.
3. Runner not found in the app's environment
npx/uvx resolves in your shell but not inside the GUI client, so the spawn fails and the connection closes.
Fix: Use the absolute path to the runner (`which npx`) as the command.
Fix it step by step
- 1Copy the exact command + args from your config.
- 2Run it in a terminal — the crash reason prints immediately.
- 3Fix the named problem (install dep, correct package name, add env var).
- 4Swap the runner for its absolute path if it works in terminal but not the client.
- 5Restart the client fully and re-check.
Still stuck?
If the command runs and stays alive in your terminal but the client still reports -32000, the server may be writing logs to stdout and corrupting the stdio stream — check the server's repo for a 'quiet'/'log-to-file' flag.
FAQ
What does MCP error -32000 mean?
It's a JSON-RPC error meaning the connection was closed — in MCP, the server process died before finishing the handshake. It's a startup crash, not a network issue. The startup log shows the real cause.
Is -32000 a network/firewall problem?
Almost never for local (stdio) servers — it's the process exiting. Run the command in a terminal to see the crash. Firewalls only matter for remote (HTTP/SSE) servers.