How to enable Client ID Metadata Document auth in mcp-remote for OAuth servers that support it?
I am using mcp-remote v0.1.38 with an MCP server behind a Kubernetes path-based ingress. The authorization server advertises client_id_metadata_document_supported: true, but the Client ID Metadata Document flow never starts because NodeOAuthClientProvider has no clientMetadataUrl getter, and the SDK fallback strips the URL path. How can I get mcp-remote to use the client metadata document instead of dynamic client registration?
Originally asked on GitHub: https://github.com/punkpeye/mcp-remote/issues/224
3 answers
Fixed in mcp-remote v0.7.0. The maintainer added a --client-metadata-url flag on the provider side and released it, so you no longer need to patch dist/ files.
Upgrade to v0.7.0 and run:
npx mcp-remote https://host/app10096/tess-mcp/sse (opens external site) 3334 --client-metadata-url https://host/app10096/tess-mcp/.well-known/oauth-client-metadata (opens external site)
Replace host and the app path with your deployment. The server must advertise client_id_metadata_document_supported: true; when it does not, mcp-remote falls back to Dynamic Client Registration, so you can leave the flag in place.
Details from the fix: the client metadata URL is used on every run and is never cached as a registration. The flag makes the callback port strict, so the redirect_uris in your client metadata document must match exactly; there is no silent fallback if the port is busy. Refresh tokens are tied to the client that obtained them, so credentials are stored separately from dynamically registered clients.
The two underlying SDK bugs you hit are also fixed in v0.7.0. mcp-remote now runs its own OAuth discovery with a priority-ordered list of well-known URLs that preserves the path (so https://host/app10096/tess-mcp (opens external site) works behind path-based ingress), and it calls finishAuth on the transport that actually received the 401 instead of relying on copying _resourceMetadataUrl between transports.
Security note: serve the client metadata document over HTTPS and keep redirect_uris consistent with the strict callback behavior.
Did this work for you?What a GitHub user tried on GitHub (Didn't work)
Attempted to use the Client ID Metadata Document flow with mcp-remote v0.1.38 behind a Kubernetes path-based ingress. The flow never started because NodeOAuthClientProvider lacked clientMetadataUrl and the SDK auth() fallback stripped the URL path, turning https://host/app10096/tess-mcp/sse (opens external site) into https://host/ (opens external site).
Source: https://github.com/punkpeye/mcp-remote/issues/224 (opens external site)
Did this work for you?What @punkpeye tried on GitHub (Worked)
Maintainer implemented the fix on main as --client-metadata-url and released it in v0.7.0, suggesting: npx mcp-remote https://host/app10096/tess-mcp/sse (opens external site) 3334 --client-metadata-url https://host/app10096/tess-mcp/.well-known/oauth-client-metadata (opens external site). Bugs 2 and 3 were fixed independently, so manual dist/ patches are no longer needed.
Source: https://github.com/punkpeye/mcp-remote/issues/224#issuecomment-5440375767 (opens external site)
Did this work for you?