Dynamic Client Registration (DCR) in MCP: What it is, why it exists, and when to still use it

The Model Context Protocol (MCP) enhances client-server interactions, necessitating a client identity for token requests, traditionally managed by Dynamic Client Registration (DCR). DCR allows clients to self-register programmatically, enabling seamless connectivity in MCP's many-to-many ecosystem by eliminating pre-registration. However, DCR poses security risks like client impersonation and redirect URI vulnerabilities, leading to operational burdens as servers accumulate dynamic client records. To address these challenges, Client ID Metadata Documents (CIMD) were introduced, shifting client identification responsibility from servers to clients by using stable HTTPS URLs, reducing server-side state management, and providing better trust signals. CIMD has become the preferred method for MCP client registration due to its scalability and reduced maintenance, though DCR remains relevant for local clients lacking stable HTTPS origins or requiring enterprise policy control. Despite its initial prominence, DCR's limitations in a large-scale ecosystem necessitated the evolution to CIMD, which better aligns with MCP's dynamic and web-native client landscape.