Couldn't reach the MCP server

If your server's access log shows nothing at all during the Connect attempt

1. 1 Claude resolves the hostname and validates the result before it makes any request, so a rejected name produces no traffic anywhere you can see. It rejects private, carrier-grade NAT, loopback and link-local addresses, any mix of public and non-public answers, and a hostname with no A record from public DNS — connectors are IPv4-only, so an AAAA-only host has nothing to dial.
2. 2 Publish the server on a globally routable IPv4 endpoint: a host with a public IP, a public reverse proxy, or a tunnel. An Anthropic MCP tunnel does not close this gap for claude.ai — the docs state that tunnels created through the Console are not available as connectors in claude.ai, and reach Claude Managed Agents and the Messages API only.
3. 3 Then collect the reference id. It starts ofid_ and appears in the error toast and in the page URL; file it with your server URL and your server-side access logs on the anthropics/claude-ai-mcp tracker. It is what lets Anthropic trace the exact failure server-side, and reference ids are time-limited, so report soon after the failure.

.../settings/connectors?step=start_error&flow_id=ofid_d32594c73257a651

If the public record points into your cluster's network, or your ingress has a source-IP allowlist

1. 1 An internal load balancer gets an internal address: networking.gke.io/load-balancer-type: "Internal" on a GKE Service creates a load balancer that, per Google's docs, only clients in the same VPC network or a network connected to it can reach. If that address is what your public zone publishes, claude.ai resolves it, sees a non-routable answer, and stops before sending anything.
2. 2 Point the public record at an internet-facing ingress and keep the internal name for in-cluster callers. Verify with dig +short A from outside your network, not from a pod and not from a laptop on the VPN.
3. 3 nginx.ingress.kubernetes.io/whitelist-source-range sets the allowed client IP source ranges as a comma-separated CIDR list, and ingress-nginx documents that an annotation on an Ingress rule overrides any global restriction — so 160.79.104.0/21 has to be in whichever one applies, or the MCP and OAuth paths never reach your pod. Do not treat that allowlist as authentication: the range is shared by every Anthropic customer.

If Cloudflare Access or a WAF rule sits in front of the hostname

1. 1 A WAF rule, a bot-management rule and a rate limiter all answer before your application does, and all three look identical from claude.ai. Anthropic's guidance is the only reliable tell: look for 403 or 429 responses in your edge or CDN logs that your application did not generate, especially during a Connect attempt. Cloudflare Access in front of the hostname is a different failure with the same toast — it authenticates browser sessions, and that shape has its own page in the related errors below.
2. 2 Add a Bypass policy for Anthropic's outbound range using an IP-range selector, which takes CIDR notation: 160.79.104.0/21. Cloudflare documents Bypass as disabling Access enforcement for traffic matching the rule, and that bypassed requests are not logged — so it removes your only gate on that path, and the MCP route needs its own authentication afterwards.
3. 3 Do not plan on a service token instead. That needs Claude to send CF-Access-Client-Id and CF-Access-Client-Secret, and claude.ai's request-header authentication is in beta and gated on contacting Anthropic, accepts at most four headers, and restricts names to a reviewed allowlist of standard authentication and routing headers such as authorization, x-api-key and x-auth-token.

If a WAF web ACL, security group or network ACL sits in front of your load balancer

1. 1 A web ACL whose default action is Block, or a managed rule group that reads an unattended client as a bot, answers before your target group does. The allow path is an IP set match rule: create an IP set holding 160.79.104.0/21 and reference it from a rule with an Allow action, ordered ahead of the blocking rules. In the console rule builder the Request option to choose is Originates from an IP address in; in the API the statement is IPSetReferenceStatement. AWS WAF supports every IPv4 and IPv6 CIDR range except /0, and one IP set holds up to 10,000 addresses or ranges.
2. 2 Check the security group and any network ACL as well. A group scoped to your corporate ranges drops the connection with no HTTP response at all, which claude.ai reports with the same string and which leaves nothing in your WAF logs to find.
3. 3 If the listener also carries an authenticate-oidc action, that is a separate failure that produces the same toast — a browser redirect an MCP client cannot follow. It has its own page in the related errors below.

