claude.ai connector OAuth fails with mcp_client_invalid — server confirmed working via direct testing, no server-side logs during Connect attempts

### MCP server URL

https://mcp.dartera.ch/mcp

### Where does the issue occur?

When pressing the Connect button

### Transport used

streamable-http

### Client registration type

Dynamic Client Registration (DCR)

### SSE only: Does your server return the expected status code for POST requests?

Not applicable (my server does not use SSE)

### When did you last reproduce this?

2026-08-07, 10:14 UTC (multiple reproductions 07:35–10:14 UTC same day)

### Browser and OS

Chrome 150 on macOS

### Describe the issue

Custom connector to a self-hosted MCP server (ms-365-mcp-server / Microsoft 365) fails every attempt to connect from claude.ai. Confirmed server-side auth flow is fully functional via direct manual testing (DCR registration, redirect to Microsoft Entra, real login page all work correctly). The failure is happening entirely on claude.ai's side, not the server's.

Sequence of findings across ~2.5 hours of testing:

1. Initial state: connector showed "Connection has expired," clicking Connect produced no visible action (no popup, no redirect, nothing).
2. Manually drove the OAuth flow via curl, bypassing claude.ai entirely: POST /register -> valid client_id issued immediately (DCR works). Built /authorize URL with that client_id + PKCE, opened in browser -> reached a real Microsoft Entra login page -> Microsoft returned AADSTS50011: redirect_uri mismatch, because our server was forwarding the caller-supplied redirect_uri straight to Microsoft instead of using its own fixed registered one (a known issue in older ms-365-mcp-server versions, CWE-601-style). This confirmed the server's OAuth flow works end-to-end when driven directly.
3. Fixed the redirect_uri handling server-side (MS365_MCP_ALLOWED_REDIRECT_URIS allowlist, already present in our installed version 0.128.2, just needed configuring). Restarted the service.claude.ai connector OAuth fails with mcp_client_invalid — server confirmed working via direct testing, no server-side logs during Connect attempts
4. Retried Connect from claude.ai. Same generic failure, error_code=mcp_client_invalid, new reference each time. Checked our server's systemd journal for the exact attempt window: zero log lines. No request reached the server at all. Repeated this 3+ times (normal session, remove+re-add connector, fresh incognito session/fresh login) -- same result every time: no server-side activity, connector fails with a new ofid_ reference each attempt.
5. Removing and re-adding the connector under a new display name did not generate a new connector ID on claude.ai's side -- it reused the same internal ID (bce71812-c00d-4dfe-a19d-55d91d5a23a9) as the original broken connector, suggesting the failure may be tied to a stuck server-side record for that specific connector rather than anything client-configurable.
This strongly suggests the block is on claude.ai's side for this specific connector record, not in our server's OAuth implementation, which we've independently proven works.

### Issue details

```shell
Error shown in claude.ai: "Authorization with the MCP server failed. You can check your credentials and permissions. If this persists, share this reference with support: [ofid]"

Multiple reference IDs collected across this session (all same underlying issue):
ofid_ad8a6775165a8175
ofid_4e60d64d36457692
ofid_3d5e45ac45e0a769
ofid_77ca778fb55fc080
ofid_e895f70682592280

Connector internal ID (unchanged across remove/re-add attempts): bce71812-c00d-4dfe-a19d-55d91d5a23a9
```

### Expected behavior

Pressing Connect (or Reconnect) should run the DCR + OAuth flow against our server exactly as our manual curl-driven test did, reach the Microsoft login screen, and complete successfully.

### Logs from your server

```shell
Confirmed via curl: /register returns a valid client_id, /authorize correctly redirects to Microsoft Entra with a real login page (AADSTS50011 was our own bug, already fixed).

During claude.ai Connect/Reconnect attempts: sudo journalctl -u ms365-mcp shows zero new log entries for the attempt window each time -- the request never reaches our server.
```

### Additional context

Happy to provide further server logs, timestamps, or grant read access to reproduce if that helps triage.