Regression in 0.1.36: authorize URL built from MCP server origin instead of discovered authorization server endpoint

[Elrendio]

Summary

Since 0.1.36, the interactive OAuth flow builds the authorization URL from the MCP server origin (<server-origin>/authorize) instead of the authorization_endpoint of the discovered authorization server — even though discovery itself succeeds and logs the right AS. 0.1.35 is the last version that builds the correct URL.

Version matrix (tested 2026-07-05 against https://mcp.frontapp.com/mcp):

version	authorize URL opened	result
0.1.35	https://app.frontapp.com/oauth/authorize?...	✅ correct
0.1.36	https://mcp.frontapp.com/authorize?...	❌ 404
0.1.37	https://mcp.frontapp.com/authorize?...	❌ 404
0.1.38	https://mcp.frontapp.com/authorize?...	❌ 404

The server answers {"error":"No such route: GET /authorize"}, so auth (and token refresh, which derives its endpoint the same way) can never complete. Every client start loops back into a browser tab that 404s.

The server is fully RFC 9728 / MCP-auth-spec compliant

Front's MCP server (public) advertises everything a client needs — its authorization server just lives on a different origin:

$ curl -si -X POST https://mcp.frontapp.com/mcp | grep -i www-authenticate
www-authenticate: Bearer resource_metadata="https://mcp.frontapp.com/.well-known/oauth-protected-resource"

$ curl -s https://mcp.frontapp.com/.well-known/oauth-protected-resource
{"resource":"https://mcp.frontapp.com","authorization_servers":["https://app.frontapp.com"], ...}

$ curl -s https://app.frontapp.com/.well-known/oauth-authorization-server
{"issuer":"https://app.frontapp.com","authorization_endpoint":"https://app.frontapp.com/oauth/authorize","token_endpoint":"https://app.frontapp.com/oauth/token", ...}

Repro

npx -y mcp-remote@0.1.38 https://mcp.frontapp.com/mcp 3334 --host 127.0.0.1 \
  --static-oauth-client-info '{"client_id":"<redacted>","client_secret":"<redacted>"}'

(Front requires a pre-registered static client — no DCR — but any MCP server whose authorization server is on a different origin should reproduce.)

0.1.37 output — note it discovers the AS correctly and then ignores it:

[pid] Discovering OAuth server configuration...
[pid] Discovered authorization server: https://app.frontapp.com
[pid] Connecting to remote server: https://mcp.frontapp.com/mcp
Please authorize this client by visiting:
https://mcp.frontapp.com/authorize?response_type=code&client_id=<redacted>&code_challenge=...&redirect_uri=http%3A%2F%2F127.0.0.1%3A3334%2Foauth%2Fcallback&...

Same behavior on 0.1.36 and 0.1.38 (0.1.38 doesn't log the "Discovered authorization server" line but opens the same origin-based URL).

0.1.35 output for comparison (correct):

[pid] Using authorization server from Protected Resource Metadata { authorizationServerUrl: 'https://app.frontapp.com' }
Please authorize this client by visiting:
https://app.frontapp.com/oauth/authorize?response_type=code&client_id=<redacted>&...

Expected

The authorize (and token) URLs should come from the discovered authorization server metadata — https://app.frontapp.com/oauth/authorize — as in 0.1.35.

Possibly related

Looks like the same family as #241 (discovered registration_endpoint ignored, hardcoded /register used) and #270 (proxy mode POSTs token exchange to the resource URL instead of the discovered token_endpoint): endpoints built from the resource origin instead of the discovered AS metadata.

[CDL-RohaanA]

+1 facing the same issue.

[devmaha]

We recently forked mcp-remote and fixed a number of auth-related problems. If it's helpful, you can try the fork here: https://github.com/abluva/mcp-remote

We'll be maintaining it going forward, so feel free to open issues or PRs there if you run into anything else.