MCP Server Settings
This section provides an overview of all configurable aspects of an MCP server, under the Settings tab.
MCP Server Details
Note
If you would like to add additional claims to any access tokens created for this MCP Server, you can use the custom claims flow action in your user consent flow.
These are the basic configurable details of an MCP server:
- Name (required)
- Description (optional)
- MCP Server URL (optional) → becomes the
audclaim in access tokens
MCP Client Registration
In this section, you can configure how clients can register with your MCP server.
Descope supports three client registration mechanisms: Client ID Metadata Documents (CIMD), Dynamic Client Registration (DCR), and Pre-registration. Learn more about each method and when to use them in our Client Registration Methods documentation.
Note
Clients must be pre-registered under the Clients section after the MCP server configuration is saved, not in this client registration configuration section.
The two settings you can configure in this section of the MCP server settings are the following:
| Setting | Purpose |
|---|---|
| CIMD | Securely discover client OAuth metadata from a client-hosted HTTPS URL. You can also specify approved domains when enabling. |
| DCR | Allow clients to self-register and receive a client_id if CIMD is unsupported. |
By default, all MCP servers will have DCR enabled, and CIMD disabled.
Approved Domains
You can specify approved domains for CIMD client registration. This is a list of domains that are allowed to register with your MCP server. If a client is not from an approved domain, the client registration will fail.
Approved domains can either be a specific domain, or a wildcard domain. For example, example.com or *.example.com.
MCP Server Scopes
MCP server scopes define which permissions clients are allowed to request and map to tool access. Scopes can optionally link to specific connection scopes for retrieving external OAuth tokens or API keys when tools call third-party services.
For each scope, configure:
| Field | Purpose |
|---|---|
| Scope name | The machine-friendly scope string enforced by your MCP server (e.g., menu:read, calendar:write) |
| Connection scopes | OAuth scopes or permissions that should be requested on external services via Connections |
| Description to show on the consent screen for end users | Human-readable explanation shown on the user consent screen |
| Mark as mandatory scope (toggle) | Optionally set the scope as optional (scopes are mandatory by default) |
Here is an example scope configuration:
Flows
Each MCP server supports two configurable flows that control how users authenticate and how MCP clients (agents) are onboarded.
User Consent Flow
End users go through the User Consent Flow when authenticating to an MCP server. This flow runs during /authorize requests and controls user authentication, scope consent, and conditional logic.
The following things can be configured in the User Consent Flow:
-
User Authentication - Guide users through your chosen authentication methods, such as SSO (Okta, Azure AD, etc.), passwordless/password-based login, social login, or MFA and step-up authentication.
-
Scope Consent - Display a consent screen where users explicitly approve the MCP server scopes being requested. Scope descriptions configured on the MCP server are shown here to clearly communicate what access is being granted.
-
Conditional Logic - Add conditional logic based on user, tenant, or request context, such as tenant-specific authentication requirements, additional verification for sensitive scopes, or conditional MFA and step-up flows.
-
Connection Actions - You can use Connection actions in your User Consent Flow to collect external OAuth tokens or API keys during authentication.
Check out our Flows documentation for more information on how to configure and use the User Consent Flow.
Client Registration Flow
The Client Registration Flow runs when an MCP client registers using DCR or CIMD. This flow is used to verify and classify clients before they are allowed to interact with your MCP server and users can start signing in.
By default, newly registered clients are unverified.
Tag and Classify Clients: Assign tags to clients for identification and future access control, for example tagging Claude as sales-agent, ChatGPT as viewer-agent, or internal tools as internal-agent. These tags can later be used in policies across the Agentic Identity Hub.
Verify Client Status: Review newly registered clients and update their status by marking trusted clients as verified, blocking or rejecting untrusted clients, or using connectors (such as AbuseIPDB) to detect malicious originating IPs and block registration from those IPs.
This allows you to enforce reputation checks or platform detection before granting access to your MCP server and users can start signing in.