If the URL you registered redirects — apex to www, region routing, or a vanity domain to a CDN

1. 1 Vercel recommends the www subdomain as the primary domain with a redirect from the non-www domain to it, and its docs say that if someone visits your domain with or without the www prefix, Vercel will attempt to redirect automatically. So the apex URL a developer naturally pastes into the connector dialog is a redirect, not an endpoint.
2. 2 The Authorization header is dropped on a cross-host redirect per standard HTTP client security behaviour. The redirect target receives an unauthenticated request, returns 401, and the connection fails with "Authorization with the MCP server failed" — which is why this cause hides behind the other error string.
3. 3 Register the URL the server actually listens on, not one that redirects to it. curl -sI the registered URL: if the status is a 3xx and the Location names another host, that target is the URL to register. Region routing and vanity-domain-to-CDN redirects behave the same way.

If your authorization server is Microsoft Entra ID and the token request fails with AADSTS9010010

1. 1 This one lands on the other toast — Anthropic documents it under "Authorization with the MCP server failed", because the MCP endpoint was reachable and the token request is what failed. Entra is rejecting the resource value Claude sends, sometimes surfaced as invalid_target: Claude sets resource to your MCP server URL including the path, and Entra issues a token only when that value is listed as an Application ID URI on the app registration representing your protected API. The default api://{client-id} URI alone is not sufficient.
2. 2 In the Entra admin center open the API's app registration — not the client's, if they are separate — and under Expose an API add your MCP server URL as an additional Application ID URI (identifierUris in the manifest). The value must match exactly, including the path, without a trailing slash.
3. 3 If your server validates the audience through Azure App Service Authentication, add the API app's Application (client) ID and its api:// URI to the allowed token audiences — the Allowed token audiences setting, not Allowed client applications, which is a different list. And where the client and the API are separate registrations, confirm the client has an admin-consented API permission for the scope your API exposes.

If the MCP server genuinely cannot be published to the public internet

1. 1 claude.ai has no private path into your network, and Anthropic's own MCP tunnels do not provide one: they are a research preview, and the docs state that tunnels created through the Console are not available as connectors in claude.ai. For a claude.ai connector the fix has exactly one shape — a public origin in front of the private server.
2. 2 The gateway is that origin: one public HTTPS route per upstream MCP server, with a server that only exists inside your VPC or on bare metal reached over the Zuplo secure tunnel. The tunnel service dials out from inside your network, so nothing is exposed to the internet and no inbound firewall rule is opened.
3. 3 It also answers the discovery half of this error. For its MCP routes the gateway is both the OAuth 2.1 resource server and the authorization server, publishing an RFC 9728 protected resource metadata document per route and RFC 8414 authorization-server metadata both gateway-wide and per route — so there is no cross-host authorization server for a WAF to block.

Something else

Whatever sits in front of your server, the branch is the hop, and there are only four. Nothing on your network saw the request: the name you registered resolves to something Anthropic will not dial, so fix the public record or publish a routable IPv4 endpoint. Something answered before your application did: find the 403 or 429 in the edge logs and allowlist 160.79.104.0/21 on that component, or exempt the MCP and OAuth paths from the rule. The request arrived without its credential: your URL redirects to another host, so register the target instead. The MCP endpoint answered but discovery did not: return a 401 carrying WWW-Authenticate: Bearer resource_metadata="…", or serve /.well-known/oauth-protected-resource/<your-mcp-path> on the origin, and remember that discovery requests to a cross-host authorization server arrive from the same egress range — so a WAF in front of your identity provider breaks the connection even when your MCP server is perfectly reachable.