Subject: MCP OAuth Dynamic Client Registration fails for remote HTTP connector (magnific.com) — ref ofid_027bfef7df1ab3f5

[ahelbert-cmd]

MCP server URL or name

https://mcp.magnific.com

How are you connecting to this server?

From browsing the MCP server directory

Where does the issue occur?

When pressing the Connect button

When did you last reproduce this?

06/07/2026 14H france

Browser and OS

No response

Describe the issue

Subject: MCP OAuth Dynamic Client Registration fails for remote HTTP connector (magnific.com) — ref ofid_027bfef7df1ab3f5

Description:

When trying to authenticate the Magnific MCP connector (https://mcp.magnific.com, HTTP transport) added via claude mcp add, the OAuth flow fails immediately with the error:

"Impossible de s'inscrire auprès du service de connexion de Magnific. Vous pouvez réessayer ou ajouter un identifiant client OAuth dans les paramètres du connecteur."
("Couldn't register with the sign-in service. You can retry or add an OAuth client ID in the connector settings.")

Reference ID: ofid_027bfef7df1ab3f5

Steps to reproduce:

claude mcp add --transport http magnific https://mcp.magnific.com
Start an interactive session, run /mcp
Select magnific to authenticate
Error appears before the browser OAuth screen even loads
Diagnostic already performed:
I verified Magnific's server-side OAuth metadata and registration endpoint directly:

GET https://mcp.magnific.com/.well-known/oauth-authorization-server → 200 OK, correctly advertises registration_endpoint: https://auth.magnific.com/realms/mcp/clients-registrations/openid-connect
POST directly to that registration_endpoint with a minimal DCR payload (redirect_uris, client_name) → 201 Created, so Magnific's Dynamic Client Registration endpoint works correctly when called directly.
This suggests the failure is happening in Claude's own OAuth/DCR client logic (malformed registration request, header issue, redirect handling, etc.), not on Magnific's auth server.

Environment:

macOS (Darwin), hostname lmwr-lap043
Claude Code CLI, connector added via claude mcp add --transport http
Note: I noticed similar error formats (ofid_...) reported against unrelated MCP servers in anthropics/claude-ai-mcp (issue #457) and anthropics/claude-code (issues #11585, #26917, #36307), suggesting this may be a broader bug in Claude's DCR client rather than something specific to Magnific.

Error details

Subject: MCP OAuth Dynamic Client Registration fails for remote HTTP connector (magnific.com) — ref ofid_027bfef7df1ab3f5

Description:

When trying to authenticate the Magnific MCP connector (https://mcp.magnific.com, HTTP transport) added via claude mcp add, the OAuth flow fails immediately with the error:

"Impossible de s'inscrire auprès du service de connexion de Magnific. Vous pouvez réessayer ou ajouter un identifiant client OAuth dans les paramètres du connecteur."
("Couldn't register with the sign-in service. You can retry or add an OAuth client ID in the connector settings.")

Reference ID: ofid_027bfef7df1ab3f5

Steps to reproduce:

claude mcp add --transport http magnific https://mcp.magnific.com
Start an interactive session, run /mcp
Select magnific to authenticate
Error appears before the browser OAuth screen even loads
Diagnostic already performed:
I verified Magnific's server-side OAuth metadata and registration endpoint directly:

GET https://mcp.magnific.com/.well-known/oauth-authorization-server → 200 OK, correctly advertises registration_endpoint: https://auth.magnific.com/realms/mcp/clients-registrations/openid-connect
POST directly to that registration_endpoint with a minimal DCR payload (redirect_uris, client_name) → 201 Created, so Magnific's Dynamic Client Registration endpoint works correctly when called directly.
This suggests the failure is happening in Claude's own OAuth/DCR client logic (malformed registration request, header issue, redirect handling, etc.), not on Magnific's auth server.

Environment:

macOS (Darwin), hostname lmwr-lap043
Claude Code CLI, connector added via claude mcp add --transport http
Note: I noticed similar error formats (ofid_...) reported against unrelated MCP servers in anthropics/claude-ai-mcp (issue [#457](https://github.com/anthropics/claude-ai-mcp/issues/457)) and anthropics/claude-code (issues [#11585](https://github.com/anthropics/claude-code/issues/11585), [#26917](https://github.com/anthropics/claude-code/issues/26917), [#36307](https://github.com/anthropics/claude-code/issues/36307)), suggesting this may be a broader bug in Claude's DCR client rather than something specific to Magnific.

Expected behavior

Subject: MCP OAuth Dynamic Client Registration fails for remote HTTP connector (magnific.com) — ref ofid_027bfef7df1ab3f5

Description:

When trying to authenticate the Magnific MCP connector (https://mcp.magnific.com, HTTP transport) added via claude mcp add, the OAuth flow fails immediately with the error:

"Impossible de s'inscrire auprès du service de connexion de Magnific. Vous pouvez réessayer ou ajouter un identifiant client OAuth dans les paramètres du connecteur."
("Couldn't register with the sign-in service. You can retry or add an OAuth client ID in the connector settings.")

Reference ID: ofid_027bfef7df1ab3f5

Steps to reproduce:

claude mcp add --transport http magnific https://mcp.magnific.com
Start an interactive session, run /mcp
Select magnific to authenticate
Error appears before the browser OAuth screen even loads
Diagnostic already performed:
I verified Magnific's server-side OAuth metadata and registration endpoint directly:

GET https://mcp.magnific.com/.well-known/oauth-authorization-server → 200 OK, correctly advertises registration_endpoint: https://auth.magnific.com/realms/mcp/clients-registrations/openid-connect
POST directly to that registration_endpoint with a minimal DCR payload (redirect_uris, client_name) → 201 Created, so Magnific's Dynamic Client Registration endpoint works correctly when called directly.
This suggests the failure is happening in Claude's own OAuth/DCR client logic (malformed registration request, header issue, redirect handling, etc.), not on Magnific's auth server.

Environment:

macOS (Darwin), hostname lmwr-lap043
Claude Code CLI, connector added via claude mcp add --transport http
Note: I noticed similar error formats (ofid_...) reported against unrelated MCP servers in anthropics/claude-ai-mcp (issue #457) and anthropics/claude-code (issues #11585, #26917, #36307), suggesting this may be a broader bug in Claude's DCR client rather than something specific to Magnific.

Additional context

Subject: MCP OAuth Dynamic Client Registration fails for remote HTTP connector (magnific.com) — ref ofid_027bfef7df1ab3f5

Description:

When trying to authenticate the Magnific MCP connector (https://mcp.magnific.com, HTTP transport) added via claude mcp add, the OAuth flow fails immediately with the error:

"Impossible de s'inscrire auprès du service de connexion de Magnific. Vous pouvez réessayer ou ajouter un identifiant client OAuth dans les paramètres du connecteur."
("Couldn't register with the sign-in service. You can retry or add an OAuth client ID in the connector settings.")

Reference ID: ofid_027bfef7df1ab3f5

Steps to reproduce:

claude mcp add --transport http magnific https://mcp.magnific.com
Start an interactive session, run /mcp
Select magnific to authenticate
Error appears before the browser OAuth screen even loads
Diagnostic already performed:
I verified Magnific's server-side OAuth metadata and registration endpoint directly:

GET https://mcp.magnific.com/.well-known/oauth-authorization-server → 200 OK, correctly advertises registration_endpoint: https://auth.magnific.com/realms/mcp/clients-registrations/openid-connect
POST directly to that registration_endpoint with a minimal DCR payload (redirect_uris, client_name) → 201 Created, so Magnific's Dynamic Client Registration endpoint works correctly when called directly.
This suggests the failure is happening in Claude's own OAuth/DCR client logic (malformed registration request, header issue, redirect handling, etc.), not on Magnific's auth server.

Environment:

macOS (Darwin), hostname lmwr-lap043
Claude Code CLI, connector added via claude mcp add --transport http
Note: I noticed similar error formats (ofid_...) reported against unrelated MCP servers in anthropics/claude-ai-mcp (issue #457) and anthropics/claude-code (issues #11585, #26917, #36307), suggesting this may be a broader bug in Claude's DCR client rather than something specific to Magnific.

[rpelevin]

I would split this at the OAuth phase boundary before treating it as a generic connector failure.

The useful invariant is that the client should emit a distinct result for each setup step:

1. authorization-server metadata fetched and parsed;
2. dynamic client registration request constructed;
3. registration response accepted or rejected with the provider response body/status preserved;
4. browser authorization handoff started only after a valid client is registered;
5. initialize sent only after the selected credential path has produced a bearer token.

In this case the important signal is that a direct minimal registration request succeeds, while the connector flow fails before the browser OAuth screen loads. That points to the registration request shape, headers, redirect URI set, or client metadata sent by the Claude-side DCR client, not to the MCP tool server itself.

A narrow regression would stub a registration endpoint that returns 201 for a minimal RFC-aligned payload, then assert that the connector client sends the same phase-correct DCR request before showing the authorize screen. On failure, the client should surface a typed dynamic_client_registration_failed state with the HTTP status/body or local construction error attached, instead of collapsing it into a generic sign-in-service message.

[localden]

Thank you for taking the time to report this.

For ofid_027bfef7df1ab3f5 (Jul 6 12:11 UTC): the connector URL points at one host, but the Protected Resource Metadata that host serves declares a resource on a different host. Per RFC 9728 Section 3.3, when the metadata's resource does not identify the server we asked about, the client must not use that document, so discovery is rejected. The fallback registration attempt then hits a /register path that does not exist on the connector host and returns 404, which surfaces as the registration failure you saw.

The fix is on the server publisher's side: the Protected Resource Metadata's resource field must match the connector's own origin. Alternatively the connector URL should point at the host whose metadata is correct.

Closing as a server-metadata configuration issue; please reopen with a fresh reference ID if the failure persists after the publisher corrects the metadata.