Add a Remote MCP Server to Claude Desktop: Connectors and Fixes

How to add a remote MCP server to Claude Desktop as a custom connector, when to use mcp-remote instead, and why a server that works on your machine fails in Claude.

MCP Hunter team 3 October 2026 8 min read

A remote MCP server goes into Claude Desktop as a custom connector: you paste its URL under Customize > Connectors and Claude signs in to it if it needs to. claude_desktop_config.json is for local servers, and it has no field for a URL.

Everything below is checked against Anthropic's connector documentation on 3 October 2026 [1][2][3][4]. The step that catches most people is not in the dialog at all. Claude does not connect from your computer. It connects from Anthropic's servers, so the question is never "does my server work" but "does my server answer a stranger on the internet".

TL;DR:

Paste the URL under Customize > Connectors > Add custom connector. Any plan can do it; the Free plan gets one custom connector [2].
Do not put a url in claude_desktop_config.json. That file only understands local servers. One reported bug has Desktop silently deleting the whole mcpServers block when it finds one [5].
Claude calls your server from Anthropic's network, not yours [1]. A server that passes in the MCP Inspector or curl on your laptop can still fail in Claude.
A guarded server needs a 401 that says where to sign in. Without a resource_metadata pointer or working /.well-known/ paths, Claude cannot find your authorization server [3].

Add it as a custom connector

On a Free, Pro or Max plan you add it to your own account [2]:

Open Customize > Connectors, on the web at claude.ai/customize/connectors. Claude Desktop uses the same connectors as claude.ai, because one connector system backs every Claude app [7].
Click Add custom connector.
Enter the server's URL, for example https://mcp.example.com/mcp.
Leave the OAuth fields empty unless the server's own docs give you a client ID.
Click Add, then Connect if the server asks you to sign in.

To use it in a chat, open + > Connectors and switch it on for that conversation [2].

On a Team or Enterprise plan a member cannot add a custom connector. An Owner adds it under Organization settings > Connectors > Add > Custom, and each member then connects with their own account [2].

The three authentication choices

Depending on your organization, the dialog either shows Advanced settings on one screen or walks you through these as a second step [2]:

Choice	Pick it when
Sign in now	The server uses OAuth and every tool needs your account
Sign in when needed	Some tools work anonymously and Claude should ask only when the server does
No sign-in	The server is open, or it takes a fixed API key you add under Request headers

Request headers is in beta for a limited set of organizations, so you may not see it [3]. Where it exists, Claude sends the value exactly as you type it, so a bearer token needs the scheme: enter Bearer your-token, with the space, not just the token [2].

You cannot change authentication settings after adding a connector. Remove it and add it again [2].

When to use mcp-remote instead

mcp-remote is a small bridge that Claude Desktop launches as a local stdio server, and which forwards everything to a remote URL [6]. It goes in claude_desktop_config.json like any local server:

{
  "mcpServers": {
    "example": {
      "command": "npx",
      "args": ["-y", "mcp-remote", "https://mcp.example.com/mcp"]
    }
  }
}

It is the right tool in exactly the cases a custom connector cannot reach, because the bridge runs on your machine and connects from it:

The server is only reachable from your network: localhost, a VPN, a staging host behind your firewall.
You need a header and do not have Request headers: "--header", "Authorization:${AUTH_HEADER}" with the value in env [6].

For anything on the public internet, the custom connector is the supported route and needs no Node install. Its maintainers describe the bridge as something to remove "as soon as your chosen MCP client supports remote, authorized servers" [6]. Claude Desktop does.

Why it works on your machine and fails in Claude

Every custom connector call starts at Anthropic: "Claude connects to your remote MCP server from Anthropic's cloud infrastructure, rather than from your local device" [1]. The MCP Inspector, curl and Claude Code all connect from your machine, so they test a different path. Anthropic's troubleshooting page lists what goes wrong on that path, and two errors cover almost all of it [4].

"Couldn't reach the MCP server"

Claude never finished the handshake. In the order Anthropic suggests checking [4]:

Cause	How it looks	Fix
The hostname resolves to a private address	Nothing in your access logs at all	Serve it from a public host or a tunnel
The hostname has only an IPv6 (`AAAA`) record	Same: no request ever arrives	Add an `A` record. Connectors are IPv4-only
A WAF, CDN or bot rule blocks Anthropic	`403` or `429` in edge logs your app did not write	Allowlist Anthropic's egress range, `160.79.104.0/21` at the time of writing [3]
OAuth discovery fails	Your MCP server sees a request, your auth server sees nothing	See the next section

Split-horizon DNS is the classic version of the first row: the hostname resolves on your network and to nothing routable outside it.

"Authorization with the MCP server failed"

Sign-in started and did not finish [4]. The causes Anthropic lists:

The URL redirects to another host, such as apex to www.. Claude follows the redirect, drops the Authorization header on the way, and the target answers 401. Register the URL your server actually listens on.
Issuer or audience mismatch. Claude sends your MCP server URL as the resource parameter, and your tokens have to be minted for it.
No S256 PKCE. Claude sends a code_challenge on every request [3].
A slow token endpoint. Claude waits 10 seconds for discovery, registration and token responses [3].

What a guarded server has to answer

About a quarter of MCP servers ask for credentials: across 1,039 addresses drawn at random from the official registry, 24% did (the registry census). For those, the handshake with Claude starts with one response [3]:

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer resource_metadata="https://mcp.example.com/.well-known/oauth-protected-resource"

That header is how Claude finds your authorization server. Without it, Claude falls back to probing /.well-known/oauth-protected-resource on your server's own origin, and if that returns 404 too, it has nowhere to go [3]. Check it from outside your network:

curl -i https://mcp.example.com/mcp
curl -i https://mcp.example.com/.well-known/oauth-protected-resource

Then the authorization server needs a way to register Claude as a client: a registration_endpoint for Dynamic Client Registration, or "client_id_metadata_document_supported": true for Claude's published identity [3]. Register https://claude.ai/api/mcp/auth_callback as a redirect URI if your server wants them listed in advance [3]. The spec side of all this is in our post on MCP OAuth.

Check it from outside before you paste it

The failures above share one shape: the server is fine, and nobody outside your network can reach it the way you can. Our MCP connection test makes the call from our server rather than yours, so it answers the part your laptop cannot. It reports a private address, a hostname that does not resolve, a URL that serves a web page instead of an endpoint, a server still on the old SSE transport, a 401, or a full handshake with its tool list, and it writes the result to its own dated URL.

It is not Anthropic's network, so it cannot see a WAF rule aimed at Anthropic's range in particular. What it does settle is whether a stranger on the internet gets an MCP answer at all, which rules the private-address, DNS and discovery rows in or out before you open the dialog. If you are still deciding whether your server should have a public address in the first place, remote MCP server vs stdio covers what that address costs and what it buys.