Bug: Connection Info shows DCR even when OAuth client registration uses CIMD

[randy-s-shin]

Which version line?

v2 — current (@modelcontextprotocol/inspector@latest)

Which client?

Web

Inspector version

2.5.0

Node version

v24.15.0

Operating system (and browser, for the web client)

Windows 11, Chrome 152.0.7977.65

Transport

Streamable HTTP

MCP server under inspection

Server: private Streamable HTTP MCP server (FastMCP 4.0.1 / python mcp 2.1.1), https:///mcp
Protocol era: modern (2026-07-28)
OAuth: yes
the AS metadata advertises "client_id_metadata_document_supported": true
and there is no pre-registered client. The flow never calls /oauth/register (verified in the Network tab).

Steps to reproduce

1. Run npx @modelcontextprotocol/inspector@2.5.0 and open the web client.
2. Client Settings → OAuth → enable "Use CIMD" and set the CIMD metadata URL
   to an HTTPS URL that serves a valid client-metadata JSON
   (client_id == that URL, redirect_uris includes http://127.0.0.1:6274/oauth/callback).
3. Add a Streamable HTTP server whose AS metadata has
   client_id_metadata_document_supported: true (no pre-registered client id in Server Settings).
4. Connect, complete login/consent, return to the Inspector (status: Connected).
5. Open Connection Info → OAuth Details (or the client-registration badge).

Expected behavior

The registration kind is shown as CIMD (e.g. "CIMD (URL client_id)"), because the
client_id used for /oauth/authorize and /oauth/token is the metadata-document URL and
no dynamic registration request was made.

Actual behavior

Client ID shows the metadata-document URL (correct), but the registration kind is
labeled "Dynamic (DCR)". The Network tab confirms there was no POST /oauth/register.
Reproduces after "Clear OAuth state and disconnect" and after restarting the Inspector
(~/.mcp-inspector/storage/client.json / mcp.json cleared).

Logs, errors, or screenshots

Make sure the screenshot shows that no /register request was made

In OAuth Details, the Client ID is an HTTPS URL ending in .json.

Already prototyped a fix?

No, I haven’t prototyped a fix yet.

I only traced the relevant Inspector and MCP TypeScript SDK code paths to understand why CIMD is reported as DCR in Connection Info.

What I verified:

• The OAuth flow uses a HTTPS Client Metadata Document URL as the client_id.
• No POST /register request is made, so DCR is not actually being used.
• Deleting ~/.mcp-inspector/storage/oauth.json and reconnecting does not change the behavior.
• Connection Info still reports the registration method as DCR.
• In the Inspector source, saveClientInformation() appears to default registrationKind to "dcr" when it is not explicitly provided.

I have not made or tested a code change, so I don’t have an exact implementation prompt or before/after screenshots.

Before you submit

• I searched existing issues and this is not a duplicate.
• This is not a security vulnerability report (those go through the private advisory process).

[Jermaine-Anugwom]

I reproduced this on the current v2/main branch.

The CIMD registration is saved correctly before authorization. The label changes later, when the SDK calls saveClientInformation(clientInfo, { issuer }) to bind that registration to the authorization server. BaseOAuthClientProvider.saveClientInformation currently treats any save without an explicit registrationKind as DCR, so that issuer-binding write overwrites the earlier cimd provenance.

I prototyped a narrow fix locally. It preserves cimd only when the stored registration kind is CIMD and the stored client_id matches the client ID being promoted. A different or newly registered client still defaults to dcr, so stale CIMD state cannot leak onto a later DCR registration.

Before the fix, the new regression test failed with expected registrationKind: "cimd" and received: "dcr". After the fix:

• Provider unit suite: 37/37 passed
• OAuth end-to-end suite: 34/34 passed across SSE and Streamable HTTP
• Full web unit and integration coverage: 7,410 tests passed
• Storybook interaction suite: 514 tests passed across 122 files
• CLI, TUI, launcher, build, lint, formatting, type checks, dependency lockstep, coverage gates, and Chromium/Firefox browser smokes passed

The OAuth E2E assertion now verifies that a completed CIMD connection still reports the metadata URL as its client ID and registrationKind: "cimd" through getOAuthState().

Exact implementation prompt for the maintainer workflow:

On v2/main, fix #2242 without changing the Connection Info UI copy. In BaseOAuthClientProvider.saveClientInformation, distinguish an SDK issuer-binding save from a new DCR registration. If the options explicitly contain registrationKind, preserve it. Otherwise, load the existing dynamic client information and registration kind for the same server and issuer. Preserve cimd only when the stored kind is cimd and its stored client_id equals the incoming client_id; otherwise use dcr. Add provider unit tests covering same-ID CIMD issuer binding and mismatched-ID DCR fallback. Extend the InspectorClient CIMD OAuth E2E test to assert that getOAuthState().client contains the metadata URL and registrationKind: "cimd" after connection. Run formatting, focused provider and OAuth E2E tests, the full web unit/integration coverage suite, Storybook interactions, builds, and browser smokes.

No UI layout or copy changes are needed; the issue is the stored registration provenance.