MCP Server Not Showing Up in Claude Desktop? The 6 Real Causes (Windows-First Fix Guide)

#Why does an MCP server not show up in Claude Desktop?

Six causes explain nearly every "server missing" report. In rough order of frequency:

1. Invalid JSON in the config file. One trailing comma, a smart quote pasted from a blog post, or a // comment and Claude Desktop silently ignores the entire file. JSON doesn't allow comments or trailing commas — ever.
2. Windows path escaping. C:\Users\you\Desktop is invalid inside JSON. Every backslash must be doubled: C:\\Users\\you\\Desktop. A single backslash makes the file unparseable or the path wrong.
3. npx / Node.js problems. Most servers launch via npx, which requires Node.js on your PATH. On Windows, npx is actually npx.cmd — a batch shim that child_process.spawn() can't always execute directly, which is why the cmd /c wrapper exists (claude-code#9594, servers#3460).
4. You didn't fully quit Claude Desktop. Closing the window is not enough — the app keeps running in the system tray (Windows) or dock (macOS). Config is only re-read on a true quit-and-relaunch. The MCP debugging docs are explicit: "fully quit and reopen; closing the window is not enough."
5. You edited the wrong config file. After Claude Desktop moved to MSIX packaging on Windows, some installs read the config from a virtualized path under %LOCALAPPDATA%\Packages\... while "Edit Config" opens the old %APPDATA% file. Your perfect config never gets read. (Details in the Windows section below.)
6. Missing environment variables. Stdio MCP servers inherit only a limited subset of your environment. An API key that works in your terminal doesn't exist for the server unless you put it in the env block of the config.

Work through these in order — the first three are config-file problems you can rule out in a minute, the last three are runtime problems the logs will confirm.

#Where is claude_desktop_config.json on Windows and Mac?

Per the official MCP quickstart, the file lives at:

• Windows: %APPDATA%\Claude\claude_desktop_config.json (typically C:\Users\<you>\AppData\Roaming\Claude\claude_desktop_config.json)
• macOS: ~/Library/Application Support/Claude/claude_desktop_config.json

The supported way to open it: Claude menu → Settings... → Developer tab → Edit Config. That button creates the file if it doesn't exist yet.

Windows caveat (cause #5): on MSIX-packaged installs, the app may actually read from:

%LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\claude_desktop_config.json

If that folder exists on your machine, that copy wins. The tell: mcp.log stays completely empty after a restart, because Claude never attempted to launch anything from the file you edited. Fix: edit the LocalCache copy (or keep both in sync by copying — do not symlink them; that's been reported to produce a blank white window on launch).

#How do you validate the JSON in 30 seconds?

Don't eyeball it. On Windows, open PowerShell:

Get-Content "$env:APPDATA\Claude\claude_desktop_config.json" -Raw | ConvertFrom-Json

If it prints an object, your JSON parses. If it throws, the error message points at the broken spot. Node works too: node -e "require('C:/Users/you/AppData/Roaming/Claude/claude_desktop_config.json')".

The three killers to look for:

• Trailing comma after the last entry in mcpServers or args
• Single backslashes in Windows paths (must be \\)
• Smart quotes (“ ”) from copy-pasting out of a formatted blog post — retype them as straight quotes

Parsing is necessary but not sufficient: the paths inside must also be absolute and real. The MCP docs warn that the server's working directory is undefined when launched by the client, so relative paths like ./data will break even with valid JSON.

#Windows-specific fixes: paths, npx, and cmd /c

1. Escape every backslash. In JSON, "C:\\Users\\you\\Desktop" is the string C:\Users\you\Desktop. Forward slashes (C:/Users/you/Desktop) also work in most Node-based servers and sidestep the problem entirely.

2. Verify Node and npx exist. In a fresh terminal: node --version and npx --version. If either fails, install the Node.js LTS from nodejs.org. If you use nvm-windows, remember Claude Desktop doesn't run your shell profile — the Node that nvm activates in your terminal may not be visible to the app.

3. Test the server by hand. This is the single highest-signal check. Run exactly what your config says:

npx -y @modelcontextprotocol/server-filesystem C:\Users\you\Desktop

If it errors in your terminal, it will never work inside Claude Desktop. Fix the terminal error first.

4. The cmd /c wrapper. Because npx is really npx.cmd, Windows sometimes can't spawn it directly. The community-standard fix is to wrap it:

{
  "mcpServers": {
    "filesystem": {
      "command": "cmd",
      "args": ["/c", "npx", "-y", "@modelcontextprotocol/server-filesystem", "C:\\Users\\you\\Desktop"]
    }
  }
}

Try the plain npx form first; only add cmd /c if the logs show a spawn/ENOENT failure. Note one known edge case: playwright-mcp#1540 reports stdio pipes not connecting properly through cmd /c for some servers — if that bites you on our Playwright MCP setup, point command at the full path of npx.cmd instead.

5. The ${APPDATA} ENOENT error. If a server's log shows an error containing ${APPDATA} in a path, the official fix is to pass the expanded value yourself in the env block:

"env": {
  "APPDATA": "C:\\Users\\you\\AppData\\Roaming\\",
  "BRAVE_API_KEY": "..."
}

The docs also note npx can keep failing if npm isn't installed globally — check that %APPDATA%\npm exists, and run npm install -g npm if not.

#"Disconnected" vs "not showing up" — two different problems

These get conflated constantly, and they have different causes:

• Not showing up at all = Claude Desktop never loaded your server entry. The config failed to parse (cause #1/#2), you edited the wrong file (cause #5), or you never truly restarted (cause #4). Diagnostic signature: mcp.log has no mention of your server, or is empty.
• "Server disconnected" = the config was read and Claude tried to launch the server, but the process crashed or exited. Usual suspects: npx couldn't resolve (cause #3), a required API key or path argument is missing (cause #6), or the server printed to stdout — stdio servers must log only to stderr, because stdout is reserved for the protocol itself.

So: "not showing" → fix the config file and restart procedure. "Disconnected" → read mcp-server-<name>.log and run the command manually. Servers that need API keys — like our GitHub MCP config — disconnect far more often than keyless ones, and it's almost always the env block.

#How do you read the logs?

Claude Desktop writes MCP logs to:

• Windows: %APPDATA%\Claude\logs
• macOS: ~/Library/Logs/Claude

Two files matter:

• mcp.log — general connection lifecycle: which servers Claude tried to start, connection failures
• mcp-server-<SERVERNAME>.log — the stderr output of that specific server (its actual error messages)

Dump them on Windows (PowerShell):

type "$env:AppData\Claude\logs\mcp*.log"

On macOS, follow live:

tail -n 20 -F ~/Library/Logs/Claude/mcp*.log

How to interpret what you see:

• Empty mcp.log after a full restart → Claude is reading a different config file than the one you edited (the MSIX trap above).
• ENOENT spawning npx → Node/PATH problem; try the cmd /c wrapper or the full path to npx.cmd.
• Server log shows a stack trace → the server itself is crashing; reproduce by running its command in your terminal.
• ${APPDATA} in an error path → add the expanded APPDATA to env as shown above.

#A known-good config to start from (What we verified)

Start from a config that is known to work, confirm the connector appears, then swap in the server you actually want. The filesystem server is ideal: no API key, official package, instant visual proof.

{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-filesystem",
        "C:\\Users\\you\\Desktop"
      ]
    }
  }
}

