Model Context Protocol (MCP) + Descope

The Model Context Protocol (MCP) is an open standard that defines a secure, consistent, and interoperable way for AI models and agents to communicate with external systems (APIs, tools, files, and services).

Descope integrates with MCP to provide a fully managed authentication and authorization layer for securing MCP servers and governing access to MCP tools.

About MCP

MCP is the standard interface layer between AI systems and external resources.

A good mental model: MCP is like USB-C for AI — a universal, plug-and-play protocol that replaces custom, one-off integrations with a consistent connection model.

Instead of bespoke integrations for every AI system, MCP introduces a standardized plug-and-play model that works across:

• AI agents and chat interfaces
• Developer tools like IDEs and CLIs
• Local and remote APIs, SaaS apps, and data services
• Secure, multi-tenant environments with structured access control

To learn more about MCP, refer to the official MCP documentation.

Why Use Descope with MCP

Descope provides the identity and access control foundation required to deploy MCP securely at scale:

1. OAuth 2.1 Authorization for MCP Servers

• MCP authorization is built on OAuth 2.1
• Descope handles authentication, user consent, scope validation, SSO, social OAuth login, and other modern auth methods
• You can configure your MCP server inside Descope and declare OAuth scopes per tool

2. Secure Token & Secret Management for MCP Tools

• Store OAuth tokens, refresh tokens, static API keys, and external credentials using Connections
• MCP tools retrieve credentials securely at runtime, avoiding hardcoded secrets

3. Granular Access Control & Policy Enforcement

• Define access policies that map:
  • Client or agent attributes (e.g., tags, roles, metadata)
  • OAuth token claims to specific tool permissions and allowed scopes
• Ensures only approved clients or agents can call sensitive MCP tools

How Descope Secures MCP Servers

With Descope you can:

• Configure your MCP server inside Descope using a .well-known endpoint that exposes all OAuth endpoints, including Dynamic Client Registration (DCR) if enabled.
• Define tool-level scopes (e.g., mcp:invoice.create, mcp:calendar.write) to treat tool access as a first-class permission.
• Onboard clients / agents dynamically using:
  • CIMD (Client-Initiated Metadata Discovery) or
  • DCR (Dynamic Client Registration)
• Restrict scopes per client to ensure only approved scopes can be used.
• Run custom logic on registration (e.g., assign tags like sales-agent, attach metadata for policy decisions).

Basic Authentication and Authorization with MCP

You can use Descope as the authentication and authorization layer for any MCP server, including custom implementations or frameworks like FastMCP, by leveraging Descope's OAuth 2.1 discovery endpoint.

• The .well-known OpenID configuration published by Descope exposes all required OAuth 2.1 endpoints (authorization, token exchange, JWKs, and Dynamic Client Registration if enabled by the MCP server).
• MCP clients can be provisioned either: Manually in the Descope Console, or Automatically using CIMD or DCR (if enabled in your MCP server configuration).

You can read more about how to configure your MCP server with Descope in our MCP Server doc.

Scoping with MCP Servers

MCP authorization follows OAuth 2.1, where the MCP server acts as the resource server—responsible for enforcing the permissions carried in the access token. Scopes are the standard way to express those permissions.

Adding scopes to your MCP server enables:

• Granular tool access (e.g., read-only vs. write actions)
• Protection of sensitive MCP tools
• Least-privilege enforcement across users, agents, and tenants
• Auditable and revocable tool permissions

Without scopes, access becomes all-or-nothing, making fine-grained tool authorization impossible.

For granular authorization, it is recommended to define one scope per MCP tool or tool group.

These scopes are issued in MCP client access tokens and let your MCP server verify which tools an AI agent or MCP client is allowed to invoke.

Example tool-level scopes:

• mcp:invoice.create → Permission to run invoice-generation tools
• mcp:calendar.write → Permission to create or modify calendar events
• mcp:calendar.read → Read-only access to calendar queries

Scopes also require a human-friendly description when configured, which helps end users understand exactly what access an MCP client or agent is requesting.

Calling External APIs from Tools

Use this pattern only when an MCP tool needs credentials to call an external API—whether OAuth tokens or API keys.

If your MCP tools do not call external APIs that require authentication, you can skip this section and rely on MCP tool scopes alone.

When your MCP tools do call authenticated external APIs, Descope stores those credentials securely using Connections, allowing you to:

• Store multiple OAuth tokens per user or tenant, each with its own scopes and automatic refresh—even for the same third-party service.
• Store API keys for non-OAuth services, which can be fetched at runtime.
• Store credentials for multiple MCP servers or external APIs in one unified token store, eliminating hardcoded secrets and custom refresh logic in your gateway or MCP server.

Your MCP server retrieves these credentials using Descope SDKs at runtime and uses them to execute the tool's external API calls securely.

Policies for MCP Scope Authorization

Descope Access Control Policies let you define which MCP clients or AI agents are allowed to request or use specific MCP server scopes (tools).

• You can create multiple policies to govern different MCP client types and agent groups.
• Policies evaluate requests using attributes such as:
  • MCP client identity (e.g., Claude, Cursor, etc. )
  • Agent tags (e.g., sales-agent, support-agent)
  • User roles/attributes (e.g. associated user roles, permissions, tenants)
  • Custom claims (claims in client access token)
• This allows you to grant tool-level OAuth scopes based on who the agent/client is, what group or tag they belong to, and where they're operating.

Example MCP Servers

Multi-Tenant Calendar MCP Server

See our detailed example of building a Calendar MCP Server with SSO and tool-level scoping that demonstrates:

• Restricting access to registered MCP clients
• SSO authentication with Okta or Azure AD
• Tool-level scope authorization

For a list of example MCP servers, please refer to our GitHub repository.