403 Forbidden Error When Accessing a Dataverse MCP Server from Azure AI Foundry

Question

403 Forbidden Error When Accessing a Dataverse MCP Server from Azure AI Foundry

Sergio Villaescusa Moreno 0

We are trying to consume a Dataverse MCP Server from Azure AI Foundry, but the server cannot be used due to the following error:

Problem Description

When attempting to enumerate tools from Azure AI Foundry, we receive the following error:

Access denied when connecting to the MCP server at:

https://agent365.svc.cloud.microsoft/agents/servers/dataverse/SERVERNAME

while enumerating tools (HTTP 403 Forbidden).

Please verify:

(1) the configured credential, connection, or selected identity has the downstream permission, RBAC role, workspace or resource access, or access policy required by this server,

(2) if the endpoint is behind private networking or IP allowlists, requests from the selected network path are permitted, and (3) the server's access control configuration allows this operation for the configured authentication mode.

Validation Steps Already Performed

The MCP server is active and running.
The MCP endpoint URL is generated correctly:

https://agent365.svc.cloud.microsoft/mcp/environments/IDENVIRONMENT/servers/SERVERNAME

Agent 365 Tools are enabled.
The environment ID used by the server matches the configured Dataverse environment.
Attempting to enumerate tools from Azure AI Foundry consistently results in access-related errors.
Authentication succeeds from Postman and we are able to obtain access tokens.
Direct calls to the service return a NotApproved status.

We would appreciate guidance on the following points:

What exactly does the NotApproved status mean for a Dataverse MCP Server?
Where is MCP Server approval configured or stored within Dataverse or Microsoft 365?
What requirements must be met for the server to transition to an approved state?
How can we verify that the MCP Server is correctly configured and authorized for use from Azure AI Foundry?
Are there any additional permissions, roles, approvals, or tenant-level configurations required for custom Dataverse MCP Servers to be consumed by Azure AI Foundry?

We have already verified Dataverse permissions, API permissions in Microsoft Entra ID, and authentication using Postman. Authentication appears to work correctly, however Azure AI Foundry is still unable to enumerate the tools exposed by the MCP server and returns HTTP 403 Forbidden. We suspect that the issue may be related to MCP Server approval, registration, or Azure AI Foundry integration requirements rather than authentication itself.

Any troubleshooting guidance would be greatly appreciated.

Thank you for your assistance.

Kind regards,

Manish Deshpande 8,135 Reputation points Microsoft External Staff Moderator

2026-09-02T17:47:43.2766667+00:00
Hello @Sergio Villaescusa Moreno

You've done the right diagnostics — token acquisition works from Postman, the environment ID matches, and Agent 365 Tools are enabled. The NotApproved status you observed on the direct call is the actual signal here, and it points to a governance gate rather than an authentication defect.

Root cause (high confidence, two contributing factors)

Custom "Bring Your Own" MCP servers registered with Agent 365 are held in a pending state after registration. The Agent 365 Tooling Gateway returns HTTP 403 on tools/list until a tenant administrator both approves the registration request and consents to the Microsoft Entra permissions the server declares. Documentation states the server becomes available to agent-building surfaces only after consent is granted, with up to 30 minutes of propagation.

Separately — and this is the more important finding — Azure AI Foundry is not currently a supported client surface for BYO MCP servers. The current documentation lists Copilot Studio, Visual Studio Code, Claude Code, and GitHub Copilot CLI as supported, and explicitly states that Azure AI Foundry and Microsoft 365 Declarative Agents aren't yet supported. This is a preview limitation on the Microsoft side, not a configuration error in your tenant.

Steps to take

Step 1 — Approve the server and grant Entra consent. A Global Admin or AI Admin signs in to https://admin.cloud.microsoft/, goes to Agents > Tools > Requests, reviews the server and its declared tools, selects Approve, and then consents to the required Microsoft Entra permissions. Why this matters: without both actions the gateway rejects every call at runtime. How to verify: the server appears on the Registry tab with status Available. Allow up to 30 minutes.

Step 2 — Correct the endpoint path. Use https://agent365.svc.cloud.microsoft/mcp/environments/<environment-id>/servers/<server-name>. The /mcp/environments/ segment is mandatory; omitting it returns 404 RouteNotFound. How to verify: GET https://agent365.svc.cloud.microsoft/.well-known/oauth-protected-resource/mcp/environments/<environment-id>/servers/<server-name> returns OAuth discovery metadata anonymously.

Step 3 — Confirm the token audience. The token must be issued for the Agent 365 Tooling Gateway app ea9ffc3e-8a23-4a7d-836d-234d7c7565c1 using a /.default scope, with tenant admin consent granted in advance (/.default does not support incremental consent). How to verify: decode your Postman token and confirm the aud claim resolves to the gateway app ID.

