How Do You Add a Custom Connector in Claude?

Three steps, one URL, no API key. Plus the one thing that makes the dialog fail with no error message.

Sep 15, 2026

In Claude, go to Customize, then Connectors, then the plus button, then Add custom connector. Paste the server's HTTPS URL and click Add. If the server uses OAuth, you then click Connect and sign in through that application's own login. There is no API key to paste and no configuration file to edit.

The three steps, as an end user sees them

This is the connection section of a guide we shipped with a platform we run for an accounting firm. It is the whole setup:

Connecting, start to finish

  1. 1

    Step 1 In Claude, open Connectors and choose Add custom connector. Paste the URL, which is usually the application's own address with /mcp on the end.

  2. 2

    Step 2 Click Connect. A window from that application opens and asks you to sign in the way you normally do, often with the Google or Microsoft account you already use.

  3. 3

    Step 3 Check the scope shown on the consent screen, then Authorize. Claude keeps the connection and renews it by itself.

The prerequisite line in that guide is the useful one: if the application will not let you in, neither will the connector. Your access through Claude is your normal access, and it ends when your account does.

Team and Enterprise work differently

On Pro and Max, you add connectors yourself under Customize, then Connectors.

On Team and Enterprise, only an Owner can add a custom connector to the organisation, from Organization settings, then Connectors. After that, each member connects individually from their own Customize, then Connectors, signing in with their own account.

That split is the right shape for a business system: one administrative decision about whether the connector is allowed at all, then per-person identity for everyone who uses it.

What the server has to be

Two constraints catch people out.

It has to be reachable from the internet. A remote MCP server is a public HTTPS endpoint. Claude cannot reach a server running on your laptop or inside a private network, no matter what the URL is.

It has to speak the remote transport. A local stdio server, the kind configured in a JSON file for Claude Desktop, is a different thing and does not appear in this dialog.

When the dialog fails and says nothing

Almost always the server, not the client. In order of how often we have hit it:

  • The issuer in the server's metadata does not match the iss in its tokens. This is the single most common cause, and it fails silently.
  • Only one spelling of the authorization-server metadata is served. Clients differ on whether they probe /.well-known/oauth-authorization-server or /.well-known/openid-configuration, and some try only one.
  • The protected-resource document is served only at the bare path. A client may legitimately probe /.well-known/oauth-protected-resource/mcp instead.
  • The discovery documents are not CORS-open, so a browser-based client cannot read them.

If you are the user rather than the person who built the server, those are the four things to send to whoever did.


The full version of that list, with why each one breaks and what to serve instead, is in the auth change that moved MCP setup off the user.

If you want your own customers connecting to your product this way, that is what we build, including on top of an existing system like Salesforce.