Power Platform Community Forum Thread Details

Context
I’ve built an MCP server that’s secured using an Azure AD App and expects application (client credentials) tokens. The server validates the token and role claims. There is no user/delegated context in this flow.

Issue
When the Agent calls the MCP tool via the Custom Connector, Copilot Studio is always generating/sending a delegated (user) token. I need it to send an application token (client credentials flow) to match the server’s expected auth model. I can’t find any documentation on configuring the Custom Connector so that the MCP tool call uses application-based tokens.

Questions

Is there a supported way to configure a Custom Connector (used by an MCP tool in Copilot Studio) to use OAuth 2.0 Client Credentials (application token) instead of a delegated token?
If yes, which security settings (Authorization URL/Token URL/Scope placement/Client ID+Secret) and connection settings should be used so that Copilot Studio acquires and forwards an app token?
Are there limitations specific to Copilot Studio MCP tools that force delegated tokens even if the Custom Connector is set up for client credentials?

Connector security configuration (summary)

Authentication type: OAuth 2.0
Grant type needed: Client Credentials (desired)
Current behavior: Appears to run delegated auth at runtime when invoked as an MCP tool

Categories:

Calling actions from Copilot Studio

Model context protocol

1. Is there a supported way to configure a Custom Connector (used by an MCP tool in Copilot Studio) to use OAuth 2.0 Client Credentials (application token) instead of a delegated token?
As of now, Copilot Studio (and Power Platform Custom Connectors in general) supports OAuth 2.0 Client Credentials flow for Custom Connectors, but there are important limitations when used as MCP tools or in Copilot Studio.

Custom Connectors can be configured for Client Credentials flow in the connector definition.
Copilot Studio MCP tools: When used as a tool in Copilot Studio, the platform often defaults to using delegated (user) tokens, even if the connector is set up for client credentials. This is because Copilot Studio is designed around user-centric scenarios and expects user context for most tool invocations.
2. If yes, which security settings (Authorization URL/Token URL/Scope placement/Client ID+Secret) and connection settings should be used so that Copilot Studio acquires and forwards an app token?
Connector Security Settings for Client Credentials:

Authentication type: OAuth 2.0
Grant type: Client Credentials
Authorization URL: (Leave blank for client credentials)
Token URL: Your Azure AD token endpoint, e.g.,
https://login.microsoftonline.com/{tenant}/oauth2/v2.0/token
Client ID/Secret: Registered Azure AD App credentials
Scope: The resource/API scope, e.g., api://{app-id}/.default
Scope placement: Body
However:
Even with these settings, Copilot Studio may still attempt to use delegated tokens at runtime, because the tool invocation is tied to the user’s context.

3. Are there limitations specific to Copilot Studio MCP tools that force delegated tokens even if the Custom Connector is set up for client credentials?
Yes, there are limitations:

Copilot Studio MCP tools are designed to operate in the context of the signed-in user. This means that, by default, the platform will try to acquire a delegated token for the user, not an application token.
Client Credentials flow is not fully supported for tool invocations in Copilot Studio, even if the connector is configured for it. This is a known limitation and is not well-documented.
Workarounds:
You may need to call your MCP server from a Power Automate flow (which can use client credentials) and then invoke that flow from Copilot Studio.
Alternatively, expose an endpoint that accepts delegated tokens and map user roles accordingly, if possible.