MCP Deprecated Dynamic Client Registration. What Should Your Bot Use Now?

What actually changed on July 28, 2026

The July 2026 MCP authorization revision deprecates OAuth Dynamic Client Registration (RFC 7591) in favor of Client ID Metadata Documents. DCR remains available for backward compatibility when an authorization server supports it; it was never the only way to obtain a client ID. A client might already have credentials registered out of band, for example through an administrator's configuration screen.

This guidance applies to MCP's HTTP-based OAuth authorization flow. Authorization is optional in MCP, and the specification says STDIO transports should retrieve credentials from the environment rather than use this HTTP OAuth flow. The registration choice matters when the client needs an OAuth client ID for a protected HTTP MCP server.

The current client-registration document names four possible steps for clients that support all options. It says they SHOULD use available pre-registered information first, CIMD when the authorization server advertises support second, DCR when a registration endpoint is advertised third, and a prompt for user-entered client information if none of those works. SHOULD is a strong recommendation in the specification, not an unconditional MUST to attempt every mechanism.

Sources: Authorization - Model Context Protocol, Client Registration - Model Context Protocol, modelcontextprotocol/docs/specification/2026-07-28/changelog.mdx at main · modelcontextprotocol/modelcontextprotocol.

Why DCR was the wrong default

DCR asks an authorization server to create a client registration and return a client ID, potentially for software it has never met. A client may need separate registrations at multiple issuers, and an open registration endpoint needs abuse controls. Those operational costs explain why a self-hosted metadata document is attractive, but they do not mean every DCR deployment is insecure or that all servers permit anonymous registration.

With CIMD, the client hosts a JSON metadata document at an HTTPS URL that has a path. The document's client_id must exactly match that URL and include client_name and redirect_uris. An authorization server that supports CIMD can fetch and validate the document, including matching requested redirect URIs; it may cache the metadata according to HTTP headers. The URL-form client ID can be portable across issuers because the metadata is hosted by the client. It is an identifier and metadata location, not a portable client secret, registration record, access token or proof that the user authorized the client.

Sources: Client Registration - Model Context Protocol.

Worked example: connecting a personal bot to a new MCP server

Illustrative case: a personal bot connects to a protected HTTP MCP project-tracker server through an OAuth-capable client. First the client discovers the server's authorization server and validates that server's metadata. The bot's app may already hold a pre-registered client ID for that exact issuer. If so, it uses the stored information without making a new client-registration request; the later OAuth authorization exchange still involves network requests and user consent as applicable.

If no such registration exists, the client checks authorization-server metadata for client_id_metadata_document_supported. If supported and the client has published its HTTPS metadata document, it can use that document URL as its client_id. The authorization server resolves and validates the document under its own policy. There is no DCR POST in this path, but the normal authorization and token exchange still follows.

If CIMD is unavailable and the authorization server advertises a registration_endpoint, a client supporting DCR can register there. It must specify an appropriate application_type during DCR; a native desktop client and a remote web application may need different redirect-URI constraints. Persisted DCR credentials must be keyed to the issuing authorization server's issuer. If that issuer changes, do not reuse those credentials with the new server.

If none of those mechanisms is available, the registration guidance includes a fourth step: ask the user to supply client information, such as credentials arranged with the server operator. That is a real fallback, not a promise that every server can be connected automatically. The client should explain which capability is missing instead of repeatedly trying a registration endpoint the server does not advertise.

After obtaining a client ID, the client still has to perform the OAuth flow correctly. In the current authorization specification, it records the expected issuer from validated metadata and compares a present iss authorization-response value with that issuer before sending the code to a token endpoint. If metadata advertises support for iss but the response omits it, the client rejects the response. This issuer check is separate from the DCR-only application_type requirement.

Sources: Client Registration - Model Context Protocol, modelcontextprotocol/docs/specification/2026-07-28/changelog.mdx at main · modelcontextprotocol/modelcontextprotocol.

What happens if you do nothing

A DCR-only client can continue working with an authorization server that still offers a registration endpoint. Deprecation does not instantly disable existing installations. The protocol's feature-lifecycle policy gives deprecated features a minimum window before removal from the specification, but that does not require every independently operated authorization server to expose optional DCR forever.

A client without CIMD, a matching pre-registration, or usable DCR cannot automatically obtain a client ID from a CIMD-only authorization server. It should offer the documented user-entry route if supported and otherwise report the missing registration mechanism clearly. Check the server metadata rather than assuming a failed OAuth login is a bad password or bad token.

For a small team, the migration is to make the client capable of hosting and using a valid CIMD document, test redirect-URI and issuer validation, and retain DCR only where a server still advertises it. Do not confuse portability of the CIMD URL with portability of DCR credentials or authorization grants; those remain tied to the issuer and the user's authorization.

Sources: Client Registration - Model Context Protocol, modelcontextprotocol/docs/specification/2026-07-28/changelog.mdx at main · modelcontextprotocol/modelcontextprotocol.

The decision

If you choose an MCP client for HTTP OAuth connections, check which registration mechanisms it actually implements. The recommended order for a client that supports all four is existing pre-registration, advertised CIMD, advertised DCR, then user-provided client information. Confirm that it keeps stored issuer-bound credentials separate and surfaces a useful error when no mechanism is available.

If you operate an authorization server, advertise client_id_metadata_document_supported only when it can fetch and validate documents and redirect URIs according to the specification. You may retain DCR for existing clients while they migrate. Correction, 2026-10-07: an earlier version called the recommended order mandatory, omitted the user-entry fallback, described the CIMD URL as a portable credential, and applied a DCR-only application_type rule to every registration path. Those claims have been corrected here.

Sources: Client Registration - Model Context Protocol.