Step 4 — Validate on a supported client. Test the approved server from Copilot Studio or Visual Studio Code. Success there confirms your registration, approval, and tool schema are correct and isolates the remaining failure to the Foundry preview gap. How to verify: the tool list returns and a test invocation produces the expected output.

Step 5 — If Dataverse access from Foundry is the immediate business need, use the first-party Microsoft Dataverse MCP Server (Frontier) rather than a custom server. In Foundry, connect a tool > Custom > MCP > OAuth Identity Passthrough, supplying your own Entra app's client ID/secret, https://login.microsoftonline.com/{tenantId}/oauth2/v2.0/authorize and .../token for auth, token and refresh URLs, and the scope ea9ffc3e-8a23-4a7d-836d-234d7c7565c1/McpServers.Dataverse.All offline_access. Add the redirect URL Foundry returns to your app registration. Note this requires a Frontier tenant, the Foundry Agent Consumer role for consuming users, and same-tenant identity (cross-tenant token exchange isn't supported). How to verify: the first run returns an oauth_consent_request with a consent_link; after consent, tool enumeration succeeds.

Steps 1–4 are the supported configuration; Step 5 is the workaround for consuming Dataverse from Foundry while BYO MCP server support for Foundry remains unavailable in preview. I'm not able to commit to a date for Foundry support — I'll confirm status with the product team rather than speculate.

References

Manage tools for agents in Microsoft 365 admin center — https://learn.microsoft.com/en-us/microsoft-365/admin/manage/manage-tools-for-agent (sections: Bring your own (BYO) MCP server, Review and approve tool requests, Use an approved MCP server)

Set up authentication for MCP tools — https://learn.microsoft.com/azure/foundry/agents/how-to/mcp-authentication (section: Bring your own Microsoft Entra app registration)

Agent 365 tooling servers overview — https://learn.microsoft.com/microsoft-agent-365/tooling-servers-overview

Foundry MCP Server security and best practices — https://learn.microsoft.com/azure/foundry/mcp/security-best-practices#troubleshooting

Thanks,
Manish.
Sergio Villaescusa Moreno 0 Reputation points

2026-09-07T08:18:54.03+00:00
Hello Manish,

Thank you for your response.

I'd like to explain the two approaches we identified and tested in Foundry.

Option 1: Default Dataverse MCP Connector

Configuration

We used the endpoint: https://agent365.svc.cloud.microsoft/agents/servers/Dataverse/{DataverseMCPServerName}

The connector only allows the {DataverseMCPServerName} parameter to be modified. The rest of the endpoint is fixed and cannot be edited. Because of this limitation, we are unable to use the endpoint https://agent365.svc.cloud.microsoft/mcp/environments//servers/.

For {DataverseMCPServerName}, we used the alias assigned when publishing the server. We did this because the documentation indicates that publishing the server links the main Dataverse server to a specific environment. The command used was: 365 develop-mcp publish --server-name msdyn_DataverseMCPServer --environment-id <DEVELOPMENT_ID> --alias dataverse-dev --display-name "Dataverse MCP - Development"

Results

After publishing the server, an approval request appeared in the Admin Center. However, the process eventually returned the following error: "Could not find 'McpServers.Dataverse.All' scope on app ea9ffc3e-8a23-4a7d-836d-234d7c7565c1. API permissions not added."

Despite the error, the server was successfully approved.

Additional Information

It is important to mention that we used msdyn_DataverseMCPServer as the first-party server when publishing to Agent 365 because our goal was to associate it with a specific Dataverse environment. The connector's fixed endpoint does not provide any way to specify the target environment.

We tested both Managed OAuth Authentication and Custom OAuth Authentication for the tool, but neither option worked.

Our preferred approach is Managed OAuth Authentication because it would allow the tool to inherit the permissions of the signed-in user.

We also registered the MCP client "Agent365" under the Allowed MCP Clients configuration.

Option 2: Custom MCP Connector

After many attempts, this approach worked, but only when using Custom OAuth Authentication.

Configuration

Endpoint used: https://org.crm4.dynamics.com/api/mcp

Custom OAuth Authentication using an Entra ID application. Managed Identity is not available in this scenario, meaning the tool cannot use the user's delegated identity.

A Dynamics Application User was created for the Entra ID application.

The MCP client was added to the Allowed MCP Clients section in the environment's Advanced Settings.

Issues with This Option

Although this approach works, it presents several significant challenges:

Users do not inherit permissions from their delegated identity.

The tool must be approved again in every session.

We frequently encounter HTTP 401 errors because the tool does not automatically reauthenticate.

In many cases, the page must be refreshed several times before the tool requests consent and allows the user to authenticate again.

