By Shekhar — Founder, AgenticMarket. Tested on VS Code 1.98, Cursor 0.47, and Claude Desktop 0.9 on macOS 15 Sequoia and Windows 11. Last reviewed March 2026.

If your MCP server isn't working — no tools showing up, no error that means anything, config looks correct — the fastest path to a fix starts with one question that cuts the problem space in half.

Is the server a local stdio server or a remote HTTP server?

• Stdio server — runs as a process on your machine, launched by your IDE. Config looks like "command": "npx", "args": ["-y", "some-package"]. The most common MCP server not working failures here involve your machine's environment — PATH, runtimes, stdout.
• Remote HTTP server — runs at a URL somewhere else. Config has a "url" field. Failures here come from config key names, restarts, and auth.

These two types break in completely different ways. Most troubleshooting guides cover one and ignore the other. This covers both — but start with the config layer below, because those problems affect everyone and account for the majority of silent failures.

---

Step 1 — Check the config layer first

Silent failures are the worst kind. No error, server just doesn't appear. The config layer is where most of them live.

Wrong key name

The single most common cause of MCP servers not loading. Different tools use different key names, and using the wrong one produces no error — the config is valid JSON, the tool silently ignores the content.

If you copied a config from a Cursor guide into VS Code, or vice versa, this is almost certainly the problem. Check the root key name before anything else.

JSON syntax error

A single misplaced comma, missing quote, or unclosed bracket breaks the entire config file — not just the new entry you added. All servers stop loading, with no indication of which line caused it.

Paste your config into jsonlint.com before concluding there's a deeper problem.

Wrong config file location

You may be editing the right format in the wrong location. Each tool reads from a specific path, and if you're editing a workspace config (.vscode/mcp.json, .cursor/mcp.json) expecting the server to appear globally, it won't.

Claude Desktop needs a full quit, not just a window close

Claude Desktop does not reload config when you close the window or minimise. It needs a full application restart — Cmd+Q on Mac, right-click the taskbar icon and Exit on Windows. After reopening, wait a few seconds before testing. There's no visual confirmation the config loaded; the only way to verify is to ask Claude something that requires the server.

This caught me out more than once when I first set up Claude Desktop. You close the window, reopen it, nothing works, and you assume the config is wrong — but the app was never actually restarted.

Not in agent mode (VS Code)

MCP tools in VS Code are only available when Copilot Chat is in Agent mode. In Ask mode, the tools panel doesn't appear and servers aren't called even if correctly configured. Look for the mode selector in the chat input — it defaults to Ask. Switch it to Agent.

Cursor: check the MCP status panel

Go to Cursor Settings → Features → MCP Servers. Each server shows a status indicator. A grey or red dot means it didn't connect. Hovering often shows the actual error. This panel is the fastest way to confirm whether Cursor can see the server at all, separate from the config question.

---

Step 2 — Stdio server problems

If your server runs locally via npx, node, python, or uvx, these are the failure modes that don't appear in HTTP troubleshooting guides.

The PATH problem (extremely common with nvm and pyenv)

Your IDE launches MCP servers as subprocesses using its own shell environment — which is not the same as your terminal. It doesn't load .bashrc, .zshrc, or your version manager's shell hooks.

If you use nvm for Node.js or pyenv for Python, the binaries your IDE can find may be different from — or completely absent from — what you see in your terminal. The server process starts, immediately fails to find its runtime, and exits. Cursor logs this as -32000: Connection closed.

Find the absolute path in your terminal and use it directly in your config:

bashCOPY
# Find where your actual node/npx binaries live
which node
# → /Users/you/.nvm/versions/node/v20.11.0/bin/node

which npx
# → /Users/you/.nvm/versions/node/v20.11.0/bin/npx

which python3
# → /Users/you/.pyenv/shims/python3

Then replace the command name with the full path:

jsonCOPY
{
  "mcpServers": {
    "my-server": {
      // Use the absolute path from `which npx` — never just "npx" with nvm
      "command": "/Users/you/.nvm/versions/node/v20.11.0/bin/npx",
      "args": ["-y", "some-mcp-package"]
    }
  }
}

Stdout contamination (the cause of most -32000 errors)

The stdio MCP transport uses your server process's standard output exclusively for JSON-RPC messages. If anything else writes to stdout — a startup banner, a debug log, a print() statement from a dependency — it corrupts the stream. The client receives invalid JSON, drops the connection, and logs -32000: Connection closed.

The server runs fine in your terminal (you can read mixed output) and fails completely inside an IDE. I've hit this with servers where a third-party dependency was printing a deprecation notice to stdout on import.

Move every log call from stdout to stderr:

pythonCOPY
# Python — wrong: this writes to stdout and breaks the MCP stream
print("Server starting...")

# Python — correct: stderr is invisible to the MCP client
print("Server starting...", file=sys.stderr)

typescriptCOPY
// TypeScript — wrong
console.log("Debug info");

// TypeScript — correct: console.error goes to stderr, not stdout
console.error("Debug info");

Search your entire codebase for stdout writes, including inside any imported packages you don't control. If you suspect a dependency, wrap its import and check sys.stdout before and after.

For FastMCP users, the FastMCP logging documentation covers how to redirect logs to stderr without breaking the protocol. The official MCP Python SDK and TypeScript SDK both default to stderr-safe logging.

Missing -y flag on npx

jsonCOPY
"command": "npx",
"args": ["some-mcp-package"]

Without -y, npx prompts for confirmation before installing a new package. With no interactive terminal, it waits indefinitely. The IDE times out or shows the server as stuck indefinitely.

Always include -y:

jsonCOPY
"command": "npx",
"args": ["-y", "some-mcp-package"]

Floating @latest versions

jsonCOPY
"args": ["-y", "some-mcp-package@latest"]

@latest resolves at runtime. A breaking change in a new version silently breaks your server on the next install. Pin the version you've tested:

jsonCOPY
"args": ["-y", "some-mcp-package@1.4.2"]

How to read MCP logs for stdio servers

Cursor doesn't surface subprocess output in its main UI. To see what's actually happening:

1. Help → Toggle Developer Tools → Console tab — shows raw error output from server processes
2. Output panel (Ctrl+Shift+U) → select the MCP channel from the dropdown

Look for Starting new stdio process, Client closed for command, or the error code. Connection closed immediately after starting is almost always stdout contamination or a PATH issue.

For Claude Desktop, the MCP logs are written to disk:

bashCOPY
# macOS — stream new entries as they arrive
tail -f ~/Library/Logs/Claude/mcp*.log

# Windows — read the latest log file
type %APPDATA%\Claude\logs\mcp*.log

---

Step 3 — Remote HTTP server problems

If your server has a "url" field in the config — or if you installed it through a platform like AgenticMarket — these are the relevant failure modes.

Server not responding at the URL

The basic check. Test the endpoint directly before debugging anything else:

bashCOPY
# Send a minimal MCP initialize request to your server URL
# Replace https://your-server-url/mcp with your actual endpoint
curl -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 you get a connection error, the server is down. If you get an HTML page instead of JSON, the URL is wrong or pointing at the web app root rather than the MCP endpoint.

Auth header missing or malformed

Remote servers that require authentication fail silently if the header is wrong — no visible error, the server just doesn't respond. Both VS Code and Cursor support auth headers in config:

jsonCOPY
{
  "servers": {
    "my-server": {
      "type": "http",
      "url": "https://your-server-url/mcp",
      "headers": {
        // The exact header name and format must match what the server expects
        "Authorization": "Bearer your-token-here"
      }
    }
  }
}

A single extra space — Bearer token instead of Bearer token — will cause auth to fail with no useful error. If you're using AgenticMarket, the CLI writes these headers automatically. If you're configuring manually, copy the expected format from the server's documentation exactly.

Transport mismatch: HTTP vs SSE

Older MCP servers used Server-Sent Events (SSE) as their transport. Newer servers use Streamable HTTP (the current standard since March 2025, per the MCP specification). Some IDEs detect this automatically; others don't.

If a server that used to work stopped after an IDE update, check whether the server dropped SSE support. The error typically looks like a timeout or an immediate connection close.

Missing type field in VS Code

VS Code remote servers need "type": "http" explicitly:

jsonCOPY
{
  "servers": {
    "my-server": {
      "type": "http",
      "url": "https://your-server-url/mcp"
    }
  }
}

Omitting type causes VS Code to default to stdio and try to launch the URL as a subprocess command. It fails immediately, and the error message looks like a local process crash.

Cold start delays on serverless endpoints

If the server runs on Vercel, Cloudflare Workers, or AWS Lambda and hasn't received traffic recently, the first request can take several seconds. Your IDE may timeout before the response arrives and mark the server as failed.

Wait 30–60 seconds after the first failure and try again. If the second attempt succeeds, the server is working but cold-starting. Ask the server's author if they run a health-ping to keep it warm.

---

AgenticMarket-specific fixes

