Connect Claude Desktop to a Remote MCP Server: Step by Step

To connect Claude Desktop to a remote MCP server, open Settings, then Connectors, choose Add custom connector, paste the server’s HTTPS endpoint and authenticate. If your version lacks that flow, edit the config file and bridge the remote endpoint with mcp-remote. Then fully restart the app and verify with a question only live data can answer.

Before you start

Have three things ready:

• An endpoint URL. A remote server speaks MCP over HTTPS, usually using the streamable HTTP transport. The URL is specific to the server.
• Credentials. Either a Bearer key you generated, or OAuth consent if the server supports it.
• A key you can afford to lose. Use a dedicated key for this machine, scoped to the tools you need, so you can revoke it independently. See MCP API key management.

The example below uses BusinessMCP’s documented flow, because its guide is detailed and checkable. The same logic applies to any remote server; only the URL and credential differ.

Method 1: the Connectors UI

This is the simplest route, with no local process.

1. In Claude Desktop, open Settings, then Connectors.
2. Choose Add custom connector.
3. Paste the endpoint URL. For BusinessMCP the guide says it ends in /api/mcp.
4. Authenticate with your Bearer key.

BusinessMCP’s guide to connecting Claude Desktop notes one limit: the web version of claude.ai accepts only OAuth in its Connectors flow, so a Bearer key requires a client like Claude Desktop. If your server offers OAuth, web connectors become possible.

Method 2: the config file and mcp-remote

Use this if the Connectors option is unavailable or you prefer files. The configuration file lives at:

System	Path
macOS	~/Library/Application Support/Claude/claude_desktop_config.json
Windows	%APPDATA%\Claude\claude_desktop_config.json

You can also open it from Settings, then Developer, then Edit Config. For a remote endpoint, the BusinessMCP guide uses the mcp-remote bridge, which lets a client that expects a local command talk to a remote URL:

{
  "mcpServers": {
    "my-remote-server": {
      "command": "npx",
      "args": [
        "-y",
        "mcp-remote",
        "https://example.com/api/mcp",
        "--header",
        "Authorization: Bearer YOUR_KEY_HERE"
      ]
    }
  }
}

Replace the URL and key with your own. Do not commit this file to a repository, since it contains a secret.

Key takeaway: a remote server is not “installed.” You are giving the app an address and a credential, so protect that credential like a password and scope it tightly.

Restart properly

The configuration is read only at startup. Fully quit Claude Desktop, and on Windows use Exit from the system tray, then reopen it. Closing the window is not enough.

Verify the connection

Start a new chat and ask a question that only the server’s live data could answer. For a business analytics server that might be last week’s visitors and conversion rate. A specific figure with a tool-use indicator confirms the connection. A confident but vague answer with no tool indicator means the model is guessing, not calling a tool.

Then run one more check: ask for something your key should not be able to do. If the server enforces policy, the call should be refused. That test tells you the access scoping works as intended, which matters as much as the connection itself.

Troubleshooting

Symptom	Likely cause	Fix
Config seems ignored	Invalid JSON (trailing comma, curly quotes), wrong file or folder	Validate the JSON and recheck the path
spawn npx ENOENT or command not found	Desktop apps do not inherit your shell PATH	Use absolute paths from which node and which npx
Server starts but tools fail	Missing environment variables	Add an env block to the server entry
Remote calls fail	Wrong URL or an expired key	Confirm the exact URL and issue a fresh key
Tools appear but results are empty	Data sources not connected on the server side	Connect the underlying sources first
Works on one machine, not another	Different Node install or PATH	Align versions, use absolute paths

For logs, the guide lists macOS at ~/Library/Logs/Claude, with mcp.log and mcp-server-NAME.log, and the logs folder under %APPDATA%\Claude on Windows. Read them before guessing.

What a good remote server shows once connected

Once connected, look at what the server exposes. A well-run endpoint will give your key a short, sensible tool list. BusinessMCP, for instance, publishes a generated catalogue of every tool its MCP endpoint serves, with access scoped by the API key and approval required for certain actions. If you connect something with far more tools than you expected, narrow the key’s policy before using it. Our tool allowlist guide shows how.

Reading the failure modes

Most connection problems fall into three buckets, and knowing which one you are in saves an hour. The first is the app never launching your entry, which shows as no server in the list and nothing in the logs. That is almost always a config file problem: wrong path, invalid JSON or an app that was not fully restarted. The second is the entry launching and failing, which shows an error in the server log. That points to the command, the PATH or the bridge package. The third is the server connecting and answering with a refusal, which shows a connection that works but tools that fail. That is an authentication or scope problem on the server side, not a client one.

Work through them in that order. Open the log folder named earlier, find the most recent session and read the first error, not the last. Later errors are often consequences of the first. If the bridge cannot reach the URL at all, try the same URL from a terminal with your key to separate a network issue from an app issue, and take care not to paste the key into a shared terminal history.

One more habit helps: after any successful setup, write down the endpoint, the key name and the machine in your key inventory. When someone asks in six months which laptops can reach the server, you will be able to answer.

Security habits for desktop connections

• Use one key per machine, so a lost laptop means one revocation.
• Keep the config file out of backups and sync folders that others can read.
• Prefer OAuth where offered, since tokens can be scoped and expire.
• Disable auto-approval for tools that touch credentials, files or the network.
• Remove connections you no longer use.

When a local server is the better answer

Not every connection should be remote. Local stdio servers need no authentication because the operating system user boundary covers them, and they can reach local files and databases. BusinessMCP’s remote versus local MCP guide notes the two can coexist in the same client. Use remote for shared business data and cross-assistant access, and local for files on your own machine.

If you operate the remote server yourself, read self-hosted versus managed gateways before exposing it to the internet.