Claude Desktop MCP Server Not Showing Up: A Fix List

When a local MCP server does not work in Claude Desktop, the cause is nearly always one of five things: the app was not fully restarted, the JSON does not parse, the command is not found because the app cannot see your terminal’s PATH, a path or setting the server needs is missing, or the server starts and then crashes. Work in that order. Quit the app completely and reopen it; check the file parses; read mcp.log and the server’s own mcp-server-NAME.log; then run the exact command from the config in a terminal, and in the MCP Inspector, to see whether the server works without Claude at all.

This list is for getting a server to appear and connect. What goes in the file is covered in the Claude Desktop MCP config; once a server is connected and its tools misbehave, see how to debug MCP tools.

Two checks that fix most cases

1. Restart properly. Claude Desktop reads the config only when it starts. The protocol’s debugging guide↗ (opens in a new tab) is explicit: fully quit and reopen, because closing the window is not enough. On Windows, check Task Manager for a leftover Claude process before you reopen it.
2. Edit the file the app reads. Open it from the app, through the Claude menu in the system menu bar, then Settings…, Developer and Edit Config, rather than a copy you found on disk. On macOS it is ~/Library/Application Support/Claude/claude_desktop_config.json; on Windows, %APPDATA%\Claude\claude_desktop_config.json.

Where the logs are

• macOS: ~/Library/Logs/Claude
• Windows: %APPDATA%\Claude\logs
• mcp.log records MCP connections and connection failures in general.
• mcp-server-NAME.log, one per server, holds that server’s standard error. The MCP guide to connecting local servers↗ (opens in a new tab) notes that stdio servers may log everything there, so the file is not only errors.

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

# Windows PowerShell
Get-Content "$env:APPDATA\Claude\logs\mcp*.log" -Tail 20

Anthropic’s help page on local MCP servers in Claude Desktop↗ (opens in a new tab) also points to the Developer settings for each server’s connection status and its logs, which is the quickest way to see which server failed before you open any file.

Fix list by symptom

The server is not listed at all

If no server from the file appears, the app most likely could not read the file. Check it parses before anything else:

# macOS
python3 -m json.tool ~/Library/Application\ Support/Claude/claude_desktop_config.json

# Windows PowerShell
python -m json.tool "$env:APPDATA\Claude\claude_desktop_config.json"

• A trailing comma after the last server, or a comment. JSON allows neither.
• Curly quotes pasted from a web page or a word processor instead of straight " quotes.
• A single backslash in a Windows path. Write C:\\Users\\you or C:/Users/you.
• Two mcpServers blocks, or a server object placed outside mcpServers. There is one object, and every server is a key inside it.
• A file saved as claude_desktop_config.json.txt because Windows hides known extensions. Turn on file name extensions in File Explorer and look again.
• Windows installs packaged as MSIX: people have reported the app reading its configuration and logs from %LOCALAPPDATA%\Packages\Claude_…\LocalCache\Roaming\Claude instead. If edits never take effect and the logs folder stays empty, look there too.

It is listed but failed to connect, or disconnected

The app found the entry, started the command, and the process either exited or never answered. Open that server’s mcp-server-NAME.log; the last lines usually name the cause.

• ENOENT, command not found or spawn npx errors: the app cannot find the program. See the PATH section below.
• Cannot find module or a missing file: a relative path. Servers are not started from your project folder, and on macOS the working directory may be /. Use absolute paths everywhere in command and args.
• An authentication or “missing key” message: the server did not get its environment. Stdio servers inherit only a limited set of environment variables, so put keys and settings in the server’s env block.
• Parse errors or garbage in mcp.log: the server is printing to standard output, which is the protocol channel. Its own logging belongs on standard error. That is a server bug; report it to its author.
• On Windows, an ENOENT mentioning ${APPDATA} in a path: add the expanded APPDATA value to the server’s env, as the MCP troubleshooting guidance describes.

It says it could not attach, or drops straight after starting

