Announcing CIMD Support in Descope Agentic Identity Hub

We’re excited to announce that Client ID Metadata Documents (CIMD) support is now generally available as a part of the Agentic Identity Hub! Descope now supports both DCR and CIMD, both of which can be enabled simultaneously to address multiple registration scenarios and client types.

CIMD is the latest solution to the client registration challenges of the Model Context Protocol (MCP), providing a standardized approach for agent builders to provide more context about the agent as it establishes a connection with an MCP server.

As organizations continue to embrace AI and discover new ways to enable agents in their organizations, MCP gives agents a standards-based way to interface with external tools, resources, and prompts. The ability to support all three of the MCP auth spec’s possible client registration methods ensures adoption can be both seamless and secure. 

The MCP client registration challenge

MCP strongly defines three key components:

1. The MCP client: The main broker of a connection with an MCP server. MCP clients are instantiated by MCP Host applications, such as Claude, Cursor, or VS Code. In general, it’s easiest to think about an MCP Client as “the agent”.

2. The MCP server: A program that exposes tools, resources, and prompts to an MCP client. For example, you can build an MCP server that gives an agent the ability to interact with your APIs by defining tools for the agent to use.

3. The Authorization Server (AS): The “security gatekeeper” between the MCP client and server. When an MCP client makes an unauthenticated request to an MCP server, the MCP server gives the client instructions on how to authenticate with the Authorization Server. The Descope Agentic Identity Hub acts as the Authorization Server in the MCP handshake.

Within the Authorization Server, an MCP client must register itself to receive credentials to connect to the MCP server. Prior to CIMD being ratified in the MCP authorization spec, there were two methods to register an MCP client within the Authorization Server. 

The first method is pre-registration of an MCP client. This method involves the user creating a Client ID and potentially Client Credentials within an Authorization Server, then manually configuring these values within their MCP Client. 

The second method is Dynamic Client Registration (DCR). This method requires the MCP server to host an open /register endpoint, and during Protected Resource Metadata (PRM) discovery, the MCP client can learn to register itself. 

For early MCP adoption, these methods defined the core authorization process. Unfortunately, these solutions left a few gaps:

• Pre-registered credentials are static, which can be a security risk

• New clients created via DCR often have very little metadata that can be verified, usually only a redirect_uri and IP address

• DCR creates a new Client ID and Client Secret every time, which leads to huge lists of potentially the same agent in the Authorization Server 

• Hosting a /register endpoint opened up some security risks without hardening. 

Previously, considerable expertise and additional infrastructure was needed to harden DCR rollouts and handle these risks. Now, CIMD can tackle these scenarios, while DCR can be used in controlled environments.

Client ID Metadata Documents

The latest update of the MCP auth spec, released on November 25th, 2025, introduces Client ID Metadata Documents (CIMD) as a suggested standard for MCP authorization.

As the newest recommendation in the MCP spec, CIMD aims to fix the existing client registration pitfalls. CIMD does a few things differently that elegantly fits within the existing OAuth handshake of MCP.

First, the MCP client is in charge of hosting a metadata.json file via HTTPS. The metadata document provides attestation of redirect URIs to the client’s identity via HTTPS. In other words, MCP server developers can trust that redirect URIs in the metadata.json file are controlled by the MCP client, which is crucial in an environment where the MCP client and server must trust each other without any pre-registration.

Next, the MCP client provides the HTTPS URL of this metadata document as its Client ID to the Authorization Server. This not only fits within the expected OAuth handshake between the MCP client and Authorization Server, it gives the Authorization Server a secure place to verify details about the incoming MCP client.

Once the Authorization Server has finished validating the provided metadata.json, the MCP client can go through the OAuth 2.1 authorization process as usual. This diagram shows how CIMD works between the MCP client, its metadata URL, and the Authorization Server.

Enabling CIMD in the Agentic Identity Hub

Within the Agentic Identity Hub, enabling CIMD support for your MCP server can be done with the click of a button. When configuring your MCP server, simply enable CIMD in the MCP Client Registration settings.

Both DCR and CIMD can be enabled at the same time by the Authorization Server—it’s the MCP client that decides how to proceed with client registration. 

On top of simply enabling support for this feature, you can customize approved domains for incoming clients. By default, all domains are permitted, but if you wanted to limit MCP Clients with a domain of claude.ai, you can do so. In addition, we support Client Registration Flows which allow you to enforce additional security controls for clients that register dynamically either via CIMD or DCR.

DCR vs. CIMD: when to use each (or both)

DCR and CIMD ultimately serve to solve the same problem: identifying MCP clients so they can authenticate safely with an Authorization Server. The difference is in how identification is established and what kinds of environment each approach best supports. 

If you’re using Descope for MCP auth, these methods don’t have to be competing mechanisms; rather, they are complementary protocols that map to different operational requirements (which often overlap). 

DCR’s openness

As previously mentioned, DCR was the early default for MCP. It was a necessary tool that worked well in controlled settings where clients are long-lived, relatively static, and governed mostly through centralized processes. But as we noted earlier, DCR’s open registration endpoints and persistent entries make it a poor fit for the open internet—even if it is hardened through layered verification, constrained registration sources, and short-lived credentials.

CIMD’s complexity

CIMD addresses these limits at scale. By shifting identification to client-hosted metadata, CIMD aligns more natively with open ecosystems where potentially malicious actors operate. Trust is established through tried-and-true HTTPS-based domain control, and clients can be registered frequently without saturating the Authorization Server with countless records. The tradeoff is complexity: handling metadata hosting, validating the documents, server caching, and all the security considerations that come with existing in a dynamic and open ecosystem.

Thus, choosing between DCR and CIMD is less about feature fit and more about the environment in which they operate:

In practice, you don’t really have to choose between DCR and CIMD. DCR can remain in place for structured, enterprise-managed clients that require tight oversight, while CIMD handles dynamic or previously unknown clients that benefit from faster, on-demand discovery. 

Over time, however, CIMD will tend to become the default, not because DCR is useless or obsolete, but because CIMD better reflects the eventual promise of how MCP can deliver agentic interactions at scale. 

Also Read: DCR vs CIMD

Enabling secure agentic systems with Descope

Client ID Metadata Documents (CIMD) is the latest suggested authorization technique in MCP and you can now enable it for your MCP servers within the Descope Agentic Identity Hub alongside Dynamic Client Registration and pre-registration. With the click of a button and less than 5 lines of code, you can add production-grade auth to your MCP servers. 

To get started, sign up for a Free Forever account and visit our documentation. Building an MCP server and have more questions about our platform? Book a demo with our team.