What is Dynamic Client Registration?

DCR exists in MCP because the usual OAuth assumption — that client and server have a prior relationship — does not hold. An MCP client like Claude Code or Cursor cannot know every remote MCP server a user might add, and asking users to manually register an OAuth client for each one would be prohibitive. With DCR, the client POSTs its metadata to the authorisation server's registration endpoint and receives credentials on the spot.

In practice DCR causes real operational friction:

• Every client installation can create a fresh client record, so authorisation servers accumulate unbounded, anonymous registrations.
• Registration metadata is self-asserted, leaving server operators little basis for trust decisions or allowlisting.
• Many enterprise identity providers disable open registration endpoints outright, breaking the automated flow and forcing manual fallbacks.

The spec has shifted accordingly. The 2025-06-18 revision said clients and authorisation servers SHOULD support DCR; the current 2025-11-25 revision demotes it to MAY, retained for backwards compatibility. The preferred mechanism is now Client ID Metadata Documents (CIMD), where the client's client_id is an HTTPS URL pointing at a hosted metadata JSON document. Clients are told to prefer pre-registered credentials, then CIMD, then DCR, then prompting the user — see MCP Authorization for the full flow.

PolicyLayer reduces a team's exposure to per-server registration mechanics: clients authenticate to the PolicyLayer gateway with per-person scoped tokens, while the gateway holds the relationship with each registered upstream server. Which servers are approved, and who may reach them, is decided centrally rather than by each authorisation server's registration policy.