What's Wrong?
When connecting to a remote MCP server that declares a non-root OAuth
registration path in its discovery document (e.g. /oauth/register),
mcp-remote fails to connect.
The client correctly fetches the OAuth discovery document from
/.well-known/oauth-authorization-server and finds the
registration_endpoint field, but then ignores it. Instead of calling
the declared URL, it constructs a hardcoded /register path on the
issuer base URL, which returns HTTP 404.
This violates RFC 8414 (OAuth 2.0 Authorization Server Metadata), which
requires clients to use the registration_endpoint value from the
discovery document when present.
The same MCP server connects and authenticates successfully with other
clients, confirming full spec compliance on the server side and that
the issue is in mcp-remote.
What Should Happen?
mcp-remote should read the registration_endpoint field from the
OAuth discovery document and use that exact URL to register the client
dynamically, as required by RFC 7591 (OAuth 2.0 Dynamic Client
Registration) and RFC 8414.
In this specific case, the correct registration URL is:
https://www.app.fattura24.com/s2/oauth/register
This endpoint is fully functional. A direct call returns a valid
client_id:
curl -X POST https://www.app.fattura24.com/s2/oauth/register \
-H "Content-Type: application/json" \
-d '{
"redirect_uris": ["http://localhost:13246/callback"],
"client_name": "mcp-remote-test",
"grant_types": ["authorization_code"],
"response_types": ["code"],
"token_endpoint_auth_method": "none",
"scope": "mcp"
}'Response:
{
"client_id": "f24_67f1ee5524754764813f7db76cbee7fb",
"client_id_issued_at": 1774026058,
"client_name": "mcp-remote-test",
"redirect_uris": ["http://localhost:13246/callback"],
"grant_types": ["authorization_code", "refresh_token"],
"response_types": ["code"],
"token_endpoint_auth_method": "none"
}Error Messages/Logs
[31494] Discovering OAuth server configuration...
[31494] Discovered authorization server: https://www.app.fattura24.com/s2
[31494] Connecting to remote server: https://www.app.fattura24.com/s2/mcp
[31494] Using transport strategy: http-first
[31494] Received error (status unknown): HTTP 404: Invalid OAuth error
response: SyntaxError: Unexpected token '<', "<html><hea"... is not
valid JSON. Raw body: <html>...<h1>HTTP Status 404 - /register</h1>...
[31494] Recursively reconnecting for reason: falling-back-to-alternate-transport
[31494] Connecting to remote server: https://www.app.fattura24.com/s2/mcp
[31494] Using transport strategy: sse-only
[31494] Connection error: ServerError: HTTP 404: Invalid OAuth error
response [...]
[31494] Fatal error: ServerError: HTTP 404 [...]
The key detail: the discovery document correctly declares
registration_endpoint as .../oauth/register, but mcp-remote
calls .../register (hardcoded path appended to the issuer URL).
Steps to Reproduce
- Set up a remote MCP server with OAuth where the registration
endpoint is at a non-root path (e.g. /oauth/register), declared
correctly in the discovery document:
{
"issuer": "https://www.app.fattura24.com/s2",
"authorization_endpoint": "https://www.app.fattura24.com/s2/oauth/authorize",
"token_endpoint": "https://www.app.fattura24.com/s2/oauth/token",
"registration_endpoint": "https://www.app.fattura24.com/s2/oauth/register",
"response_types_supported": ["code"],
"grant_types_supported": ["authorization_code", "refresh_token"],
"code_challenge_methods_supported": ["S256"],
"token_endpoint_auth_methods_supported": ["none"],
"scopes_supported": ["mcp"]
}
- Run:
npx mcp-remote https://www.app.fattura24.com/s2/mcp
- Observe that
mcp-remote calls /register instead of
/oauth/register, receiving HTTP 404.
Environment:
- mcp-remote: 0.1.38
- Node.js: v22.14.0
- macOS (Apple Silicon)
What's Wrong?
When connecting to a remote MCP server that declares a non-root OAuth
registration path in its discovery document (e.g.
/oauth/register),mcp-remotefails to connect.The client correctly fetches the OAuth discovery document from
/.well-known/oauth-authorization-serverand finds theregistration_endpointfield, but then ignores it. Instead of callingthe declared URL, it constructs a hardcoded
/registerpath on theissuer base URL, which returns HTTP 404.
This violates RFC 8414 (OAuth 2.0 Authorization Server Metadata), which
requires clients to use the
registration_endpointvalue from thediscovery document when present.
The same MCP server connects and authenticates successfully with other
clients, confirming full spec compliance on the server side and that
the issue is in
mcp-remote.What Should Happen?
mcp-remoteshould read theregistration_endpointfield from theOAuth discovery document and use that exact URL to register the client
dynamically, as required by RFC 7591 (OAuth 2.0 Dynamic Client
Registration) and RFC 8414.
In this specific case, the correct registration URL is:
https://www.app.fattura24.com/s2/oauth/registerThis endpoint is fully functional. A direct call returns a valid
client_id:Response:
{ "client_id": "f24_67f1ee5524754764813f7db76cbee7fb", "client_id_issued_at": 1774026058, "client_name": "mcp-remote-test", "redirect_uris": ["http://localhost:13246/callback"], "grant_types": ["authorization_code", "refresh_token"], "response_types": ["code"], "token_endpoint_auth_method": "none" }Error Messages/Logs
The key detail: the discovery document correctly declares
registration_endpointas.../oauth/register, butmcp-remotecalls
.../register(hardcoded path appended to the issuer URL).Steps to Reproduce
endpoint is at a non-root path (e.g.
/oauth/register), declaredcorrectly in the discovery document:
{ "issuer": "https://www.app.fattura24.com/s2", "authorization_endpoint": "https://www.app.fattura24.com/s2/oauth/authorize", "token_endpoint": "https://www.app.fattura24.com/s2/oauth/token", "registration_endpoint": "https://www.app.fattura24.com/s2/oauth/register", "response_types_supported": ["code"], "grant_types_supported": ["authorization_code", "refresh_token"], "code_challenge_methods_supported": ["S256"], "token_endpoint_auth_methods_supported": ["none"], "scopes_supported": ["mcp"] }mcp-remotecalls/registerinstead of/oauth/register, receiving HTTP 404.Environment: