Skip to content

Claude custom connectorAuthorization with the MCP server failed

You added your MCP server to Claude as a custom connector and got one of two messages: Authorization with the MCP server failed, or Couldn’t reach the MCP server. Claude runs connectors from Anthropic’s cloud, so the problem is usually in how your server looks from the public internet, or in one step of the sign-in flow. Here’s how to find which, or hand it over at a fixed price.

Short answer

Work from the outside in. First make sure Claude can reach the URL at all: a public address, no firewall or bot rule blocking Anthropic, and no redirect to another host. Then check the sign-in flow: an unauthenticated request must get a 401 that points to your OAuth metadata, your authorization server must support S256 PKCE and a way for Claude to register, and discovery, registration and token responses must each arrive within 10 seconds.

The usual causes, and the fix

  1. 01

    The address isn’t reachable from the public internet

    “If any resolved address isn't globally routable, Claude rejects the connection before any HTTP request leaves Anthropic's network.” Anthropic, Troubleshoot connectors

    A hostname that resolves to a private or local address works on your machine and in some local tools, but not in Claude. Run dig +short on your hostname from a network outside your own: every address it returns must be public. Claude connectors are also IPv4-only, so a hostname with only an IPv6 address fails too.

  2. 02

    A firewall, CDN or bot rule blocks Anthropic

    “If your hostname resolves correctly but a CDN, WAF, bot-management rule, or rate limiter in front of your server blocks the request, the connection fails before your application sees it.” Anthropic, Troubleshoot connectors

    If your edge logs show 403 or 429 responses your app didn’t send, a WAF, bot-management rule or rate limiter is turning Claude away. Allowlist Anthropic’s published outbound range (Claude’s docs list 160.79.104.0/21), or exempt your MCP and OAuth paths from the rule.

  3. 03

    The URL redirects to another host

    A redirect from the apex domain to www, or from a vanity domain to a CDN, loses the Authorization header on the way, so the target answers 401 and the connection fails. Run curl -sI on the exact URL you entered. If it returns a 301, 302, 307 or 308 to a different host, enter the final URL in Claude instead.

  4. 04

    Claude can’t find or use your OAuth setup

    “The 401 status is required, because Claude doesn't honor a WWW-Authenticate header on a 200 response.” Anthropic, Authentication for connectors

    An unauthenticated request to your MCP URL must return 401 with a WWW-Authenticate header whose resource_metadata points to your protected resource metadata document. Any HTTPS address works, and if the pointer is missing Claude tries /.well-known/oauth-protected-resource. That document’s resource must equal the URL as entered in Claude, including the path, and Claude only uses the first authorization server it lists. The authorization server then needs a way for Claude to register: dynamic client registration, a Client ID Metadata Document, or a client you create in advance with the redirect URI https://claude.ai/api/mcp/auth_callback.

  5. 05

    The token step fails or is too slow

    “If your authorization server doesn't implement S256 PKCE, the flow fails at the token endpoint.” Anthropic, Troubleshoot connectors

    Claude sends a PKCE challenge on every sign-in, so the authorization server must support S256. It also waits about 10 seconds for discovery, registration and token responses. If your token endpoint returns 415, accept form-encoded request bodies there.

Checked against the vendor’s docs on : Anthropic: Troubleshoot connectors; Anthropic: Authentication for connectors; MCP Inspector; Anthropic: Claude connector issue tracker.

Rather hand it over?

Fixed scope, fixed price, paid upfront. The work happens in writing; no call needed.

Related: ChatGPT MCP OAuth redirect URI errors · MCP server 405 and 406 errors · MCP server authentication: API keys vs OAuth

Questions

More on this error

It works in MCP Inspector but not in Claude. Why?

Local clients such as MCP Inspector fail fast on a redirect to another host, while Claude follows it, drops the Authorization header and reports an authorization error. Local tools also connect from your own network, so private addresses and firewall rules don’t affect them. Test the exact URL from outside your network.

Is it always my server’s fault?

No. Some reports in Anthropic’s public connector issue tracker (github.com/anthropics/claude-ai-mcp) are open Claude-side problems. If every check here passes, copy the reference ID that starts with ofid_ from the error and report it there.

Can you fix it for me?

Yes, when the cause is in your server or sign-in setup: the App Fix Ticket gives you a written diagnosis first, then the fix. If the diagnosis shows a bug on the vendor’s side, I’ll tell you so and show you what to report. If you would rather have the server built or rebuilt over your existing API, the MCP Connector offer covers that at a fixed price, with OAuth sign-in as an add-on.

A different error?

Describe it and get a written quote

Send the error and what you were doing. You get a written scope, a fixed price and a timeline; we reply by email, usually within one business day.