Technical summary for Anthropic Support

### MCP server URL

https://itservicedesk.filmore.com.vn/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-17 17:07 ICT (UTC+7)

### Browser and OS

Windows 11 64-bit, Chrome 151 (tested via claude.ai web) AND Claude Desktop app — same "Couldn't connect to the server" / "Connection issue" error reproduced identically on both.

### Describe the issue

Custom connector fails silently: client fetches protected-resource-metadata successfully but never calls /register afterward, shown as "Couldn't connect to the server. Check that the URL points to a valid MCP server." Server-side OAuth flow fully verified working via manual end-to-end simulation.

### Issue details

```shell
Error popups seen in Claude.ai:
1. "Couldn't connect to the server. Check that the URL points to a valid MCP server." (shown when adding the connector / on Reconnect)
2. "Couldn't reach IT Service Desk. You can check the server URL and verify the server is running. If this persists, share this reference with support: 'ofid_36acf6e242ad2c52'" (shown separately, reference ID ofid_36acf6e242ad2c52)
3. Same error again on a later attempt with reference ID ofid_d376d93f95f2542a

Server: https://itservicedesk.filmore.com.vn/mcp — MCP Python SDK, Streamable HTTP transport, OAuth 2.1 + PKCE + Dynamic Client Registration per the MCP Authorization spec.

I manually verified the server works correctly end-to-end by simulating the full OAuth flow via curl/httpx:
1. POST /register → 201 Created, valid client_id issued
2. GET /authorize (with PKCE S256, resource param) → 302 redirect to login page
3. POST /login/callback (passphrase login) → 302 redirect to redirect_uri with code
4. POST /token (with code_verifier) → 200, valid access_token issued
5. POST /mcp with Authorization: Bearer , JSON-RPC initialize → 200, correct protocolVersion, capabilities, serverInfo returned

Server access logs confirm the real Claude client (both claude.ai web and Claude Desktop, reproduced identically on both) successfully called and received 200 OK from:
- GET /.well-known/oauth-authorization-server (at domain root)
- GET /.well-known/oauth-protected-resource/mcp (per RFC 9728 path-insertion, since the resource has a /mcp path)

However, after successfully fetching protected-resource-metadata, the client stops and never calls POST /register. No further requests reach the server after that point, including after clicking "Reconnect" on the saved connector.

This was reproduced identically when adding the connector fresh and via "Reconnect", on both claude.ai web (Chrome 151/Windows) and Claude Desktop app.
```

### Expected behavior

After successfully fetching the protected-resource-metadata (which the client already does correctly), the client should proceed to call POST /register (Dynamic Client Registration), then redirect the user to /authorize for login, complete the OAuth code exchange via /token, and successfully establish the MCP connection — allowing the connector to show as "Connected" and enabling tool calls against the server.

I have verified server-side that every one of these subsequent steps (register, authorize, login, token exchange, authenticated MCP initialize call) works correctly when performed manually — so the expected behavior is for the Claude client to actually attempt and complete them, instead of stopping silently right after the protected-resource-metadata fetch.

### Logs from your server

```shell
Aug 17 08:30:00 uvicorn: 14.161.13.95 - "GET /.well-known/oauth-authorization-server HTTP/1.1" 200 OK
Aug 17 08:30:09 uvicorn: 14.161.13.95 - "GET /mcp HTTP/1.1" 401 Unauthorized
Aug 17 08:34:48 uvicorn: 127.0.0.1 - "GET /.well-known/oauth-protected-resource/mcp HTTP/1.1" 200 OK (my own manual curl test confirming this endpoint works)
Aug 17 08:35:06 uvicorn: 14.161.13.95 - "GET /.well-known/oauth-protected-resource/mcp HTTP/1.1" 200 OK (real client — User-Agent: "Claude-User (claude-code/2.1.233; +https://support.anthropic.com/)")

--- No further requests from this client (no /register, /authorize, /token) at any point after this ---

--- My own manual end-to-end simulation of the exact same flow, run minutes later, succeeded completely: ---
1. REGISTER 201 {"response_types":["code"],"scope":"user",...,"client_id":"1803e353-...", ...}
2. AUTHORIZE 302 -> https://itservicedesk.filmore.com.vn/login?state=...&client_id=...
3. LOGIN CALLBACK 302 -> https://claude.ai/api/mcp/auth_callback?code=mcp_...&state=...
4. TOKEN 200 {"access_token":"mcp_...","token_type":"Bearer","expires_in":604800,"scope":"user"}
5. MCP INITIALIZE 200 {"jsonrpc":"2.0","id":1,"result":{"capabilities":{...},"protocolVersion":"2025-06-18","serverInfo":{"name":"osTicket Service Desk",...}}}
```

### Additional context

Server: MCP Python SDK (pip package "mcp", installed version 2.0.0), built with MCPServer (mcp.server.mcpserver.server) + OAuthAuthorizationServerProvider, served via `MCPServer.streamable_http_app()` under uvicorn, reverse-proxied by Apache (path-based proxying for /mcp, /.well-known/, /authorize, /token, /register, /revoke, /login at domain root — confirmed working end-to-end through Apache too, not just directly on localhost).

Earlier in debugging we found and fixed two real server-side issues before reaching the current state:
1. A fail2ban rule on our own infrastructure was incorrectly flagging requests to /mcp as bot-scanning activity and banning the source IP after a single request — fixed by excluding /mcp from that filter. (This explains an earlier, different error we saw: "Couldn't connect to the server" with plain TCP connection refused.)
2. AuthSettings.resource_server_url was initially left None (following an SDK example targeting an older spec revision), which meant /.well-known/oauth-protected-resource was not exposed and WWW-Authenticate didn't include resource_metadata. Fixed by setting resource_server_url to the /mcp resource URL, which enabled RFC 9728 discovery — after this fix, the client did start successfully fetching that endpoint (see logs above), but still stops right after.

Given the manual end-to-end reproduction above proves every subsequent step works correctly server-side, we believe the remaining issue is entirely client-side (claude.ai web + Claude Desktop, both reproduce identically).