Custom connector: OAuth completes successfully (token 200 OK) but client never sends follow-up MCP request — infinite re-registration loop

### MCP server URL

https://mcp.getassemblr.com/mcp

### Where does the issue occur?

Other

### 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-06-09 4:00 PM AKST

### Browser and OS

Chrome on Windows 11, 64-bit

### Describe the issue

---

Title: Custom connector: OAuth completes successfully (token 200 OK) but client never sends follow-up MCP request — infinite re-registration loop [WORKAROUND FOUND]

---

Summary

When connecting a custom MCP server to Claude.ai via a custom connector, the OAuth 2.0 + PKCE flow completes perfectly every single time — the authorization code is issued, the token endpoint returns 200 OK with a valid Bearer token — and then nothing happens. Claude.ai's backend never sends a follow-up MCP request using the token. Instead it immediately re-registers a new OAuth client and repeats the entire flow from scratch, then fails with "Authorization with the MCP server failed."

This has been reproduced across two transports (SSE and Streamable HTTP), with and without an OAuth layer server-side, across eight separate connection attempts, with every RFC-compliance fix applied. The server implementation is correct. The bug is in Claude.ai's post-token-exchange handling.

A workaround was found after two days of debugging — see Resolution section at the bottom.

---

Environment

Component | Detail
-- | --
MCP server | obsidian-web-mcp (custom), FastMCP (Python), mcp SDK 1.x
Transport tested | SSE (/sse) — primary
Transport also tested | Streamable HTTP (/)
Hosting | Cloudflare Tunnel → localhost:8420
Public URL | https://mcp.getassemblr.com/sse
OAuth implementation | RFC 6749 authorization_code + RFC 7636 PKCE S256 + RFC 7591 DCR + RFC 8707 resource indicators + RFC 9728 PRM
Also tested without OAuth | Bearer-only auth (no OAuth routes) — same outcome
Claude.ai tested from | Web browser, custom connector UI
Other clients tested | Claude Code (MCP), ChatGPT — both connect on first try with identical server

---

Resolution — Workaround Found

After two days of debugging, the connection was achieved by changing the connector URL endpoint path to /mcp.

The discovery: Anthropic's own GitHub issue template uses the placeholder URL https://example.com/mcp. The /mcp path appears to be the expected format for Claude.ai's connector. We had been using the root path (/) and /sse — the /mcp path had never been tested.

What worked:

• Endpoint path: /mcp


• Transport: Streamable HTTP (handles both GET and POST on the same endpoint, which is required for the MCP initialize handshake)


• Connector URL: https://mcp.getassemblr.com/mcp

What the working log looked like:

POST /mcp  → 401  (no token — correct)

[OAuth discovery and token exchange — identical to before]

POST /oauth/token  → 200 OK  (token issued)

POST /mcp  → 200 OK  (AUTH OK — first time ever)

GET  /mcp  → 200 OK  (SSE stream / MCP connection established)

initialize → initialized  (handshake complete)

Why this matters for the bug report: The underlying bug still exists. Claude.ai's connector silently fails the post-token handshake when the endpoint path is not /mcp. Developers using /, /sse, or any other path will hit the exact same infinite re-registration loop with no error message indicating the path is the problem. The error message "Authorization with the MCP server failed" actively misleads developers into debugging their OAuth implementation rather than their URL format.

Recommendation: Claude.ai's connector should either enforce the /mcp path requirement with a clear error message, or fix the post-token handling to work correctly regardless of endpoint path.

### Issue details

```shell
***See "Describe Issue"
```

### Expected behavior

***See "Describe Issue"

### Logs from your server

```shell
POST /mcp → 401 (no token)
GET /.well-known/oauth-protected-resource → 200
GET /.well-known/oauth-authorization-server → 200
POST /oauth/register → 201
GET /oauth/authorize → 200
POST /oauth/authorize → 302
POST /oauth/token → 200 (token issued)
[ SILENCE — zero follow-up requests ]
POST /oauth/register → 201 (immediate re-registration, new client_id)
GET /oauth/authorize → 200
POST /oauth/authorize → 302
POST /oauth/token → 200 (second token issued)
[ SILENCE — zero follow-up requests ]
→ Claude.ai reports: "Authorization with the MCP server failed"

That's the exact pattern, eight times in a row across two days.
```

### Additional context

Workaround confirmed: changing the connector URL endpoint path from / or /sse to /mcp resolved the issue. Combined with Streamable HTTP transport, the MCP initialize handshake completed successfully on the first attempt after the path change.

The bug is triggered by any endpoint path other than /mcp. Claude Code and ChatGPT are not affected — both connect correctly regardless of path. The silent failure and misleading error message are specific to Claude.ai's web custom connector.

Related issue: #291