MCP Server Works in Inspector but Not in Claude: How to Fix It (Claude Desktop, claude.ai, Claude Code)

If your MCP server works in the MCP Inspector but fails in Claude, the server code is probably fine and the difference is in how it is launched or reached. Locally, the Inspector inherits your terminal's environment, while Claude Desktop starts the server with a smaller environment and possibly a different working directory or Node runtime. Remotely, claude.ai connects from Anthropic's servers, not your machine. The fastest fix is to make the Claude config use absolute paths and explicit env values, or, for remote servers, to check DNS, redirects and discovery from a public network.

Checked against: the MCP debugging guide, the MCP Inspector docs, Claude's connector troubleshooting page and the source of the @modelcontextprotocol/sdk 1.32.2 npm package on 2 November 2026. eSEOspace did not reproduce these cases.

What this error means

The Inspector is the reference testing tool. When you run npx @modelcontextprotocol/inspector node path/to/server/index.js, the Inspector starts your server from your current terminal session.

Claude starts it differently. For local servers, Claude Desktop is a GUI app. An MCP maintainer put it plainly in a GitHub thread: "the environment for GUI apps is completely different from what you see on the command line." For remote servers, claude.ai does not connect from your laptop at all.

So "works in the Inspector" proves the protocol logic. It does not prove the launch settings or the network path Claude uses.

Quick fix

Local server (Claude Desktop):

1. Use absolute paths for command and every file argument. Get them with which or where.
2. Set every needed variable in env. The TypeScript SDK 1.32.2 passes only HOME, LOGNAME, PATH, SHELL, TERM and USER by default on macOS and Linux. API keys from your shell profile do not come along.
3. Do not rely on the current folder. Load .env files and data by absolute path.
4. Check the runtime. If it is a desktop extension, test with a JSON config that points at your own Node.
5. Quit and reopen Claude Desktop, then read mcp-server-SERVERNAME.log.

Remote server (claude.ai):

1. Check public DNS. Run dig +short your-server.example.com from outside your network.
2. Check redirects. Run curl -sI https://your-server.example.com/mcp. A 3xx to another host is the problem.
3. Check discovery. Fetch /.well-known/oauth-protected-resource from a public network.
4. Check your firewall for blocked requests from Anthropic's range.

Fix by client / OS

Claude Desktop

Mirror the Inspector's launch. If this works:

npx @modelcontextprotocol/inspector node /Users/you/server/dist/index.js

then build the config from the same pieces, with full paths and explicit variables:

{
  "mcpServers": {
    "my-server": {
      "command": "/opt/homebrew/bin/node",
      "args": ["/Users/you/server/dist/index.js"],
      "env": {
        "MY_API_KEY": "your-key",
        "DATA_DIR": "/Users/you/server/data"
      }
    }
  }
}

Use your own which node output. On Windows, users report that MSIX installs may read a different copy of the config; see config JSON not loading.

claude.ai and remote connectors

Claude's troubleshooting page lists these causes for "Couldn't reach the MCP server" when other tools work:

• Split-horizon DNS: "the CLI and curl connect from your machine, while claude.ai connects from Anthropic's servers."
• Private addresses: Claude rejects hostnames that resolve to 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 100.64.0.0/10, loopback or link-local, or to a mix of public and private. It also needs an A record, because connectors are IPv4-only.
• Redirects: "Local clients fail fast on a redirect," while claude.ai follows it, drops the credential, and fails later with "Authorization with the MCP server failed."
• WAF blocks: look for 403 or 429 your app did not generate. Anthropic's outbound range is 160.79.104.0/21, per Claude's authentication docs.

To test a local server with claude.ai, the troubleshooting page points to a public tunnel setup.

Claude Code

Claude Code also runs from your terminal, so it often behaves like the Inspector. If it fails where the Inspector works, compare transports and headers. The Claude Code MCP docs say a rejected headers.Authorization is reported as a failure without falling back to OAuth.

Where to find the logs

If your server's access logs show nothing during a claude.ai connect attempt, the request never left Anthropic or was blocked at your edge. That points to DNS or a WAF, not your code.

If it still fails

• Protocol era differences. The Inspector docs say it negotiates both legacy and modern 2026-07-28 protocol eras. If your server supports only one, see protocol version mismatch.
• Environment variables. See env variables not passed.
• Stray stdout output can pass in one client and fail in another. See stdout logging.
• Auth failures. See MCP 401 Unauthorized.

Look up any code with the MCP error code lookup. The course lesson on testing with the MCP Inspector covers good test habits, and our MCP development team can review a server before launch.

Frequently asked questions