If you installed a server through AgenticMarket and it's not working, check these in order before debugging the server itself.

Check your balance first. AgenticMarket only routes calls when you have credits. A zero balance causes all tool calls to fail silently from the IDE's perspective.

bashCOPY
agenticmarket balance

If it's empty, top up at agenticmarket.dev/topup. Credits never expire.

Verify your API key is stored. The CLI keeps your key in ~/.agenticmarket/config.json. If the file was deleted or the key expired:

bashCOPY
# Check your current auth status
agenticmarket whoami

If this returns an error, re-authenticate:

bashCOPY
agenticmarket auth am_live_your_key_here

Reinstall cleanly. If the config was manually edited and is now inconsistent, a clean reinstall is faster than debugging it:

bashCOPY
# Remove clears all config entries the CLI previously wrote
agenticmarket remove server-name
agenticmarket install username/server-name

Check the server's health status. AgenticMarket monitors every listed server. If the creator's endpoint is down, the server's status in the browse page updates accordingly. An inactive server means the creator's infrastructure is down — not your configuration.

---

The tools appear but the AI won't use them

This is a separate problem class — the server is connected, tools are visible, but the assistant ignores them.

In Cursor and VS Code: Check the tools toggle in the chat input — individual tools can be disabled per session. In VS Code, also confirm the tool appears in the Configure Tools panel. If you're near Cursor's 40-tool limit across all servers, some tools get deprioritised. Disable servers you're not actively using.

In VS Code: Try prompting more explicitly: "Use the [tool-name] tool to..." rather than natural language the model may resolve without calling anything.

In Claude Desktop: Claude sometimes declines to call external tools for queries it can answer from training data. Give it a task that clearly requires live data — fetching a specific URL, checking a current status — to confirm the tool path works end to end.

---

Quick reference: which error means what

---

Still Not Working? Where to Get MCP Help {#get-help}

The MCP protocol's GitHub issues and community forums are genuinely active. For Cursor-specific problems, forum.cursor.com has a dedicated MCP section where the Cursor team responds. For VS Code, file MCP bugs against the GitHub Copilot extension repository.

If the server you're trying to use is installed through AgenticMarket, reach out at support@agenticmarket.dev with your agenticmarket whoami output and the server name.

Related: If you haven't installed the server yet or want to switch to a one-command approach, see How to Install MCP Servers Without Editing JSON. If you built the server you're debugging and want to list it to earn from it, see How to Monetize Your MCP Server.

---

Common questions about MCP server failures {#faq}

Why does VS Code use servers but Cursor uses mcpServers?

Each tool chose its own key name independently — the MCP spec doesn't enforce a config format. VS Code used servers to align with its language server conventions; Cursor and most others followed an earlier community default of mcpServers. They're functionally identical but the wrong key silently breaks everything.

Can stdout contamination cause -32000 even if the server works fine in the terminal?

Yes, and this is exactly what makes it hard to diagnose. In a terminal, you read the combined output fine. In an IDE, the MCP client reads stdout expecting only JSON-RPC and breaks on the first non-JSON character. The server is running correctly; the transport is broken. Move everything to stderr.

Why does Claude Desktop stop finding my MCP server after I edit the config?

Claude Desktop doesn't watch its config file. You need a full application quit and reopen — not just closing the window. On Mac, Cmd+Q. On Windows, right-click the taskbar icon and choose Exit. A window close leaves the process running with the old config loaded.

Why does @latest cause intermittent MCP server failures?

@latest resolves to whatever the current version is at the moment npx runs it. If a new version of the package introduces a breaking change or stdout output, your server breaks on the next restart — with no change to your config. Pinning a specific version like @1.4.2 makes failures reproducible and intentional.

The MCP server works on one computer but not another. What's different?

Nine times out of ten it's the PATH problem. The computer where it works has node or python on the system PATH directly; the one where it fails uses nvm or pyenv and the IDE can't find the runtime. Use which node on the working machine, check if the path looks like .nvm/versions/..., and use the absolute path in the config on both machines.

---

Last updated March 2026. Tested on VS Code 1.98, Cursor 0.47, and Claude Desktop 0.9 — macOS 15 Sequoia and Windows 11. The MCP protocol is moving fast — if an error you're seeing isn't covered here, open an issue and I'll add it.

---

Which failure mode caught you out? The PATH problem with nvm catches almost everyone at least once — drop a comment if you hit a different one. It helps me keep this guide updated.

I write about MCP tooling and the agentic AI developer ecosystem roughly twice a month. Subscribe to the AgenticMarket newsletter if that's useful.