Our preferred solution is Option 1, as it would allow the tool to operate using the user's delegated permissions and provide a much better user experience. Could you please advise whether our configuration is correct and what may be causing the missing 'McpServers.Dataverse.All' scope error? We would also appreciate confirmation of the expected configuration for using the default Dataverse MCP connector with Agent365.

Thank you for your assistance. Any guidance on resolving the issues preventing Option 1 from working would be greatly appreciated.

Best regards,

Sergio Villaescusa MorenoHello Manish,

Thank you for your response.

I'd like to explain the two approaches we identified and tested in Foundry.

Option 1: Default Dataverse MCP Connector

Configuration

We used the endpoint: https://agent365.svc.cloud.microsoft/agents/servers/Dataverse/{DataverseMCPServerName}

The connector only allows the {DataverseMCPServerName} parameter to be modified. The rest of the endpoint is fixed and cannot be edited. Because of this limitation, we are unable to use the endpoint https://agent365.svc.cloud.microsoft/mcp/environments//servers/.

For {DataverseMCPServerName}, we used the alias assigned when publishing the server. We did this because the documentation indicates that publishing the server links the main Dataverse server to a specific environment. The command used was: 365 develop-mcp publish --server-name msdyn_DataverseMCPServer --environment-id <DEVELOPMENT_ID> --alias dataverse-dev --display-name "Dataverse MCP - Development"

Results

After publishing the server, an approval request appeared in the Admin Center. However, the process eventually returned the following error: "Could not find 'McpServers.Dataverse.All' scope on app ea9ffc3e-8a23-4a7d-836d-234d7c7565c1. API permissions not added."

Despite the error, the server was successfully approved.

Additional Information

It is important to mention that we used msdyn_DataverseMCPServer as the first-party server when publishing to Agent 365 because our goal was to associate it with a specific Dataverse environment. The connector's fixed endpoint does not provide any way to specify the target environment.

We tested both Managed OAuth Authentication and Custom OAuth Authentication for the tool, but neither option worked.

Our preferred approach is Managed OAuth Authentication because it would allow the tool to inherit the permissions of the signed-in user.

We also registered the MCP client "Agent365" under the Allowed MCP Clients configuration.

Option 2: Custom MCP Connector

After many attempts, this approach worked, but only when using Custom OAuth Authentication.

Configuration

Endpoint used: https://org.crm4.dynamics.com/api/mcp

Custom OAuth Authentication using an Entra ID application. Managed Identity is not available in this scenario, meaning the tool cannot use the user's delegated identity.

A Dynamics Application User was created for the Entra ID application.

The MCP client was added to the Allowed MCP Clients section in the environment's Advanced Settings.

Issues with This Option

Although this approach works, it presents several significant challenges:

Users do not inherit permissions from their delegated identity.

The tool must be approved again in every session.

We frequently encounter HTTP 401 errors because the tool does not automatically reauthenticate.

In many cases, the page must be refreshed several times before the tool requests consent and allows the user to authenticate again.

Our preferred solution is Option 1, as it would allow the tool to operate using the user's delegated permissions and provide a much better user experience. Could you please advise whether our configuration is correct and what may be causing the missing 'McpServers.Dataverse.All' scope error? We would also appreciate confirmation of the expected configuration for using the default Dataverse MCP connector with Agent365.

Thank you for your assistance. Any guidance on resolving the issues preventing Option 1 from working would be greatly appreciated.

Best regards,

Sergio Villaescusa Moreno

3 answers

Your answer

Answer 1

Hello Sergio Villaescusa Moreno,

Greetings! Thanks for raising this question in the Q&A forum.

The NotApproved status and the 403 you are seeing are not caused by authentication, Dataverse permissions, or Entra API permissions. Since your Postman test successfully obtains a token and reaches the service, credential-level authentication is already working. The failure happens one layer higher, at the Agent 365 tenant governance layer that sits in front of MCP servers exposed through agent365.svc.cloud.microsoft.

Here is the underlying mechanism:

Agent 365 governs MCP server access centrally. Any MCP server surfaced through the agent365.svc.cloud.microsoft endpoint, including the Dataverse MCP Server, is subject to a developer-to-admin approval workflow before any client, including Azure AI Foundry, is allowed to enumerate or call its tools. This applies even if the underlying Dataverse security roles and OAuth setup are completely correct.

NotApproved means the server has not yet been reviewed and approved by a tenant administrator. The workflow is: a developer registers or requests the server, a tenant admin reviews the declared server details and tools, and only after the admin approves the request and grants the required Microsoft Entra permissions does the server transition out of NotApproved and become callable.

This approval is configured in the Microsoft 365 admin center, not in Dataverse or Entra ID directly. To resolve this:

