Custom MCP connectors fail with persistent "Connection Required" loop on ALL published channels (Teams, Demo Website) despite working perfectly in Preview

Summary

Three custom MCP tools added to a Copilot Studio agent via the standard MCP onboarding wizard work perfectly in the Preview/test canvas, but fail with a persistent, non-recoverable "Connection Required" loop on every published channel tested (Microsoft Teams and the built-in Demo Website channel). This reproduces identically across three connectors using three structurally different OAuth configurations, which points at the published-channel runtime itself rather than any single connector's auth setup.

Environment

• Copilot Studio agent using the standard MCP onboarding wizard (Tools → Add tool → Model Context Protocol)
• Three MCP tools configured:
  1. A self-hosted MCP server (OAuth 2.0 → Dynamic discovery, Dynamic Client Registration with a public/PKCE-only client, no client secret)
     1. Atlassian's officially-hosted Rovo MCP server (OAuth 2.0 → Dynamic discovery)
        1. Microsoft's officially-hosted Power BI MCP server (OAuth 2.0 → Manual, Entra app registration)
        • All three verified working correctly in Copilot Studio's own Preview/test canvas across dozens of test conversations

Steps to reproduce

1. Configure any MCP tool with OAuth 2.0 authentication (Dynamic discovery or Manual) via the MCP onboarding wizard.
2. Verify the tool works correctly in Preview.
3. Publish the agent to Teams (or toggle on the "Demo Website" channel).
4. Open the agent in the published channel and ask a question requiring the tool.
5. Observe: a "Connection Required" card appears — "This action requires a connection to [connector]. Set up your connection, then select Retry."
6. Click "Set up connection" → complete a full, successful OAuth sign-in for the underlying service.
7. Click "Retry" → the identical card reappears.

What was tried and ruled out

• Reconnecting the existing tool in Copilot Studio — no effect.
• Establishing a brand-new "end user access" connection via make.powerapps.com → Connections → Share → granting "Can use + share" to both the organization and the Copilot Studio service principal — no effect.
• Starting a completely fresh conversation (ruling out session/conversation-level caching) — identical failure on the very first message.
• Checked Power Platform admin center → Data policies (DLP) for the environment — empty, not a factor.
• Checked "Agent access channels" admin restrictions — not applicable; the channels were not blocked/grayed out.
• Checked whether this matches the documented "missing Entra Agent ID Runtime.All permission" issue affecting first-party connectors in Teams — does not apply per Microsoft's own documentation, which states this mechanism explicitly excludes "custom connectors, MCP servers, and REST API tools," and that its enforcement is Teams-specific — but this reproduces identically on the Demo Website channel too.
• Inspected the connector definitions directly via pac connector download — no unusual capabilities, policies, or security definitions found; identity provider is oauth2pkcewithprm.

Why this looks like a platform issue, not a configuration issue

The failure is identical across three connectors with three different hosting models (self-hosted, and two different vendor-hosted patterns) and two different OAuth configuration types (Dynamic discovery, Manual). The one constant across all three is that they are custom MCP tools rather than first-party/certified Power Platform connectors — and Copilot Studio's own connectivity documentation confirms MCP tools currently receive different (and apparently incomplete) treatment for published-channel authentication compared to first-party connectors.

Impact: any agent built with custom MCP tools appears unable to be demonstrated or used through a published channel (Teams, Demo Website) at all — only the maker-facing Preview canvas works, which significantly limits real-world usability of MCP tools in Copilot Studio for anyone not the agent's own maker.

Happy to provide additional diagnostic detail (connector definitions, exact error text, environment ID) via a private channel if that helps investigate further.Summary

Three custom MCP tools added to a Copilot Studio agent via the standard MCP onboarding wizard work perfectly in the Preview/test canvas, but fail with a persistent, non-recoverable "Connection Required" loop on every published channel tested (Microsoft Teams and the built-in Demo Website channel). This reproduces identically across three connectors using three structurally different OAuth configurations, which points at the published-channel runtime itself rather than any single connector's auth setup.

Environment

• Copilot Studio agent using the standard MCP onboarding wizard (Tools → Add tool → Model Context Protocol)
• Three MCP tools configured:
  1. A self-hosted MCP server (OAuth 2.0 → Dynamic discovery, Dynamic Client Registration with a public/PKCE-only client, no client secret)
     1. Atlassian's officially-hosted Rovo MCP server (OAuth 2.0 → Dynamic discovery)
        1. Microsoft's officially-hosted Power BI MCP server (OAuth 2.0 → Manual, Entra app registration)
        • All three verified working correctly in Copilot Studio's own Preview/test canvas across dozens of test conversations

Steps to reproduce

1. Configure any MCP tool with OAuth 2.0 authentication (Dynamic discovery or Manual) via the MCP onboarding wizard.
2. Verify the tool works correctly in Preview.
3. Publish the agent to Teams (or toggle on the "Demo Website" channel).
4. Open the agent in the published channel and ask a question requiring the tool.
5. Observe: a "Connection Required" card appears — "This action requires a connection to [connector]. Set up your connection, then select Retry."
6. Click "Set up connection" → complete a full, successful OAuth sign-in for the underlying service.
7. Click "Retry" → the identical card reappears.

What was tried and ruled out

• Reconnecting the existing tool in Copilot Studio — no effect.
• Establishing a brand-new "end user access" connection via make.powerapps.com → Connections → Share → granting "Can use + share" to both the organization and the Copilot Studio service principal — no effect.
• Starting a completely fresh conversation (ruling out session/conversation-level caching) — identical failure on the very first message.
• Checked Power Platform admin center → Data policies (DLP) for the environment — empty, not a factor.
• Checked "Agent access channels" admin restrictions — not applicable; the channels were not blocked/grayed out.
• Checked whether this matches the documented "missing Entra Agent ID Runtime.All permission" issue affecting first-party connectors in Teams — does not apply per Microsoft's own documentation, which states this mechanism explicitly excludes "custom connectors, MCP servers, and REST API tools," and that its enforcement is Teams-specific — but this reproduces identically on the Demo Website channel too.
• Inspected the connector definitions directly via pac connector download — no unusual capabilities, policies, or security definitions found; identity provider is oauth2pkcewithprm.

Why this looks like a platform issue, not a configuration issue

The failure is identical across three connectors with three different hosting models (self-hosted, and two different vendor-hosted patterns) and two different OAuth configuration types (Dynamic discovery, Manual). The one constant across all three is that they are custom MCP tools rather than first-party/certified Power Platform connectors — and Copilot Studio's own connectivity documentation confirms MCP tools currently receive different (and apparently incomplete) treatment for published-channel authentication compared to first-party connectors.

Impact: any agent built with custom MCP tools appears unable to be demonstrated or used through a published channel (Teams, Demo Website) at all — only the maker-facing Preview canvas works, which significantly limits real-world usability of MCP tools in Copilot Studio for anyone not the agent's own maker.

Happy to provide additional diagnostic detail (connector definitions, exact error text, environment ID) via a private channel if that helps investigate further.