diff --git a/src/content/docs/agents/model-context-protocol/authorization.mdx b/src/content/docs/agents/model-context-protocol/authorization.mdx
index 1392cd370296164..7f5a87a8048a289 100644
--- a/src/content/docs/agents/model-context-protocol/authorization.mdx
+++ b/src/content/docs/agents/model-context-protocol/authorization.mdx
@@ -124,7 +124,7 @@ Read the docs for the [Workers oAuth Provider Library](https://github.com/cloudf
 
 ### (3) Bring your own OAuth Provider
 
-If your application already implements an OAuth Provider itself, or you use [Stytch](https://stytch.com/), [Auth0](https://auth0.com/), [WorkOS](https://workos.com/), or authorization-as-a-service provider, you can use this in the same way that you would use a third-party OAuth provider, described above in (2).
+If your application already implements an OAuth Provider itself, or you use authorization-as-a-service provider, you can use this in the same way that you would use a third-party OAuth provider, described above in (2).
 
 You can use the auth provider to:
 - Allow users to authenticate to your MCP server through email, social logins, SSO (single sign-on), and MFA (multi-factor authentication).
@@ -133,6 +133,7 @@ You can use the auth provider to:
 - Enforce the permissions so that agents can only invoke permitted tools.
 
 #### Stytch
+
 Get started with a [remote MCP server that uses Stytch](https://stytch.com/docs/guides/connected-apps/mcp-servers) to allow users to sign in with email, Google login or enterprise SSO and authorize their AI agent to view and manage their company's OKRs on their behalf. Stytch will handle restricting the scopes granted to the AI agent based on the user's role and permissions within their organization. When authorizing the MCP Client, each user will see a consent page that outlines the permissions that the agent is requesting that they are able to grant based on their role.
 
 [![Deploy to Cloudflare](https://deploy.workers.cloudflare.com/button)](https://deploy.workers.cloudflare.com/?url=https://github.com/cloudflare/ai/tree/main/demos/mcp-stytch-b2b-okr-manager)
@@ -142,6 +143,7 @@ For more consumer use cases, deploy a remote MCP server for a To Do app that use
 [![Deploy to Cloudflare](https://deploy.workers.cloudflare.com/button)](https://deploy.workers.cloudflare.com/?url=https://github.com/cloudflare/ai/tree/main/demos/mcp-stytch-consumer-todo-list)
 
 #### Auth0
+
 Get started with a remote MCP server that uses Auth0 to authenticate users through email, social logins, or enterprise SSO to interact with their todos and personal data through AI agents. The MCP server securely connects to API endpoints on behalf of users, showing exactly which resources the agent will be able to access once it gets consent from the user. In this implementation, access tokens are automatically refreshed during long running interactions.
 
 To set it up, first deploy the protected API endpoint:
@@ -158,6 +160,12 @@ Get started with a remote MCP server that uses WorkOS's AuthKit to authenticate
 
 [![Deploy to Cloudflare](https://deploy.workers.cloudflare.com/button)](https://deploy.workers.cloudflare.com/?url=https://github.com/cloudflare/ai/tree/main/demos/remote-mcp-authkit)
 
+#### Descope
+
+Get started with a remote MCP server that uses [Descope](https://www.descope.com/) Inbound Apps to authenticate and authorize users (for example, email, social login, SSO) to interact with their data through AI agents. Leverage Descope custom scopes to define and manage permissions for more fine-grained control.
+
+[![Deploy to Cloudflare](https://deploy.workers.cloudflare.com/button)](https://deploy.workers.cloudflare.com/?url=https://github.com/cloudflare/ai/tree/main/demos/remote-mcp-server-descope-auth)
+
 ## Using Authentication Context in Your MCP Server
 
 When a user authenticates to your MCP server through Cloudflare's OAuth Provider, their identity information and tokens are made available through the `props` parameter.
@@ -196,7 +204,7 @@ function requirePermission(permission, handler) {
         status: 403
       };
     }
-    
+
     // If permission check passes, execute the handler
     return handler(request, context);
   };
@@ -208,7 +216,7 @@ async init() {
   this.server.tool("basicTool", "Available to all users", {}, async () => {
     // Implementation for all users
   });
-  
+
   // Protected tool using the permission wrapper
   this.server.tool(
     "adminAction",
@@ -221,7 +229,7 @@ async init() {
       };
     })
   );
-  
+
   // Conditionally register tools based on user permissions
   if (this.props.permissions?.includes("special_feature")) {
     this.server.tool("specialTool", "Special feature", {}, async () => {
@@ -231,7 +239,7 @@ async init() {
 }
 ```
 
-Benefits: 
+Benefits:
 - Authorization check at the tool level ensures proper access control
 - Allows you to define permission checks once and reuse them across tools
 - Provides clear feedback to users when permission is denied