How to Connect Claude Desktop to a Remote MCP Server (Not OAuth)

If you've got a remote MCP server that authenticates with a plain API key header — not OAuth — Claude Desktop's UI will actively steer you toward a dead end. This is the walkthrough that actually works, using ThreadSnoop's own MCP server as the worked example, plus the exact errors you'll hit if you try the obvious path first (so this page finds you if you're already stuck on one of them).

Why “Settings → Connectors → Add custom connector” won't work

This is the first place anyone looks, and for a header-authenticated server it's a dead end either way you fill it in. The dialog only has three fields: Name, URL, and an “Advanced settings” section with OAuth Client ID and OAuth Client Secret. There is no field for a custom request header.

If you leave OAuth Client ID/Secret blank, Claude attempts OAuth Dynamic Client Registration — auto-discovering and registering an OAuth client with your server. A server that only does header auth has no OAuth endpoints to discover, so this fails with:

If you put your header name or key into “OAuth Client ID” — a reasonable guess, since it's the only field that looks like it takes a credential — Claude treats it literally as an OAuth client ID and starts a real authorization-code flow, redirecting to a URL shaped like:

https://your-server.com/authorize?response_type=code&client_id=YOUR_HEADER_NAME&redirect_uri=https%3A%2F%2Fclaude.ai%2Fapi%2Fmcp%2Fauth_callback&code_challenge=...

Your server almost certainly doesn't have an /authorize endpoint (ThreadSnoop's doesn't — there's no OAuth flow to speak of), so this 404s. Neither path through this dialog reaches a working connection. This isn't a misconfiguration on your end; the dialog simply has no mode for static header auth.

The fix: mcp-remote as a stdio bridge

Claude Desktop's config file has the same limitation from a different angle: it only validates local (stdio) server entries. Drop a plain url/headers block in — the shape that works fine for Claude Code and Cursor — and Desktop rejects it as invalid, or silently drops the entry. Desktop only launches local commands, so reaching a hosted server needs a bridge that speaks stdio on one side and HTTP on the other. That's what mcp-remote is.

Get a free ThreadSnoop key at /signup (1,000 free Reddit searches, no card), then quit Claude Desktop and edit its config file:

• Mac: ~/Library/Application Support/Claude/claude_desktop_config.json
• Windows: %APPDATA%\Claude\claude_desktop_config.json

{
  "mcpServers": {
    "threadsnoop": {
      "command": "npx",
      "args": [
        "-y",
        "mcp-remote",
        "https://api.threadsnoop.com/mcp",
        "--header",
        "x-api-key:YOUR_KEY"
      ]
    }
  }
}

Save, reopen Claude Desktop, and open Settings → Connectors → Local MCP servers (or the equivalent panel in your Desktop version) — threadsnoop should show a running status. This requires npx/Node.js on your machine; if you're doing any kind of development work you almost certainly already have it.

Any other MCP client that only launches local processes hits the same wall and fixes it the same way — nothing here is ThreadSnoop-specific except the URL and header name. Claude Code and Cursor, by contrast, both support a remote server config directly with no bridge needed — see giving Claude Code access to Reddit for that simpler one-line setup.

Verify it's actually working

A “running” status confirms the process started, not that auth is correct end to end. Ask Claude:

Check my ThreadSnoop credits

That calls the check_credits tool, which is free — it costs nothing even if you run it a dozen times debugging. A real balance and rate limit coming back means the header, the key, and the bridge are all correct. If you get an auth error instead, the key itself is the next thing to check, not the connection.

Does any of this affect claude.ai on the web?

Yes, and there's currently no equivalent fix. mcp-remote is a local process — a browser can't launch one, so the bridge that fixes Desktop doesn't exist as an option on claude.ai web. Web's only MCP connection path is the same Connectors dialog described above, which is OAuth-only. For a header-authenticated server, that means web currently has no working path at all — this is Desktop-only until Anthropic adds custom-header support to the web Connectors flow. The one exception: Team/Enterprise workspace admins can allowlist a specific domain for network access under Organization settings → Capabilities, which sidesteps the whole MCP question — but that's an admin-only, workspace-tier setting, not something available on Free/Pro/Max accounts.

Frequently asked questions