Skip to content

Franz Franz

goFranz // personal journal all writing
Opinion · mcp

CIMD adoption three months in - Mistral is the one without it

Which AI clients identify themselves with Client ID Metadata Documents, which still need Dynamic Client Registration, and what that means if you run an MCP authorization server.

By Franz Geffke 27 Oct 2026 11 min read #mcp #oauth2 #oidc #identity

In August I wrote about MCP deprecating DCR in favour of CIMD, and about dropping Dynamic Client Registration from Forseti entirely. Since then the question I get most is a practical one: if my authorization server only speaks CIMD, who can still connect?

So I went through the clients from the big vendors, and checked each against the vendor’s own documentation, the source code where it’s public, and the metadata document the vendor actually hosts.

TL;DR: Anthropic, OpenAI, Google and Microsoft all publish a Client ID Metadata Document for at least one of their products, and most of their flagship clients prefer it over DCR. Mistral is the exception. Vibe (formerly Le Chat) registers through DCR, and I couldn’t find a metadata document Mistral hosts for any of its products.

A quick refresher

With DCR (RFC 7591), the client POSTs its metadata to your registration_endpoint and you mint a client_id. With CIMD, the client_id is an HTTPS URL; your authorization server fetches the JSON document behind it and validates the redirect URI against it. The 2026-07-28 spec gives clients a priority order: pre-registered credentials first, then CIMD if the server advertises client_id_metadata_document_supported, then DCR if there’s a registration_endpoint, and finally asking the user.

That order matters for reading the table below. “Supports CIMD” almost always means “uses CIMD when your server advertises it, falls back to DCR when it doesn’t”.

Who supports what

As of October 27, 2026:

Vendor Client CIMD DCR Evidence
Anthropic claude.ai, Desktop, mobile, Cowork yes, preferred fallback official docs, hosted document
Anthropic Claude Code yes, preferred fallback official docs, hosted document
OpenAI ChatGPT apps and connectors yes, preferred fallback, or builder’s choice official docs, hosted document
OpenAI Codex yes, preferred fallback official docs, source code, hosted document
Google Antigravity yes unknown hosted document
Google Gemini app (custom apps) observed, undocumented yes official help page, integrator reports
Google Gemini CLI no yes source code
Google Gemini Enterprise (Business) no no official docs: you register the client
Microsoft VS Code (and Copilot in it) yes, since 1.106 fallback release notes, source code, hosted document
Microsoft Copilot CLI yes, since 1.0.83 (one open report) fallback release notes, hosted document
Microsoft Copilot Studio no yes official docs
Mistral Vibe Work and Chat (formerly Le Chat) no yes official docs, integrator tests
Mistral Vibe Code CLI only with your own document URL yes, default source code
Zed Zed yes, preferred fallback source code, hosted document
Anysphere Cursor no (not announced) yes staff statements on the forum

Anthropic

Claude’s authentication docs list oauth_cimd and oauth_dcr as both “supported by default”, and the custom connector dialog offers “Use Claude’s published identity” as the recommended option. The same authentication infrastructure backs claude.ai, Desktop, mobile, Claude Code and Cowork, but Claude Code identifies itself with its own document.

The catch is a stricter condition than the spec’s: Claude only picks CIMD when your metadata advertises client_id_metadata_document_supported: true and lists none in token_endpoint_auth_methods_supported, because its CIMD client is public at the token endpoint. Miss either and it quietly falls back to DCR. Claude Code also needs loopback redirects matched without the port, for localhost as well as 127.0.0.1.

Two documents:

OpenAI

OpenAI’s plugin auth docs cover both ChatGPT and Codex, and are the most explicit of the lot: “Use Client ID Metadata Documents (CIMD) as the preferred client registration method when your authorization server supports it and the plugin builder chooses it”, and “DCR is still supported.” ChatGPT prioritises CIMD when it’s available, but the plugin builder can choose DCR when the server offers both.

ChatGPT is also the one client here that isn’t purely public. Its document lists token_endpoint_auth_methods_supported: ["none", "private_key_jwt"], prefers private_key_jwt, and publishes a jwks_uri. If your server reads the plural field, accept any method in the intersection. If it only reads the singular legacy token_endpoint_auth_method, you’ll see private_key_jwt and need to verify the client assertion against that JWKS. For servers that don’t meet OpenAI’s issuer identification requirements, ChatGPT uses a per-connection https://chatgpt.com/oauth/{callback_id}/client.json instead of the stable URL.

Codex is a native client with a loopback redirect and its own document, public only (none). Its source in codex-rs/rmcp-client picks CIMD when the server advertises it, includes none, and the callback is a supported loopback URL; otherwise it falls back to DCR.

Google

Google has the most products here, and they don’t agree with each other.

Antigravity hosts a document at https://antigravity.google/oauth/client-metadata.json, public client, redirecting to https://antigravity.google/oauth-callback. The client isn’t open source, so I can’t show the selection logic; a server operator on the Cursor forum thread below lists it among the clients that have rolled out CIMD.

