Client Registration Methods

MCP servers support three client registration mechanisms for onboarding OAuth clients. Each method has different use cases and benefits, and clients supporting all options should follow a specific priority order when choosing which method to use.

Client Registration Approaches

Descope supports three client registration mechanisms for MCP servers:

• Client ID Metadata Documents (CIMD): When client and server have no prior relationship
• Dynamic Client Registration (DCR): For backwards compatibility or specific requirements
• Pre-registration: Pre-defined client in Descope, with it's own unique Client ID and Secret

For new MCP server deployments, Client ID Metadata Documents (CIMD) is the recommended approach as it provides the best balance of security, flexibility, and ease of use for both clients and servers. Pre-registration is ideal for controlled environments with known clients, while DCR should be used primarily for backwards compatibility.

Most MCP servers will want to enable both CIMD and DCR to support the widest range of clients, with CIMD as the primary method and DCR as a fallback option.

Client ID Metadata Documents (CIMD)

Client ID Metadata Documents (CIMD) enable clients to use HTTPS URLs as client identifiers, where the URL points to a JSON document containing client metadata.

This approach addresses the common MCP scenario where servers and clients have no pre-existing relationship, making it the recommended method for most MCP deployments.

The following diagram illustrates the complete flow when using CIMD:

To enable CIMD for your MCP server, see the MCP Server documentation.

When CIMD is enabled, the client_id_metadata_document_supported field in your discovery document will be set to true.

Example Metadata Document

Here's an example of a Client ID Metadata Document, hosted by a client:

{
  "client_id": "https://app.example.com/oauth/client-metadata.json",
  "client_name": "Example MCP Client",
  "client_uri": "https://app.example.com",
  "logo_uri": "https://app.example.com/logo.png",
  "redirect_uris": [
    "http://127.0.0.1:3000/callback",
    "http://localhost:3000/callback"
  ],
  "grant_types": ["authorization_code"],
  "response_types": ["code"],
  "token_endpoint_auth_method": "none"
}

Dynamic Client Registration (DCR)

Dynamic Client Registration (DCR) is the OAuth 2.0 Dynamic Client Registration Protocol (RFC 7591) that allows MCP clients to obtain OAuth client IDs programmatically without user interaction. This option is included primarily for backwards compatibility with earlier versions of the MCP authorization spec.

When to Use DCR

DCR is best suited for:

• Legacy clients: Supporting clients that don't support CIMD
• Fallback option: As a fallback when CIMD is not available
• Specific requirements: When programmatic registration is required but CIMD isn't feasible

However, compared to CIMD, DCR also has some strong limitations. Most notably:

• Server-side management overhead: Each registration creates a new client in Descope, resulting in many clients that need to be managed over time.
• Less flexible: Clients must go through a registration step before they can authenticate

Discovery

Authorization servers advertise support for Dynamic Client Registration by including a registration_endpoint in their OAuth Authorization Server metadata:

{
  "registration_endpoint": "https://api.descope.com/v1/mgmt/mcp/client/P32juVkF2iM8wAGoM8PiLkGi6POV/MS35d1Xw1Yo6zozsW7n8BU6xLmnAs/register"
}

When DCR is enabled, this endpoint appears in your MCP server's discovery document.

Pre-registration

Pre-registration involves manually registering clients with the authorization server before they can connect. This method is suitable when you have an existing relationship with the client and want to maintain explicit control over which clients can access your MCP server.

When to Use Pre-registration

Pre-registration is best suited for:

• Known clients: When you have a pre-existing relationship with the client (e.g., internal tools, partner integrations)
• Simplified client setup: When clients prefer not to host metadata documents
• Static deployments: When client configurations rarely change

In Descope, you can pre-register clients under the Clients section after the MCP server configuration is saved.