Platform Issue: Agent-Level MCP Initialization Blocks All Topics for Users Without Connection Access

Thanks for the detailed report, and yes, this is a real problem. Let me be straight with you about what is happening, what you can do today, and what you should expect from the platform.

When you register an MCP server at the agent level in Copilot Studio with OAuth 2.0 authentication, the platform attempts to establish the user connection before any topic routing takes place. It is not a bug in your configuration. It is how the current orchestrator works. The MCP server description is used by the agent to decide whether to call the tool, but the connection initialization itself happens upstream of that decision. So users who have no Confluence entitlement get stuck in the auth loop before the agent ever gets a chance to route their query elsewhere. You described it perfectly: it is a blocking, non-graceful failure with no escape hatch.

There is currently no native way to mark an MCP server as optional, scope it to a specific topic, or intercept the connection failure and reroute. The feature requests you listed are legitimate gaps, especially for enterprise deployments where license coverage is never uniform across all users.

The most practical workaround today is to split your architecture into two separate agents. One agent includes the Confluence/Jira MCP tool and is shared only with users who have the relevant entitlement. The second agent has no MCP dependency and serves the rest of your user base. You can use a routing mechanism at the Teams level, either through separate app deployments or by using the first topic in each agent to clarify its scope. It is not elegant, but it is the only way to fully isolate users from an MCP connection they cannot fulfill.

A second option is to remove the MCP server from the agent level entirely and instead wrap your Confluence/Jira calls inside a Power Automate flow. Flows give you explicit error handling, so if the external call fails because the user lacks access, you can return a clean message and let the conversation continue normally. The trade-off is that you lose the generative orchestration that makes MCP appealing and go back to more explicit topic-based routing.