Custom connector: authorization_endpoint from discovery metadata ignored — hardcoded /authorize used instead, causing 404

### MCP server URL

https://homeassistant.tailf1e017.ts.net/api/webhook/mcp_

### Where does the issue occur?

In the authorization screen from my server

### 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?

31.08.2026, ca. 09:00 CEST (UTC+2)

### Browser and OS

Windows 10, Firefox

### Describe the issue

When connecting a custom connector to a self-hosted MCP server (Home Assistant / ha-mcp) via OAuth, Claude opens an authorize URL that is missing the path prefix specified in the server's own discovery metadata, resulting in a 404 on the authorization screen.

### Issue details

```shell
Adding this connector initially failed during automatic Dynamic Client Registration with:
"Couldn't register with [server]'s sign-in service. You can try again, or add an OAuth Client ID in the connector settings." (ofid_40835adb1c1115db, then ofid_e63178460fb742c0 on retry after a full server restart).

To isolate the cause, I manually replayed the discovery + registration flow with curl. All steps succeeded server-side (see Logs section below): protected resource metadata, issuer-specific authorization server metadata, and a manual POST to the registration_endpoint (201 Created).

I then removed the connector, re-added it, and supplied the client_id obtained from the successful manual registration. Clicking Connect opened:
https://homeassistant.tailf1e017.ts.net/authorize?response_type=code&client_id=hamcp-dcr-&redirect_uri=https%3A%2F%2Fclaude.ai%2Fapi%2Fmcp%2Fauth_callback&code_challenge=&code_challenge_method=S256&state=

After signing in with my Claude account, this returned 404.

The server's own discovery metadata (see Logs) specifies:
"authorization_endpoint": "https://homeassistant.tailf1e017.ts.net/api/mcp_proxy/oauth/authorize"

but Claude requested:
https://homeassistant.tailf1e017.ts.net/authorize

— i.e. missing the /api/mcp_proxy/oauth path prefix entirely.
```

### Expected behavior

Claude should use the exact authorization_endpoint value returned by the issuer-specific authorization server metadata document (as referenced by the protected resource metadata's authorization_servers field), rather than constructing or falling back to a path relative to the bare origin.

### Logs from your server

```shell
[2026-08-31 08:52:46 CEST] MCP handshake sanity check:
POST /api/webhook/mcp_ (Accept: application/json, text/event-stream)
→ 200 OK, valid initialize response with full serverInfo/capabilities

[2026-08-31 08:50:55 CEST] Protected resource metadata:
GET /.well-known/oauth-protected-resource/api/webhook/mcp_
→ 200 OK
{"resource": "https://homeassistant.tailf1e017.ts.net/api/webhook/mcp_", "authorization_servers": ["https://homeassistant.tailf1e017.ts.net/api/mcp_proxy/oauth"], "bearer_methods_supported": ["header"], "resource_documentation": "https://github.com/homeassistant-ai/ha-mcp"}

[2026-08-31 08:52:04 CEST] Issuer-specific authorization server metadata:
GET /.well-known/oauth-authorization-server/api/mcp_proxy/oauth
→ 200 OK
{"issuer": "https://homeassistant.tailf1e017.ts.net/api/mcp_proxy/oauth", "authorization_endpoint": "https://homeassistant.tailf1e017.ts.net/api/mcp_proxy/oauth/authorize", "token_endpoint": "https://homeassistant.tailf1e017.ts.net/api/mcp_proxy/oauth/token", "registration_endpoint": "https://homeassistant.tailf1e017.ts.net/api/mcp_proxy/oauth/register", "response_types_supported": ["code"], "grant_types_supported": ["authorization_code"], "code_challenge_methods_supported": ["S256"], "token_endpoint_auth_methods_supported": ["none"], "client_id_metadata_document_supported": true}

[2026-08-31 08:52:46 CEST] Manual DCR against the correct registration_endpoint:
POST /api/mcp_proxy/oauth/register {"client_name":"Claude","redirect_uris":["https://claude.ai/api/mcp/auth_callback"],"grant_types":["authorization_code","refresh_token"],"response_types":["code"],"token_endpoint_auth_method":"none"}
→ 201 Created, valid client_id returned

Note: the domain root /.well-known/oauth-authorization-server (no path suffix) also returns 200 OK but describes Home Assistant's own native auth system (/auth/authorize, /auth/token) — a different, unrelated authorization server. This may be relevant if Claude's discovery walk is falling back to that root document instead of the issuer-specific one, though the 404'd URL doesn't fully match either document's endpoints.
```

### Additional context

Server: self-hosted HA-MCP add-on (Home Assistant), exposed via Tailscale Funnel (not Cloudflare). MCP server version reported in initialize response: ha-mcp 8.4.0.
All curl tests run from an external Windows machine (not on the same network/tailnet as the server) to rule out DNS/geo-blocking issues — confirmed public reachability throughout.
Reference IDs collected across attempts: ofid_38c09f3449d4f3b5, ofid_40835adb1c1115db, ofid_e63178460fb742c0.

No repository files or tests are named. Start by tracing the custom connector OAuth flow described here, from protected-resource metadata through the issuer-specific authorization-server metadata, and compare the returned authorization_endpoint with the URL Claude requests. Done means the exact metadata endpoint, including its path prefix, is used for authorization and the reported reproduction no longer returns 404.

Escrito por el modelo de indexación a partir del texto del issue.