AgenticMarketMCP Error -32000: Connection Closed — Full Diagnosis Guide
-32000 connection closed means the MCP session started, then terminated before the client received a valid response. The server process crashed, timed out, or wrote invalid output to stdout.
This is the most common MCP error across Cursor, VS Code, and Claude Desktop. It affects both stdio and HTTP servers, but the causes differ completely between the two.
The short answer: If you're running a local stdio server, the cause is almost always stdout contamination or a PATH issue. If you're running a remote HTTP server, it's usually a timeout, auth failure, or proxy misconfiguration.
Stdio servers: the two causes that account for 90% of -32000 errors
Cause 1 — Stdout contamination
The MCP stdio transport uses your server process's standard output exclusively for JSON-RPC messages. If anything else writes to stdout — a debug log, a startup banner, a print() statement, a deprecation warning from a dependency — the client receives invalid JSON, drops the connection, and logs -32000.
The server runs fine in your terminal (where you read mixed output) and fails inside the IDE.
How to verify:
bash# Run your server and check if stdout contains anything other than JSON-RPC # If you see ANY non-JSON output, that's the problem node your-server.js 2>/dev/null | head -c 500 # For Python servers python your-server.py 2>/dev/null | head -c 500
If the output starts with a log message, a banner, or anything that isn't {"jsonrpc":"2.0"..., you've found the cause.
How to fix:
python# Python — WRONG: writes to stdout, breaks MCP stream print("Server starting...") # Python — CORRECT: stderr is invisible to the MCP client import sys print("Server starting...", file=sys.stderr)
typescript// TypeScript — WRONG: console.log writes to stdout console.log("Debug info"); // TypeScript — CORRECT: console.error goes to stderr console.error("Debug info");
Search your entire codebase for console.log, print(), and sys.stdout.write calls. Also check dependencies — a third-party library printing a deprecation notice on import will break your server without any change to your code.
For SDK-specific guidance, see the MCP Python SDK and TypeScript SDK documentation on stderr-safe logging.
Cause 2 — PATH resolution failure (nvm, pyenv, Homebrew)
Your IDE launches MCP servers as subprocesses using its own shell environment — which is not the same as your terminal. It doesn't source .bashrc, .zshrc, or your version manager's shell hooks.
If you use nvm, pyenv, fnm, or Homebrew-managed runtimes, the node or python binary your IDE finds may be different from — or completely absent from — what you see in your terminal.
How to verify:
bash# Find where your actual binaries live which node # → /Users/you/.nvm/versions/node/v22.4.0/bin/node which npx # → /Users/you/.nvm/versions/node/v22.4.0/bin/npx which python3 # → /Users/you/.pyenv/shims/python3
How to fix:
Use the absolute path in your MCP config instead of just the command name:
json{ "mcpServers": { "my-server": { "command": "/Users/you/.nvm/versions/node/v22.4.0/bin/npx", "args": ["-y", "some-mcp-package"] } } }
On Windows, use where node instead of which node to find the path.
HTTP/remote servers: causes of -32000
Server timeout
If the server takes too long to respond to the initialize request — common with serverless platforms (Vercel, Cloudflare Workers, AWS Lambda) during cold starts — the IDE drops the connection.
How to verify:
bash# Time the handshake response curl -s -w "\nResponse time: %{time_total}s\n" \ -X POST https://your-server-url/mcp \ -H "Content-Type: application/json" \ -d '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2024-11-05","capabilities":{}}}'
If response time is over 3 seconds, IDE timeouts are likely. Solutions:
- Implement a keep-warm cron ping
- Use edge runtimes for faster cold starts
- Move heavy initialization to lazy loading
Auth failure
A wrong or malformed Authorization header causes the server to reject the request silently. No useful error is surfaced — the IDE sees a closed connection and reports -32000.
A single extra space — Bearer token instead of Bearer token — is enough to cause this.
Proxy or firewall termination
Corporate proxies, VPNs, and load balancers with aggressive idle timeouts close the connection before the server responds. Check:
- Reverse proxy supports WebSocket/streaming if required
- Idle timeout is set above expected tool latency (30s minimum recommended)
- Monitor for 499/502/504 responses in gateway logs
Transport mismatch
If the client sends plain HTTP but the server expects SSE (or vice versa), the connection is established but immediately closed when the first message doesn't match the expected format.
Reading IDE logs to find the actual error
Cursor
Help → Toggle Developer Tools → Console tab
— or —
Output panel (Ctrl+Shift+U) → select "MCP" from dropdown
Look for Starting new stdio process, Client closed for command, or the raw error code after Connection closed.
VS Code
Output panel (Ctrl+Shift+U) → select "MCP" from dropdown
— or —
Help → Toggle Developer Tools → Console → filter for "mcp"
Claude Desktop
bash# macOS — stream log entries live tail -f ~/Library/Logs/Claude/mcp*.log # Windows — read the latest log file type %APPDATA%\Claude\logs\mcp*.log
Remember: Claude Desktop needs a full application quit, not just a window close, to reload config.
Quick diagnostic table
| Symptom | Most likely cause | Fix |
|---|---|---|
-32000 immediately on server start | Stdout contamination | Move all logs to stderr |
-32000 after "Starting new stdio process" | PATH issue — binary not found | Use absolute path from which node |
-32000 only on first call, works on retry | Cold start timeout (serverless) | Add keep-warm ping or increase timeout |
-32000 after config change | Config syntax error or wrong key | Paste config into jsonlint.com |
-32000 intermittently | Proxy/firewall idle timeout | Increase idle timeout to 30s+ |
-32000 only on specific machine | Different PATH environments | Use absolute paths on both machines |
Verify recovery
- Run your server through the MCP Playground — it shows handshake status, tool count, and response grade
- Use the MCP Inspector for local stdio servers:
npx @modelcontextprotocol/inspector node your-server.js - Confirm the fix is stable across 3+ consecutive runs
- Re-test from your IDE after a full restart
For a complete testing workflow, see How to Test MCP Servers.
Related troubleshooting
- MCP Server Not Working? The Complete Troubleshooting Guide — covers all failure modes, not just -32000
- MCP Server Not Showing Tools — when the server connects but tools don't appear
- MCP Server Connected But Agent Ignores Tools — tools visible but never called
- How to Test MCP Servers — debug handshakes, tool calls, and response times
- MCP Error -32601 Method Not Found — different error: server reached but method unknown
- Could Not Connect to MCP Server — connection never established at all
- No Working IDE Endpoint Available — config parsed but no endpoint passed health checks
IDE setup guides: VS Code · Cursor · Claude Desktop · Windsurf