Connect a custom MCP connector in Claude (2026 UI, screenshots)

Most walkthroughs (ours included, until now) tell you to open Settings → Connectors in claude.ai. As of 2026 that page is a redirect stub; the real thing moved. Here’s the current flow, screenshotted from the live UI, using our own OAuth-protected demo endpoint (https://quickoauth.com/mcp-auth) as the connector.

1. Connectors moved to Customize

In Settings, the old Connectors entry now just points you elsewhere:

The live list lives under Customize → Connectors. Custom (self-hosted MCP) servers show a Custom badge; a checkmark means connected, a warning triangle means the token expired and you need to Reconnect.

2. Add → Add custom connector

The Add dropdown (top right) has two options: Browse connectors (the directory of pre-built ones) and Add custom connector (any remote MCP server by URL).

3. Fill in the URL and note the OAuth fields

You need two things: a display Name and the Remote MCP server URL (the HTTPS address where your server accepts MCP requests, e.g. https://mcp.example.com/mcp). Expand Advanced settings and you’ll see OAuth Client ID and OAuth Client Secret, both optional.

This is the important part for OAuth: leave those two fields blank. For a correctly built MCP server, Claude discovers everything itself: it fetches your /.well-known/oauth-protected-resource, follows it to your authorization server’s metadata, and dynamically registers its own client (DCR) to get a client ID. You only fill in Client ID/Secret for the rare server that requires a pre-provisioned static client and doesn’t support DCR. If you built your server from any of our provider guides, blank is correct.

4. Click Add → Claude runs the OAuth flow

On Add, Claude immediately runs the discovery + DCR sequence and then opens your authorization server’s login/consent page. Approve it, and the connector lands in the list with a checkmark and its tools available in chat. If the URL is already registered you’ll get “A connector with this URL already exists”; manage the existing one instead of adding a duplicate.

What Claude expects from your server

The connect step fails silently in the dialog if any of these are missing; this is exactly what our connector checklist verifies with four curls before you ever open this dialog:

• 401 (never 403) on an unauthenticated request, with a WWW-Authenticate: Bearer header naming your resource_metadata URL.
• A reachable /.well-known/oauth-protected-resource pointing at your authorization server.
• That server’s /.well-known/oauth-authorization-server advertising a registration_endpoint and S256.
• A working DCR endpoint that returns a client_id.

Claude posts its callback https://claude.ai/api/mcp/auth_callback (also claude.com/...) during registration, so your server must accept whatever redirect URI the client registers.

Next steps

1. Before adding a connector, run the four-curl self-test in the connector checklist: it catches every failure this dialog would only show as a silent spinner.
2. If you need the authorization server first, follow a provider guide: Auth0, Stytch, Supabase, or self-hosted Hydra.
3. For the same server in ChatGPT and Grok, see how the three clients differ and one server, three connectors.

If the flow errors out, debugging connector failures walks the probes in order.

My remote MCP server at https://MY_DOMAIN/mcp shows "unable to connect" when I add it as a claude.ai custom connector. Run these checks in order, report the result of each, and stop at the first failure with a diagnosis and fix:

1. DNS: dig +short MY_DOMAIN @1.1.1.1, which must return a public A/AAAA/CNAME answer. (Tailscale *.ts.net names and LAN-only DNS fail claude.ai's pre-flight even if the URL works in my browser.)
2. TLS: curl -sI https://MY_DOMAIN/mcp without -k; the certificate must chain to a public CA.
3. Unauthenticated probe: curl -si -X POST https://MY_DOMAIN/mcp | head -5; expect 401 with a WWW-Authenticate header naming the resource metadata URL (or a valid MCP response if the server is intentionally no-auth). 403, 404, redirects, or HTML mean discovery dies here.
4. Protected resource metadata: curl https://MY_DOMAIN/.well-known/oauth-protected-resource; the "resource" field must exactly equal https://MY_DOMAIN/mcp or its origin https://MY_DOMAIN (a prefix of the MCP URL); anything else fails.
5. Authorization server metadata: curl https://MY_DOMAIN/.well-known/oauth-authorization-server; must include authorization_endpoint, token_endpoint, registration_endpoint, and "S256" in code_challenge_methods_supported.
6. DCR: POST to the registration_endpoint with {"redirect_uris":["https://claude.ai/api/mcp/auth_callback"],"client_name":"probe"}; expect a JSON body containing client_id.
7. Handshake: POST an MCP initialize request to /mcp with accept: application/json, text/event-stream (use a token from the flow if auth is on); expect an initialize result, JSON or SSE-framed.

For whichever step fails, explain what claude.ai's discovery expected at that step, what my server returned instead, and the minimal change to fix it. If all seven pass, run npx @modelcontextprotocol/inspector against the endpoint and compare its handshake log with the checks above.