The process starts and dies before the app can talk to it. The usual culprit with npx is a missing -y. The npx documentation↗ (opens in a new tab) says it prompts before installing a package that is not already present, and inside Claude Desktop nobody can answer, so the server never starts. Add -y as the first argument. A first run that downloads a large package can also be slow; run the command once in a terminal so the package is cached, then restart the app.

Connected, but no tools, or some tools missing

Open the “+” menu in the message box, then Connectors, then Manage connectors, and select the server. If it is switched off for this conversation, switch it on. If it lists no tools at all, the server started without returning a tool list; list its tools in the Inspector, as below, to see whether that is the server or the app. A single missing tool, a wrong tool, or tools that fail when called is no longer a connection problem, and belongs to how to debug MCP tools.

A remote server in the config file does nothing

The config file is for programs the app starts on your machine. A server with a URL is added as a custom connector in Claude instead, and the help page on custom connectors using remote MCP↗ (opens in a new tab) adds the condition that trips people up: Claude connects from Anthropic’s cloud, so a server behind a VPN or firewall will not connect even when your own browser can reach it.

node, npx or uv “not found”

Claude Desktop is started by the operating system, not from your terminal, so it may not see PATH changes made in your shell profile. Version managers such as nvm put node somewhere only your terminal knows about. The fix is to give the full path to the program in command: which npx on macOS or where npx on Windows prints it. npx itself runs on node, so if the full path still fails, set PATH in the server’s env to include the folder that holds node.

{
  "mcpServers": {
    "filesystem": {
      "command": "/Users/you/.nvm/versions/node/v22.19.0/bin/npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem", "/Users/you/Desktop"],
      "env": {
        "PATH": "/Users/you/.nvm/versions/node/v22.19.0/bin:/usr/bin:/bin"
      }
    }
  }
}

The same applies to uv and uvx for Python servers; the MCP server-building guide suggests the full path from which uv or where uv. On Windows, the MCP guidance adds that npx may keep failing unless npm is installed globally: if %APPDATA%\npm does not exist, run npm install -g npm.

Test the server without Claude

Copy command and args from the config and run them in a terminal. A healthy stdio server prints nothing and waits for input; press Ctrl+C to stop it. An error that appears straight away is the same error Claude Desktop hit.

Then connect to it the way a client does, with the MCP Inspector↗ (opens in a new tab). It needs Node 22.19.0 or newer and runs through npx. It can also read your Claude Desktop config directly with --config and --server, so you test the entry exactly as written. The full walkthrough is in the MCP Inspector guide.

# Start the server and open the Inspector in a browser
npx @modelcontextprotocol/inspector npx -y @modelcontextprotocol/server-filesystem /Users/you/Desktop

# Or list its tools from the command line, using the entry in your config
npx @modelcontextprotocol/inspector --cli \
  --config ~/Library/Application\ Support/Claude/claude_desktop_config.json \
  --server filesystem --method tools/list

If the server works in the Inspector and not in Claude Desktop, the difference is the environment: a PATH the app cannot see, a variable only your terminal sets, or a relative path. If it fails in the Inspector too, the fault is in the server, and the log will now show it in your own terminal.

For errors in the app itself rather than the server, the debugging guide describes turning on Chrome DevTools inside Claude Desktop with a developer_settings.json file containing {"allowDevTools": true} next to the config file, then opening them with Command-Option-I on macOS or Ctrl+Alt+I on Windows.

When nothing else works

1. Make a copy of your config file.
2. Replace it with a single known-good server, such as the Filesystem example with one absolute folder path.
3. Quit fully, reopen, and confirm that one server appears with its tools.
4. Add your other servers back one at a time, restarting after each, until one breaks it.
5. Check you are on the latest version from the Claude menu’s Check for Updates.

Remote servers skip most of this list

Nearly every fix above exists because a local server is a program on your machine: PATH, runtimes, file paths, environment. A remote server has none of those. fenbs, a task board where AI assistants are members with roles, is one: you add https://fenbs.ai/api/mcp as a custom connector, sign in in the browser, tick read, write or comment, and there is no JSON to break and no process to start. If a connector will not connect, the checks are shorter: is the URL exact, did the sign-in finish, and does your plan or organisation allow custom connectors. The steps are on the Claude integration page.