[Feature Request] Support MCP servers with Client ID Metadata Documents (CIMD) OAuth authentication

https://modelcontextprotocol.io/specification/draft/basic/authorization#overview given "Authorization servers and MCP clients SHOULD support OAuth Client ID Metadata Documents" I'd be very surprised that Boris et al wouldn't have CIMD support by now. But I'm getting "does not support dynamic client registration" when testing with a CIMD only MCP server so 🤷

EDIT: it turns out it might make sense for Claude Code to not support CIMD right now https://workos.com/blog/dynamic-client-registration-dcr-mcp-oauth 'CIMD only works if a client can host a public, stable HTTPS metadata document. Many MCP clients can’t. Think desktop apps, CLI tools, IDE plugins, or internal agents running on a developer laptop. These often use localhost or custom scheme redirects and don’t have a domain they control for hosting metadata.'

A private key/certificate compiled in the client would be very hard to reverse-engineer.

Please do not do this. It would not be hard.

It does make sense for Claude Code to implement this. DCR is problematic to begin with from both security and polluting the DB perspective.

Desktop apps are currently expected to have their metadata document hosted on their backend website, not by themselves. With the redirect_uri using localhost where the spec says that for localhost, the port part is ignored to allow for that, or a custom URI schema registered at the operating system, or a public webpage that will do an extra bounce to pass the actual credentials to the desktop app, by copy pasting, or fetching a localhost URL by itself, etc.

For example, VS Code Copilot uses https://vscode.dev/oauth/client-metadata.json as CIMD and it works just fine. The trick is "application_type": "native" which allows special provisions for localhost and custom schemes in redirect_uris

Agree with @segevfiner, Anthropic should host the CIMD metadata on a website, not on local host. As for the redirect URI necessary for completing the authorization code flow, that can be local, and the port is specified in the CIMD metadata document.

Agree with @segevfiner, Anthropic should host the CIMD metadata on a website, not on local host. As for the redirect URI necessary for completing the authorization code flow, that can be local, and the port is specified in the CIMD metadata document.

And further with "application_type": "native" there are special provisions in the spec to allow for localhost and custom schemas, and furthermore, to ignore the port when the host is localhost. Of course, that assumes a provider that has implemented this provisoon properly.

I think there may be a narrower, actionable interoperability bug here in addition to the broader CIMD support request raised in this issue. This issue is currently framed as a feature request to support MCP servers using CIMD OAuth authentication.

When Claude Code uses loopback redirect URIs such as http://127.0.0.1 or http://localhost, omitting application_type can create problems across authorization servers. Under RFC 7591, omitting application_type defaults the client to "web". Under RFC 8252, loopback redirect URIs are described for native apps, and RFC 8252 also says that redirect URI alone is not enough to distinguish native from web clients, so client type needs to be recorded during registration.

That means the issue may not just be "missing CIMD support" in the abstract. It may also be that Claude Code should explicitly record its intended client type when using loopback redirect URIs, instead of relying on the RFC 7591 default.

There are at least a couple of Claude Code issues that seem consistent with this interoperability angle as well (e.g. https://github.com/anthropics/claude-code/issues/37747).

I opened a separate bug specifically for the application_type point, since it seems actionable even apart from broader CIMD support:

• https://github.com/anthropics/claude-code/issues/44378

There is also related upstream standards discussion here:

• https://github.com/oauth-wg/draft-ietf-oauth-client-id-metadata-document/issues/75

I see that the claude code docs currently say:

Claude Code also supports servers that use a Client ID Metadata Document (CIMD) instead of Dynamic Client Registration, and discovers these automatically.

And I see client metadata for client_name=Claude Code hosted here: https://claude.ai/oauth/claude-code-client-metadata

Thanks for the report. Client ID Metadata Document (CIMD) discovery is now supported and documented at code.claude.com/docs/en/mcp. Claude Code discovers CIMD-supporting servers automatically. Closing as fixed.