UPDATE: This was VPN/network gating on our own Enterprise AS, not a Copilot Studio bug. It was confirmed by making it reachable and getting a full successful flow through, including a real tool call.
MCP tool "Dynamic Discovery" OAuth crashes with internal server error — never queries the authorization server
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(179.20000000000002, 43%, 27%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EMO%3C/text%3E%3C/svg%3E)
Mardiyyah Oduwole
0
Reputation points
I'm connecting a Copilot Studio agent to a custom MCP server, added via Tools → Add a tool → Model Context Protocol (URL only, no manual auth config — the built-in auto-discovery path). The MCP server requires OAuth; sign-in should happen automatically via RFC 9728 protected-resource metadata + RFC 8414 authorization-server discovery.
Symptom: When the agent tries to invoke the tool, it prompts the connection flow, then fails with:
Encountered internal server error. The correlation Id is '
<your correlation ID>'.
What I've verified with server-side logs on both ends:
- Copilot Studio calls
GET /mcpon my server → gets401with aWWW-Authenticateheader pointing to/.well-known/oauth-protected-resource/mcp(per RFC 9728). Confirmed in my server's access logs. - Copilot Studio then fetches
/.well-known/oauth-protected-resource/mcp→ gets a200with valid JSON, including anauthorization_serversentry pointing to my authorization server. Confirmed in my server's access logs. - That authorization server's own
/.well-known/oauth-authorization-serverdocument is independently confirmed reachable and spec-correct (RFC 8414) — it advertises a workingregistration_endpoint,token_endpoint_auth_methods_supportedincluding both public and confidential clients, and PKCE (S256). - The authorization server's access logs show zero incoming requests — not to
.well-known/oauth-authorization-server, not to the registration endpoint. Nothing. Copilot Studio never attempts to contact it after step 2. - I tested whether a trailing slash on the
authorization_serversURL (added by pydantic's URL normalization on my server) was tripping up discovery, by removing it. Identical failure with or without the trailing slash — ruled out.
So the failure happens entirely inside Copilot Studio, between successfully reading my protected-resource metadata and ever attempting to reach the authorization server it just learned about — with no further outbound requests at all.
Microsoft Copilot | Other
2 answers
Sort by: Most helpful
-
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(160, 48%, 25%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3ESM%3C/text%3E%3C/svg%3E)
Sayali-MSFT 6,486 Reputation points Microsoft External Staff Moderator2026-08-27T09:08:46.2533333+00:00 Hello @Mardiyyah Oduwole ,
The server-side evidence indicates that the RFC 9728 challenge and protected-resource metadata discovery are completing successfully, but Copilot Studio fails before making any RFC 8414 discovery or dynamic client-registration request to the advertised authorization server. This rules out the trailing slash, token endpoint, PKCE, redirect URI, audience, and authorization-server availability as the immediate cause. The issue is most likely within Copilot Studio’s dynamic OAuth discovery processing or an undocumented authorization-server compatibility restriction.can u share with the correlation ID, UTC timestamp, environment/agent details, sanitized discovery documents, and logs from both servers so engineering can inspect the backend failure immediately after protected-resource metadata parsing.-
Mardiyyah Oduwole 0 Reputation points
2026-08-27T10:04:19.1533333+00:00 Hi @Sayali-MSFT
Thanks for confirming the discovery is completing but AS discovery/DCR never fires. Here's a fresh reproduction:
Correlation ID:
03a97738-b1e5-4d4c-84b4-c4d4d93b56f1UTC timestamp: ~2026-08-27 09:32 UTC Flow used: Built-in "Add a tool → Model Context Protocol" wizard, Dynamic Discovery (no manual input). The error occurs when invoking the tool, not during setup.Our protected-resource metadata (
/.well-known/oauth-protected-resource/mcp), hostnames masked:{"resource":"https://<mcp-server-host>/mcp","authorization_servers":["https://<enterprise-host>/"],"scopes_supported":["chat:query"],"bearer_methods_supported":["header"]}Our authorization server's metadata (
/.well-known/oauth-authorization-server), hostnames masked:{"issuer":"https://<enterprise-host>","authorization_endpoint":"https://<enterprise-host>/assistant/mcp/oauth2/authorize","token_endpoint":"https://<enterprise-host>/assistant/mcp/oauth2/token","registration_endpoint":"https://<enterprise-host>/assistant/mcp/oauth2/register","scopes_supported":["chat:query"],"response_types_supported":["code"],"response_modes_supported":["query"],"grant_types_supported":["authorization_code","refresh_token"],"token_endpoint_auth_methods_supported":["none","client_secret_basic","client_secret_post"],"code_challenge_methods_supported":["S256"],"authorization_response_iss_parameter_supported":true}Our MCP server's logs for that window (UTC), showing every tool-invocation attempt landing unauthenticated and re-fetching the protected-resource metadata instead of ever proceeding to authorization-server discovery:
09:28:46.884 GET /mcp -> 401 (no Authorization header) 09:28:46.885 auth error: invalid_token 09:28:46.885 request rejected: no Authorization header (reason=missing_credentials) 09:28:47.759 GET /.well-known/oauth-protected-resource/mcp -> 200 09:29:47.704 GET /mcp -> 401 (no Authorization header) 09:29:47.704 auth error: invalid_token 09:29:47.704 request rejected: no Authorization header (reason=missing_credentials) 09:29:48.121 GET /.well-known/oauth-protected-resource/mcp -> 200 09:31:08.669 GET /mcp -> 401 (no Authorization header) 09:31:08.669 auth error: invalid_token 09:31:08.669 request rejected: no Authorization header (reason=missing_credentials) 09:31:09.095 GET /.well-known/oauth-protected-resource/mcp -> 200Authorization-server-side logs (09:28–09:38 UTC): Every entry in this window is an internal scheduled background job on its normal timer — each one shows
method: <null>,request URI: <null>,remote IP: <null>. No inbound web request of any kind was received during this window, confirming the request never left Copilot Studio's client and never reached our authorization server.Separately, for context: when we instead use manual OAuth registration (pre-registered client) against the same authorization server, the flow does reach our authorization server correctly and returns a valid authorization code, but then hangs indefinitely on Microsoft's own consent-broker redirect (
msmanaged-na.consent.azure-apim.net) until the approval page times out.Happy to share the unmasked hostnames, agent ID, and environment details through a private channel if that's more useful for your investigation.
Thanks,
Mardiyyah
-
Sayali-MSFT 6,486 Reputation points Microsoft External Staff Moderator
2026-08-31T11:12:03.3666667+00:00 Hello @Mardiyyah Oduwole ,
Thank you for the sharing the details.We have reported this as a bug for further investigation.We will keep you updated as soon as we receive further information. Thank you for bringing this to our attention!
Sign in to comment -