Authorization with the MCP server failed. You can check your credentials and permissions

### MCP server URL or name

https://.pincherry.dev/mcp

### How are you connecting to this server?

From a custom connector URL I entered manually

### Where does the issue occur?

When auth finishes and redirects back to Claude.ai

### When did you last reproduce this?

2026-07-31 1:17 PM EST

### Browser and OS

ANY

### Describe the issue

Custom remote MCP connector fails with "Authorization with the MCP server failed. You can check your credentials and permissions" — reproduced identically on both Claude.ai (web) and Claude Code, across multiple fresh attempts. Server-side diagnostics show the identity/authorization step succeeds and no request from Claude's backend ever reaches the MCP server, indicating the failure is in Claude's post-authorization step (token exchange or the subsequent authenticated call to the resource server).

### Error details

```shell
Reference IDs
ofid_16b3e906625b3895
ofid_0f708ee185b993c4
ofid_c4cc2db1a95d2922
ofid_5a7ebd8cd055bba6
ofid_c7689dca68349302 (from Claude Code, same error)
Setup
Self-hosted MCP server (ToolHive VirtualMCPServer, streamable-http transport) behind a Cloudflare Tunnel, public URL https://.pincherry.dev/mcp
OAuth authorization server: a Cloudflare Access "SaaS" OIDC application (auth_type: oidc), with redirect_uris: ["https://claude.ai/api/mcp/auth_callback"], grant_types: ["authorization_code", "authorization_code_with_pkce"], scopes: ["openid", "email", "profile"]
Client ID and Client Secret entered manually in the connector's "Advanced settings" (OAuth Client ID / Secret fields), since the initial attempt without them failed with a dynamic-client-registration error
Identity provider on the Access app: One-Time PIN (email), explicitly restricted via allowed_idps so there's no ambiguity about which identity is used
resourceUrl explicitly set on the MCP server to the public HTTPS URL (confirmed this fixed an earlier, separate 404 — see below)
What's confirmed working (ruled out as causes)
RFC9728 discovery metadata is correct and reachable publicly.
GET https:///.well-known/oauth-protected-resource returns:

{
"resource": "https:///mcp",
"authorization_servers": ["https://.cloudflareaccess.com/cdn-cgi/access/sso/oidc/"],
"bearer_methods_supported": ["header"],
"jwks_uri": "https://.cloudflareaccess.com/cdn-cgi/access/sso/oidc//jwks",
"scopes_supported": ["openid"]
}
(Initially this incorrectly self-identified using an internal-only hostname, which did cause a distinct 404 on {origin}/authorize — fixed by setting the resource URL explicitly. That was a real bug on our end, now resolved and unrelated to the current failure.)

The OAuth authorization server's .well-known/openid-configuration is correct and reachable, with working authorization_endpoint, token_endpoint, and jwks_uri.

Manually driving the authorization_endpoint with proper response_type=code, client_id, redirect_uri=https://claude.ai/api/mcp/auth_callback, PKCE params, etc. returns a real, working login page (HTTP 200), not an error.

The identity/authorization step succeeds. Server-side access logs for the OAuth app show, for the matching timestamp of a failed connector attempt:

Event: Login
Decision: Access granted
Connection: onetimepin
User email:
App type: SaaS
No firewall/WAF/bot-protection blocking. Queried Cloudflare's zone-level firewall events (GraphQL Analytics API) for the full time window covering all attempts — zero events returned. Nothing was blocked or challenged at the edge.

No request of any kind ever reaches the MCP server itself. Server-side request logs (checked immediately after each failed attempt) show no incoming HTTP request at all — not even a rejected/401 one. This was checked both on the ingress/tunnel layer and on the MCP server's own application logs.

Conclusion
Given (4) the authorization step is confirmed granted, but (6) no request — authenticated or not — ever reaches the resource server, the failure must be occurring in Claude's own backend between "user completes login" and "Claude calls the MCP server," most likely at the code→token exchange step. This matches the pattern described in other open issues (e.g. #326, #327, #332) rather than anything fixable in the MCP server's own OAuth configuration.
```

### Expected behavior

After completing the OAuth authorization flow (redirecting to the identity provider, logging in, and the authorization server granting access — confirmed via server-side logs showing Decision: Access granted), Claude should exchange the returned authorization code for an access token, then use that token to connect to the MCP server. The connector should show as "Connected," and the server's tools should become available for use.

### Additional context

_No response_