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.

This page is for developers building an MCP server that needs authentication. If you are wiring an agent to call MCP servers, see the Agent Auth SDK instead.

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.

How It Fits Together

The MCP authorization spec splits auth across two entities:

• Resource server: your MCP server. Built with the official MCP SDKs or a framework like FastMCP. It serves tools and validates access tokens.
• Authorization server: Descope. Descope publishes the OAuth discovery metadata, registers MCP clients (CIMD/DCR), runs login and consent, and issues tokens.

With that split, your server implements only two concerns:

1. Validate Descope-issued tokens on every request: signature against your project JWKs, plus the aud and scope claims. Our MCP server guide and MCP SDKs handle this for you.
2. Point clients at Descope: host a /.well-known/oauth-protected-resource document that lists Descope as your authorization server, so MCP clients discover where to send users after a 401. See OAuth Protected Resource Metadata.

Everything else (client registration, consent screens, token issuance, refresh) happens inside Descope.

Why Use Descope with MCP

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

1. Keep up with the MCP authorization spec

MCP authorization is a moving target. The spec keeps adding requirements that are non-trivial to build and maintain yourself. Descope keeps your MCP server current by configuration rather than a rebuild, including:

• Dynamic Client Registration (DCR) and Client ID Metadata Documents (CIMD) so MCP clients like Claude, Cursor, and VS Code register with your server automatically, with custom logic on registration (e.g., assign tags like sales-agent for policy decisions).
• Enterprise-Managed Authorization (Cross App Access / XAA) as a validator, via ID-JAG, so enterprise customers can reach your MCP server through their own workforce IdP (Okta, Entra) with no extra consent.
• New authorization requirements as the spec evolves, adopted through settings instead of code changes.

2. 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

3. 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

4. Granular OAuth Permissions and 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
• Create granular OAuth scopes for agents to hold and end users to consent to, whether tool-level or broader. These can be finer-grained than the permissions the downstream services behind your MCP server actually expose, so you can grant, consent to, and audit exactly what an agent may do even when the underlying API only offers coarse access.
• Ensures only approved clients or agents can call sensitive MCP tools

B2C and B2B companies

Descope supports MCP servers for both consumer and enterprise audiences from the same project. The auth problems differ, so here is what each typically needs.

B2C

You expose an MCP server to individual consumers, often to get listed on the Claude or ChatGPT marketplaces, where proper auth on your MCP server is a requirement.

E-commerce platforms adopting agentic commerce protocols such as UCP and ACP fall in the same bucket: an agent is transacting on a real customer's behalf, so the server has to know who that customer is.

• Enable MCP auth quickly: Descope handles OAuth 2.1, DCR and CIMD, and proper user management and consent out of the box. If you already have an auth system, use Bring Your Own Auth instead of migrating your users.
• Tool-level scopes with real user consent: define scopes per tool and a consent flow so users approve exactly what an MCP client may do.
• Identity linking instead of an unauthenticated server: when tools need user context (their cart, their orders, their data), link the MCP session to the user who already exists in your product, so every tool call carries a real identity rather than serving anonymous traffic.

Start with the MCP server guide, or Bring Your Own Auth if you already have an auth system.

B2B

You are building an MCP server to enable other enterprises. Everything above still applies. In this scenario, each customer is usually a Tenant, typically with its own SSO and its own access rules.

• Enterprise-Managed Authorization: enable ID-JAG validation so each customer's users reach your server through their own workforce IdP (Okta, Entra) with no extra consent.
• SSO groups to roles to policies: map each customer's SSO groups to Descope roles, then use those roles in policies to decide which scopes each user's agents receive, per tenant.
• Multi-tenant isolation: see the multi-tenant calendar MCP server example for tenant-scoped SSO, roles, and tool scopes end to end.

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.

MCP SDKs

Descope ships server-side MCP SDKs that handle token validation (signature, aud, scope), the required metadata endpoints, and per-tool scope enforcement:

• Express SDK (@descope/mcp-express): drop-in middleware that ships an authenticated /mcp endpoint and tool registration with scopes.
• Python SDK (descope-mcp): token validation, Connection token retrieval, and FastMCP integration.

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 a Resource: a resource server that enforces permissions 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 in Connections: one vault shared across all your MCP servers and APIs, so nothing is hardcoded and you never write refresh logic. It holds:

• OAuth tokens per user or tenant, each with its own scopes and automatic refresh, including multiple tokens for the same third-party service.
• API keys for non-OAuth services, fetched at runtime.

This works through token exchange. The MCP client connects with a Descope access token, and when a tool runs, your server exchanges that token with Descope for whatever the tool needs: an API key or OAuth token from the Connections vault, or another Resource token if the target is an API you have defined as a Resource in Descope.

Your MCP server performs the exchange using Descope SDKs at runtime; the MCP client never holds the downstream credential.

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.

Policies and user consent are two levels of control: policies are what an IT admin allows in the Descope Console, and consent is what the end user approves. Policy wins; scopes that no policy permits never appear on the consent screen, so users can only consent within what admins have allowed. See Policies and User Consent.

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

Multi-Tenant MCP Server with Tenant Switching

See our example of building a B2B MCP Server for users who belong to many tenants, that demonstrates:

• Signing in once with one MCP URL and selecting a tenant in the consent flow
• Switching the active tenant mid-session with a switch_tenant tool (no reconnect)
• Using token introspection to read the live active tenant on every tool call
• Dynamically updating tools/list based on the active tenant

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