What we verified: this is the exact shape the official MCP quickstart publishes for Windows (npx + -y + package + absolute allowed-directory args, backslashes doubled), and it matches the hand-checked entry in our registry — copy a known-good filesystem MCP config with your username pre-substituted. Replace you with your Windows username; add more directory args to grant more folders.

To confirm it's alive after a full quit-and-relaunch: click the + ("Add files, connectors, and more") button at the bottom-left of the chat box → Connectors → Manage connectors → select filesystem and you should see its tools listed.

Once filesystem works, you know your JSON, paths, Node, and restart procedure are all correct — any server that fails after that is failing on its own requirements (keys, runtimes). Browse the full MCP server directory for verified configs; note that some servers use different runtimes entirely — fetch, for example, runs via uvx (Python's uv), so "npx works" doesn't prove it will.

#When should you give up on local MCP and use a Claude Code skill instead?

Honest answer: sometimes the fight isn't worth it. Consider switching approaches when:

• You've hit the MSIX config-path bug and the cmd /c stdio edge case, and each Claude Desktop update re-breaks your setup
• You're on a locked-down or enterprise machine where installing Node or editing %APPDATA% is restricted
• The capability you want (reading files, fetching URLs, running scripts) is something Claude Code already does natively in your terminal

If you live in the terminal anyway, Claude Code skills give you reusable capabilities with zero claude_desktop_config.json involvement, and slash commands cover repeatable workflows the same way. The mental model shift: MCP servers extend the desktop app; skills and commands extend the agent in your repo. For many builder workflows the second is both more powerful and dramatically less fragile on Windows.

New to the protocol itself? Our MCP learning guide covers what servers, tools, and transports actually are — useful context for reading those log files.

#FAQ

Why is my MCP server not showing up even though the JSON is valid? Most likely you edited a config file Claude isn't reading (the Windows MSIX virtualized path issue) or you closed the window instead of fully quitting from the system tray. Check whether mcp.log mentions your server at all — if not, Claude never saw your config.

Where is claude_desktop_config.json on Windows? %APPDATA%\Claude\claude_desktop_config.json — but on MSIX installs, also check %LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\. If both exist, the LocalCache copy may be the one Claude reads.

Why does Claude Desktop say "Server disconnected"? The config loaded, but the server process crashed or exited — usually npx/Node problems, a missing API key in the env block, or the server logging to stdout instead of stderr. Read mcp-server-<name>.log and run the server's command manually in a terminal.

Do I need Node.js installed for MCP servers? For npx-based servers in claude_desktop_config.json, yes — install the LTS from nodejs.org. (Claude Desktop's one-click Desktop Extensions bundle their own Node runtime, but hand-written configs use your system Node.)

#Questions people ask

#Why is my MCP server not showing up even though the JSON is valid?

Most likely Claude Desktop is reading a different config file than the one you edited (the Windows MSIX virtualized path under %LOCALAPPDATA%\Packages), or you closed the window instead of fully quitting from the system tray. If mcp.log never mentions your server, Claude never saw your config.

#Where is claude_desktop_config.json on Windows?

%APPDATA%\Claude\claude_desktop_config.json. On MSIX-packaged installs, also check %LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\ — if that copy exists, it may be the one the app actually reads.

#What is the difference between 'server disconnected' and a server not showing up?

Not showing up means the config was never loaded (invalid JSON, wrong file, no full restart). Disconnected means Claude launched the server but the process crashed — usually npx/Node issues, missing env keys, or the server writing to stdout. The fixes are different.

#Where are Claude Desktop MCP logs on Windows?

%APPDATA%\Claude\logs. mcp.log holds general connection events; mcp-server-.log holds that server's stderr output. Dump them with: type "$env:AppData\Claude\logs\mcp*.log" in PowerShell.