Facing Error Access denied when connecting to the Dynamics 365 MCP server from AI Foundry

Mohammad Ali 0 Reputation points
2026-09-11T06:22:25.4566667+00:00

We are trying to connect our AI Foundry with Dynamics 365 FO using the Custom OAuth based connector, everything is configured to specification, this connector was working last week, but all of a sudden it is giving 403 error after perform the consent flow.

**Problem Description

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

ErrorAccess denied when connecting to the MCP server at {DYNAMICS URL}/mcp 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. Troubleshooting guide: https://learn.microsoft.com/en-us/azure/foundry/agents/how-to/mcp-authentication#troubleshooting

**Validation Steps Already Performed

**I have tested my access to this dynamics 365 environment by using POSTMAN, and I was able to fetch data from it, but I dont understand why the MCP connector is failing all of a sudden. I have also created a new connector inside AI Foundry and still the same issue persists.

Any troubleshooting guidance would be greatly appreciated.

Thank you for your assistance.

Kind regards,

Ali

Foundry Tools
Foundry Tools

Formerly known as Azure AI Services or Azure Cognitive Services is a unified collection of prebuilt AI capabilities within the Microsoft Foundry platform

0 comments

1 answer

Sort by: Most helpful
Most helpful Newest Oldest

  1. AI answer

    2026-09-11T06:22:47.92+00:00

    A 403 Forbidden during MCP tool enumeration points to an authorization or access-path problem between Foundry and the Dynamics MCP endpoint, not a general OAuth consent success issue.

    Based on the reported behavior, the most relevant checks are:

    1. Verify the selected auth configuration is still valid For MCP connections, 401/403 errors indicate the key or token used for the selected authentication method should be validated. If credentials may have changed or been exposed, rotate them and update the saved connection.
    2. Recheck OAuth configuration values For OAuth passthrough scenarios, confirm the authorization URL, token URL, and scopes in the Foundry tool configuration still match the OAuth provider settings. Also verify the client ID and client secret are correct and not expired. Scope mismatches or incorrect endpoint values are called out as common causes of token exchange failures.
    3. Confirm the downstream principal still has required access For identity-based auth, the principal used by the toolbox must have the required RBAC role on the target resource before the toolbox is called. A 403 specifically means the configured credential, connection, or selected identity may no longer have the required downstream permission.
    4. Check whether this is a consent-first-call scenario For OAuth-based MCP endpoints in Foundry projects, the first call can return CONSENT_REQUIRED with error code -32006. That is expected. After opening the consent URL and completing authorization, retry the call. If consent completes but the next call returns 403, the issue is after consent and is usually permissions or OAuth configuration rather than the consent flow itself.
    5. Validate network access to the MCP endpoint If the endpoint is behind proxy, firewall, private networking, or IP restrictions, Foundry must be allowed to reach it. For MCP connectivity issues, verify the server URL is reachable and that outbound HTTPS access is not blocked. If private endpoints are involved, confirm the private networking setup is correct.
    6. Check whether the endpoint itself is returning the denial Since Postman can fetch data, compare the exact auth path used by Postman with the one used by Foundry. A working direct API call does not prove the MCP endpoint accepts the same token audience, scopes, or auth mode. The MCP server can be reachable while still denying tool enumeration.
    7. Review server-side logs For custom MCP servers, check the server or hosting logs for authorization failures and confirm what request is arriving during tool discovery. A successful connection with failed tool publication or denied enumeration can produce the exact symptom being seen.
    8. Recreate and retest with a minimal setup Since recreating the connector did not help, test with a minimal MCP configuration and verify whether tool discovery succeeds independently. If the endpoint is reachable but returns no usable tools or denies enumeration, focus on MCP server auth and access control rather than agent instructions.

    If the MCP endpoint is OAuth-enabled and not one of the Foundry-managed OAuth connectors, Foundry requires a custom app registration for that server.

    References:

    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.