My MCP Server Wouldn’t Connect to Claude — and the Fix Was the Last Thing I Thought to Check

Is your MCP server not connecting in Claude Desktop even though the JSON looks correct? The cause might be somewhere you didn’t expect.

Contenidos mostrar

If you’ve recently started using Claude Desktop, you’ve probably already come across MCP servers. These are small integrations that allow Claude to connect to external tools, databases, or services that provide real-time data. The idea is powerful: instead of relying only on its built-in knowledge, Claude can query live information or interact with other systems.

In theory, setting them up shouldn’t be particularly complicated.

But things get frustrating when you follow the instructions step by step, the configuration file looks perfectly fine… and the server simply refuses to connect.

That’s exactly what happened to me.

I was trying to build a simple crypto “advisor” inside Claude that could fetch real-time prices, trading volume, and other market data. To do that, I needed to connect Claude Desktop to the CoinGecko MCP Server, which allows Claude to access CoinGecko’s data directly.

CoinGecko’s documentation explains the process clearly: install Node.js, add the MCP server to the claude_desktop_config.json file, and restart Claude Desktop. I followed the official guide and even double-checked the steps with Claude itself while setting everything up.

But when I tried to activate the connector, something wasn’t working.

Claude would attempt to connect for a while and then show a simple message: connection failed. No details. No hint about what was going wrong.

I checked the configuration several times, compared my JSON with the example in the documentation, and confirmed that everything looked correct. Yet the MCP server still refused to connect.

This guide might save you the time I spent looking in the wrong place.

When something like this fails, the most logical assumption is that the error is somewhere in the configuration. And that’s exactly where I started looking.

The first thing everyone checks (and it wasn’t the problem)

Before investigating anything unusual, I reviewed all the typical things that can break in this type of setup.

The claude_desktop_config.json file was valid. No trailing commas, no missing quotation marks, no obvious syntax errors. I also confirmed that Node.js was properly installed and working from the command line.

The CoinGecko MCP server was referenced exactly as described in the official documentation.

In other words, everything seemed correct.

And yet the server still wouldn’t connect.

The real culprit: the firewall, not the JSON

After checking the configuration multiple times without finding anything wrong, I decided to try something that initially felt almost too obvious: opening the Windows firewall settings and checking which applications were allowed to access the network.

That’s where the problem was hiding.

Neither Claude Desktop nor Node.js had permission to communicate through the firewall. Windows 11 was silently blocking them, without showing any warning inside the app or any error message pointing in that direction.

Once you see it, the behavior makes sense: the MCP server tries to start, the system blocks its network access, and Claude simply reports that the connection failed.

Here’s how to fix it:

Open Control Panel → System and Security → Windows Defender Firewall.
Click “Allow an app or feature through Windows Defender Firewall.”
Look for Claude and Node.js in the list.
Make sure both are allowed to communicate (at least on private networks).
Save the changes and restart Claude Desktop.

After doing this, I opened Claude again and went back to the connectors section. The CoinGecko server now appeared with the toggle switched on. Connected.

A quick test — asking for the current Bitcoin price and 24-hour trading volume — confirmed that everything was working as expected.

The issue wasn’t the JSON configuration.

It was simply a missing firewall rule.

Why Windows 11 doesn’t always warn you

What makes this problem confusing is that it’s not actually a bug. It’s just how the Windows firewall works.

Normally, when an application tries to access the network for the first time, Windows displays a dialog asking whether you want to allow the connection. But that prompt doesn’t always appear. It can depend on how the application was installed, your user permissions, or certain system settings.

When that happens, the application may end up blocked without the user ever seeing a warning.

Since the error message in Claude Desktop doesn’t mention the firewall, it’s easy to assume the issue is somewhere else — the JSON configuration, missing dependencies, or the MCP server setup itself.

That’s why it’s worth checking firewall permissions before diving into deeper debugging.

If this doesn’t solve the issue

The firewall is a common cause, but it’s not the only possible one. If the server still doesn’t connect after allowing Claude and Node.js, there are a few other things worth verifying.

For example:

Make sure the claude_desktop_config.json file doesn’t contain syntax errors. An online JSON validator can catch mistakes that are easy to miss.
Confirm that Node.js is correctly installed and that the node command works in your terminal.
Verify that the path to the MCP server executable in the configuration file is correct.
Check whether your antivirus software is blocking the connection independently of the Windows firewall.

For the CoinGecko MCP server specifically, the official documentation can also help you double-check that your configuration matches the expected setup.

A simple fix for a problem that gives no clues

The most frustrating part about issues like this is that the real cause leaves almost no visible trace. The app fails, the server doesn’t connect, and the actual problem sits in a system layer that most people wouldn’t think to check first.

A firewall silently blocking Node.js is exactly that kind of problem: easy to fix once you know where to look, but surprisingly hard to diagnose when all the clues seem to point toward the configuration.

If your MCP server isn’t connecting and the JSON looks correct, the firewall is one of the first places worth checking before spending time troubleshooting everything else.