The Gemini app has an official help page for custom apps: add an MCP server by URL, and “If the server doesn’t support Dynamic Client Registration, next to ‘Advanced features,’ click Show more, then enter your credentials.” It’s limited to personal accounts, users 18 and over in the US, in English. The page doesn’t mention CIMD. A Home Assistant issue from July shows Gemini presenting a CIMD client_id of the form https://accountlinking.google.com/clientidmetadata/user_bound_provider/user_bound_custom-mcp-... to a server that advertised CIMD; against servers that don’t, integrators see it hit /oauth/register. That’s consistent with the spec’s order, but the CIMD half is what integrators observed, not something Google documents.

One detail from the Home Assistant report is worth knowing either way: Gemini’s redirect URI sits on a different host from its client_id. Claude’s and ChatGPT’s are same-origin, so a server that skips fetching the document and only accepts same-origin redirects works for them by accident and fails for Gemini.

Gemini CLI’s MCP OAuth code (checked at the October 26 commit) has no CIMD support; it uses a configured clientId or discovers a registration_endpoint and does DCR. The CIMD feature request was closed in May with “we don’t have immediate plans to address this specific issue”. Gemini Enterprise (Business edition) wants you to register it as an OAuth client with your identity provider, with the redirect https://vertexaisearch.cloud.google.com/oauth-redirect.

Microsoft

VS Code shipped CIMD in 1.106 (November 2025), well before the deprecation, and hosts its document at https://vscode.dev/oauth/client-metadata.json. The logic is short: no stored client ID and the server advertises CIMD, so it uses that URL.

GitHub’s Copilot CLI added CIMD in v1.0.83 (September 4), with a document at https://github.com/copilot/cli/client-metadata.json. Granted, there’s an open report from October 19 that 1.0.100 still falls back to DCR against a server that advertises CIMD, so test it before you rely on it.

Copilot Studio offers “Dynamic discovery”, “Dynamic” and “Manual”, and the first two are both DCR. No CIMD there.

Mistral

Le Chat became Vibe in August, with Work, Code and Chat modes. Its MCP connector docs list exactly one OAuth option: “OAuth 2.1 (with dynamic client registration)”. There’s no mention of CIMD.

Integrators testing in October agree. The Sulu MCP bundle tested five clients against one installation: “Claude.ai, Claude Code, ChatGPT and Codex identify themselves by CIMD, and Le Chat registers through DCR.” Integrators report the callback as https://callback.mistral.ai/v1/integrations_auth/oauth2_callback, so add it to any redirect allowlist on your registration endpoint. Mistral doesn’t document it.

If your server has no registration endpoint, there’s still a way in, though not the obvious one. The Studio Connectors API accepts an auth_data object with an OAuth client_id and client_secret, and connectors set up there are usable in Vibe and Studio. Sulu’s guide also tells Le Chat users to “leave any client ID and secret fields empty”, which suggests the dialog has them. Either way, you create the client by hand.

One more practical gotcha, from a Margince issue: their registration endpoint refused unknown metadata fields, every Le Chat attempt ended at POST /oauth/register with a 400, and Le Chat showed a generic internal error. RFC 7591 is clear that the server MUST ignore metadata it doesn’t understand, so be lenient there.

The Vibe Code CLI is a bit further along. It’s built on the official MCP Python SDK and accepts either a pre-registered client_id or a client_metadata_url in its config, so CIMD works if you host a document yourself. By default it does DCR, and I couldn’t find a document Mistral hosts for it.

So among Anthropic, OpenAI, Google, Microsoft and Mistral, Mistral is the only one with no product that identifies itself with a document the vendor publishes. Google and Microsoft have DCR-only products too (Gemini CLI, Copilot Studio), but each also ships at least one client that uses CIMD.

The rest

Zed prefers CIMD with a DCR fallback, using https://zed.dev/oauth/client-metadata.json.

Cursor is DCR-only as far as anything official goes. Staff on the forum thread said on September 22 that CIMD is “still on our radar” with no timeline. There’s a live document at https://cursor.com/oauth/mcp-client.json, and one server operator reported requests arriving with it on October 20, so it may be rolling out. Until Cursor says so, I’d treat it as DCR.

What this means if you run an authorization server

If you advertise CIMD and keep DCR, every client in the table can connect without anyone creating a client by hand (Gemini Enterprise aside, which always wants one). Put none in token_endpoint_auth_methods_supported or Claude won’t use CIMD; accept private_key_jwt if you want ChatGPT’s preferred method; actually fetch the document and validate the redirect against it, or Gemini breaks.

If you drop DCR, as I did in Forseti, then Vibe, the Gemini app on servers without CIMD, Gemini CLI, Copilot Studio and Cursor (for now) all need a client someone creates by hand. That’s a support ticket per customer. I’m fine with that for my own deployments, where the users are on Claude and ChatGPT. If you serve a European audience that’s standardising on Mistral, you probably aren’t, and keeping DCR for the remaining deprecation window is the pragmatic choice.

Take the rows marked “observed” with a grain of salt, and expect this table to be out of date within a couple of months. I’ll add a dated update when Mistral or Cursor ship.

Sources

Specification:

Anthropic:

OpenAI:

Google:

Microsoft:

Mistral:

Others:

Related

Subscribe via Atom (RSS)

Contact the author

mail@gofranz.com · public key

on Mastodon

Published on