Have a tenant admin (Global Admin or AI Admin role) go to the Microsoft 365 admin center
- Navigate to Copilot Control System > Agents & connectors, or directly to Agent Tools
  - Select the Requests tab (also referred to as the Requested Agents page) to review the pending request for your Dataverse MCP server
    - Approve the request, which will also prompt the admin to grant the required Microsoft Entra permissions for the server
    After approval, re-test from Azure AI Foundry. Once the server shows as approved in the admin center's Registry tab, tool enumeration from Foundry should succeed using the same credential and endpoint you already have configured. No changes should be needed on the Foundry, Dataverse, or Entra ID side.

To answer your specific questions directly:

NotApproved means the tool/server registration is pending tenant admin review, it is not a code, RBAC, or connectivity error.
Approval is stored and configured in the Microsoft 365 admin center under Agent Tools (Registry and Requests tabs), not in Dataverse or Microsoft Entra ID.
No additional Dataverse-side permissions are required beyond what you have already verified. The missing piece is purely the tenant-level admin approval step.

If this answer helps you kindly accept the answer which will help others who have similar questions.

Best Regards,

Jerald Felix.

Manish Deshpande 8,135 Reputation points Microsoft External Staff Moderator

2026-09-02T16:08:17.0033333+00:00

Hello @Sergio Villaescusa Moreno

We sincerely apologize that your issue has not yet been resolved. Your satisfaction is important to us, and we are committed to helping you reach a resolution. Could you please share additional details here so we can assist further? If preferred, you may also share your email address and a convenient time to connect via Private Message.

Answer 2

Sergio Villaescusa Moreno 0

Hi Jerald, we’ve already accepted the publication in the admin center with admin privileges. But when trying to use the MCP with the endpoint https://agent365.svc.cloud.microsoft/agents/servers/Dataverse/{DataverseMCPServerName} along with the alias, it gave an error when listing rows. We suspect that publishing caused an error when adding the scope McpServers.Dataverse.All during the publication.

Thanks

0 comments

Answer 3

Hello Manish,

Thank you for your response.

I'd like to explain the two approaches we identified and tested in Foundry.

Option 1: Default Dataverse MCP Connector

Configuration

We used the endpoint: https://agent365.svc.cloud.microsoft/agents/servers/Dataverse/{DataverseMCPServerName}
The connector only allows the {DataverseMCPServerName} parameter to be modified. The rest of the endpoint is fixed and cannot be edited. Because of this limitation, we are unable to use the endpoint https://agent365.svc.cloud.microsoft/mcp/environments//servers/.
For {DataverseMCPServerName}, we used the alias assigned when publishing the server. We did this because the documentation indicates that publishing the server links the main Dataverse server to a specific environment. The command used was: 365 develop-mcp publish --server-name msdyn_DataverseMCPServer --environment-id <DEVELOPMENT_ID> --alias dataverse-dev --display-name "Dataverse MCP - Development"

Results

After publishing the server, an approval request appeared in the Admin Center. However, the process eventually returned the following error: "Could not find 'McpServers.Dataverse.All' scope on app ea9ffc3e-8a23-4a7d-836d-234d7c7565c1. API permissions not added."
Despite the error, the server was successfully approved.

Additional Information

It is important to mention that we used msdyn_DataverseMCPServer as the first-party server when publishing to Agent 365 because our goal was to associate it with a specific Dataverse environment. The connector's fixed endpoint does not provide any way to specify the target environment.
We tested both Managed OAuth Authentication and Custom OAuth Authentication for the tool, but neither option worked.
Our preferred approach is Managed OAuth Authentication because it would allow the tool to inherit the permissions of the signed-in user.
We also registered the MCP client "Agent365" under the Allowed MCP Clients configuration.

Option 2: Custom MCP Connector

After many attempts, this approach worked, but only when using Custom OAuth Authentication.

Configuration

Endpoint used: https://org.crm4.dynamics.com/api/mcp
Custom OAuth Authentication using an Entra ID application. Managed Identity is not available in this scenario, meaning the tool cannot use the user's delegated identity.
A Dynamics Application User was created for the Entra ID application.
The MCP client was added to the Allowed MCP Clients section in the environment's Advanced Settings.

Issues with This Option

Although this approach works, it presents several significant challenges:

Users do not inherit permissions from their delegated identity.
The tool must be approved again in every session.
We frequently encounter HTTP 401 errors because the tool does not automatically reauthenticate.
In many cases, the page must be refreshed several times before the tool requests consent and allows the user to authenticate again.

Our preferred solution is Option 1, as it would allow the tool to operate using the user's delegated permissions and provide a much better user experience. Could you please advise whether our configuration is correct and what may be causing the missing 'McpServers.Dataverse.All' scope error? We would also appreciate confirmation of the expected configuration for using the default Dataverse MCP connector with Agent365.

Thank you for your assistance. Any guidance on resolving the issues preventing Option 1 from working would be greatly appreciated.

Best regards,

Sergio Villaescusa Moreno