mcp-remote builds invalid OAuth discovery URL for Keycloak path issuer
Why does mcp-remote build an invalid .well-known OAuth discovery URL when the authorization server uses a path such as Keycloak's realm endpoint? The token request then fails with "Invalid OAuth error response: SyntaxError: Unexpected token '<'". Is there a workaround or a fixed release for this issue?
Originally asked on GitHub: https://github.com/punkpeye/mcp-remote/issues/128
5 answers
Status: fixed in mcp-remote v0.1.48 (commit 2d323e6). Discovery now probes a priority-ordered candidate list instead of a single guessed URL shape: RFC 8414 path-insertion, then root oauth-authorization-server, then both OIDC shapes.
The root cause is in the OAuth metadata lookup: fetchAuthorizationServerMetadata built the well-known URL from the issuer's origin and discarded the path, so an issuer like https://host/auth/realms/myRealm (opens external site) was queried at the wrong location. Discovery then fell back to root discovery, and the later token request to Keycloak failed with "Invalid OAuth error response: SyntaxError: Unexpected token '<'" because an HTML page was returned instead of a token response.
Temporary workaround (before the fix): in a local clone of mcp-remote, edit package.json so the dependency reads "@modelcontextprotocol/sdk": "^1.17.1". A commenter reported that this seemed to do the trick locally. The mcp-remote 0.1.19 release also incorporated the typeScript SDK changes, but a commenter noted that resource metadata could still fail when multiple transport objects and recursive invocation were involved.
Permanent fix: upgrade to mcp-remote v0.1.48 or later. The maintainer states that the candidate-list approach is required, because a path-only implementation would regress servers that serve metadata at the root. The fix also covers issuers with any path component, Keycloak realms, and reverse proxies with path routing such as Tailscale serve.
Did this work for you?What a GitHub user tried on GitHub (Didn't work)
Reporter described the default flow: after the malformed discovery URL, mcp-remote fell back to root discovery and Keycloak rejected the token request with an HTML error, so OAuth could not complete.
Source: https://github.com/punkpeye/mcp-remote/issues/128 (opens external site)
Did this work for you?What @asparsh29kumar tried on GitHub (Worked)
Locally changed mcp-remote's package.json dependency to "@modelcontextprotocol/sdk": "^1.17.1"; the commenter said this seemed to do the trick for them locally.
Source: https://github.com/punkpeye/mcp-remote/issues/128#issuecomment-3143705742 (opens external site)
Did this work for you?What @halllo tried on GitHub (Partly worked)
After the SDK change and the 0.1.19 release, a commenter still hit resource-metadata problems caused by the use of multiple transport objects and recursive invocation, and proposed a fix in PR #167.
Source: https://github.com/punkpeye/mcp-remote/issues/128#issuecomment-3316074071 (opens external site)
Did this work for you?What @punkpeye tried on GitHub (Worked)
Upgrading to mcp-remote v0.1.48 (commit 2d323e6), which probes a priority-ordered discovery candidate list, resolved the reported issue and the related path-issuer cases from #207, #249, and #174.
Source: https://github.com/punkpeye/mcp-remote/issues/128#issuecomment-5427331813 (opens external site)
Did this work for you?