Published connector attempts DCR despite "Anthropic-held client credentials" mode

### MCP server URL

https://api.orphex.co/api/interaction-gateway/v1/mcp

### Where does the issue occur?

When pressing the Connect button

### Transport used

streamable-http

### Client registration type

Static

### SSE only: Does your server return the expected status code for POST requests?

Not applicable (my server does not use SSE)

### When did you last reproduce this?

03:20 Thursday, August 13, 2026 (GMT+3)

### Browser and OS

_No response_

### Describe the issue

Connecting to our published connector fails at the client registration step with:
"Couldn't register with Orphex's sign-in service. You can try again, or add
an OAuth Client ID in the connector settings."
Error IDs: ofid_1dd418e236122242,

### Issue details

```shell
Connecting to our published connector fails at the client registration step with:

"Couldn't register with Orphex's sign-in service. You can try again, or add
an OAuth Client ID in the connector settings."

Error IDs: ofid_1dd418e236122242,

## Our setup

- Authorization server: Auth0 (EU), issuer https://auth.orphex.co/
- Dynamic Client Registration is intentionally DISABLED at the tenant level and
will remain disabled. This is a frozen architectural decision on our side, not
a misconfiguration we can relax.
- We use static pre-registered clients, one per MCP client.
- Our resource server enforces a static client_id allowlist at runtime: any
client_id outside it is rejected with 401 before anything else runs.
- Flow: Authorization Code + PKCE S256, rotating refresh tokens, offline_access.
- Required scope: interaction:read

In the connector submission form we selected "OAuth 2.0 with Anthropic-held
client credentials" and supplied our static Client ID.

## Observed behavior: the custom connector path works, the published one does not

This is the key data point. Adding the exact same server URL as a CUSTOM
connector succeeds completely — no error at any step:

- The OAuth flow completes: authorize, callback, token exchange, refresh.
- Tools are listed and callable.
- No registration error appears, because that path lets us supply the OAuth
Client ID directly, so dynamic client registration is never attempted.

Connecting to the PUBLISHED connector, same server, same Auth0 tenant, same
user, fails at registration with the error above.

Because the custom path succeeds end to end, the following are all demonstrably
correct on our side and can be ruled out as causes:

- the MCP endpoint, its transport, and the protocol handshake
- the Auth0 tenant configuration, allowed callback URLs, and PKCE setup
- the pre-registered static client_id and its grants
- the scopes, the token audience, and refresh token rotation
- our resource server's token verification and client allowlist

The only variable that differs between a successful connection and a failing one
is which connector path is used. That points at how the published connector
resolves its OAuth client, not at our sign-in service — even though the error
message attributes the failure to us.

Additionally, the published connector's settings expose no field to view or edit
the OAuth Client ID, so we cannot apply the fix the error message itself
suggests ("add an OAuth Client ID in the connector settings").

## A note that may be relevant to diagnosis

Auth0 advertises `registration_endpoint` in its authorization server metadata
unconditionally, even when tenant DCR is disabled. Its presence in discovery is
therefore not a reliable signal that DCR is available — a client that probes
discovery for a registration path will always appear to find one, and will fail
at the actual registration call. If the connector flow decides between static
credentials and DCR based on discovery metadata, that would explain this.

## We are not certain we picked the right auth mode

We would like confirmation. Our reasoning for "Anthropic-held client
credentials":

- DCR: ruled out, disabled on our tenant by design.
- Client ID Metadata Document: ruled out, that implies a URL-shaped client_id,
which our static allowlist rejects.
- Custom URL or credentials at connection time: ruled out, we are a single fixed
endpoint on one shared tenant; users do not bring their own URL or credentials.
- No authentication: ruled out, the server requires a bearer token to list or
call any tool.

That leaves the Anthropic-held static client mode. If that is wrong, please tell
us which mode we should have selected and we will resubmit.

Our Auth0 application is registered as a Regular Web Application, i.e. a
confidential client with a client_secret, which is what the phrase "a static
client_id (and secret if needed)" implies this mode expects. So both halves of
the credential pair exist on our side and are ready to be held by Anthropic.

Given that, our question is whether they were ever actually stored. Can you
confirm what credentials, if any, are currently registered for this connector?
If none are stored because the coordination email was never processed, that
alone would explain the fallback to dynamic client registration, and we would
just need the credentials loaded.

## Coordination attempt

The submission form states this mode "needs coordination — email
mcp-review@anthropic.com with details before we can list your server." We sent
that email and have not received a response. Filing here
because the coordination step appears to be blocking the listing. Happy to
provide the client_id and tenant details privately.
```

### Expected behavior

The published connector should authenticate using the static client_id that
Anthropic holds for it, as configured by the "OAuth 2.0 with Anthropic-held
client credentials" mode, without attempting RFC 7591 dynamic client
registration against our authorization server.

Failing that, either:

- the connector settings UI should expose the OAuth Client ID field so server
developers can inspect and correct it themselves (the error message tells us
to "add an OAuth Client ID in the connector settings", but no such field is
present for a published connector); or
- the error should state that the Anthropic-side credential coordination is
incomplete, rather than surfacing as a generic registration failure that
points at our sign-in service.

### Logs from your server

```shell

```

### Additional context

_No response_