Claude MCP setup

AlexHacker Expert 2h ago 425 views 10 likes 3 min read

Solving a Claude MCP setup loop that kept crashing my Desktop app

The goal is simple: give Claude Desktop the ability to read my local filesystem and query my database without manually uploading CSVs every ten minutes. I spent four hours last Wednesday fighting with the claude_desktop_config.json file because the logs kept lying to me. If you are trying to connect a Model Context Protocol (MCP) server, the most likely point of failure is your Node path or a silent JSON syntax error.

Why did my MCP server keep failing to initialize?

I tried adding the Brave Search and Google Maps MCP servers. The app started, but the "tools" icon never appeared. I checked the logs in %APPDATA%\Claude\logs (on Windows) and found this repeating nightmare:

[ERROR] MCP Server connection failed: Spawn error: ENOENT. Command "npx" not found in path.

The wild part? npx works fine in my terminal.

The issue is that Claude Desktop doesn't inherit your shell's environment variables. It doesn't know where Node is installed. I had spent an hour trying to "fix" the server code when the problem was actually just the shell environment.

To fix this, stop using npx in your config. Use the absolute path to the executable.

The fix that actually worked

I found my npx path by running where npx in PowerShell. It was C:\Program Files\nodejs\npx.cmd.

I edited my config file here:
%APPDATA%\Claude\claude_desktop_config.json

I changed the server definition from this:

"brave-search": {
  "command": "npx",
  "args": ["-y", "@modelcontextprotocol/server-brave-search"]
}

To this:

"brave-search": {
  "command": "C:\\Program Files\\nodejs\\npx.cmd", 
  "args": ["-y", "@modelcontextprotocol/server-brave-search"],
  "env": {
    "BRAVE_API_KEY": "BPMXXXXXXXXXXXXXXXXXXXXXXXX"
  }
}

Note: Double backslashes are mandatory in JSON paths on Windows.

I restarted Claude (fully quit from the system tray, not just closed the window) and the tools finally popped up.

Comparing MCP setups across different tools

Depending on what you are trying to automate, you might find different "flavors" of MCP implementations. I've tested three common setups over the last month.

The Node-based servers are definitely the most stable, but the pathing issue I hit is a common bottleneck. If you are diving deep into AI Coding, you'll realize that the "last mile" of integration—getting the AI to actually talk to your local machine—is where most developers lose their patience.

Dealing with the "JSON Parse Error" ghost

Another thing that tripped me up: adding a trailing comma to the last item in the mcpServers object.

Standard JSON doesn't allow trailing commas. If you have one, Claude Desktop won't tell you "Line 14 has a trailing comma." It will simply refuse to load any MCP servers, and you'll be left staring at a blank tool menu.

If your config looks correct but isn't working, run it through a JSON validator. I wasted 45 minutes on a single comma.

Where to find better server configs

Setting up the JSON is the boring part. The real value is finding servers that actually do something useful. I've found that the community-driven approach is the only way to keep up.

This is why I spend time in the PromptCube community. Instead of guessing which args a specific MCP server needs, I can see what other developers are using for their local RAG setups or database connectors. It's the difference between reading the official documentation (which is often sparse) and seeing a real-world implementation that actually works on macOS or Windows.

If you want to stop guessing and start shipping, joining a group of practitioners is better than staring at a README. You can find the PromptCube community online—just look for their developer forums and join the discourse.

When to give up on MCP and just use a script

MCP is great, but it's not a silver bullet. If you have a task that requires complex state management or takes longer than 30 seconds to execute, the timeout in Claude Desktop might kill the process.

For heavy data processing, I've stopped trying to wrap everything in an MCP server. Instead, I use the AI to write a standalone Python script, run it locally, and then feed the output back into the chat. It's less "magical" than a tool call, but it doesn't crash your app.