Forum Discussion
Platform Issue: Agent-Level MCP Initialization Blocks All Topics for Users Without Connection Access
I’m writing to report a significant platform behavior issue we’ve encountered with MCP (Model Context Protocol) server initialization in Copilot Studio that is severely impacting end-user experience.
ENVIRONMENT
• Platform: Microsoft Copilot Studio
• Deployment Channel: Microsoft Teams
• Agent Type: Custom Agent (EdiSENSE DEV)
• MCP Server: Atlassian Confluence-Jira MCP
• Affected Users: Users without Confluence/Jira access entitlements
PROBLEM SUMMARY
When an MCP server is registered at the agent level in Copilot Studio, it appears to be initialized globally before any topic routing occurs. If a user’s MCP connection is in a Not Connected state — even if their query has absolutely nothing to do with that MCP server - the agent gets stuck in an authentication loop, repeatedly prompting:
“Let’s get you connected first. Open connection manager to verify your credentials. Once the connection is ready, retry your request.”
The user is shown Retry / Cancel buttons, and the agent never proceeds to route the query to the appropriate topic.
STEPS TO REPRODUCE
1. Register an MCP server (e.g., Confluence-Jira) at the agent level in Copilot Studio
2. Deploy the agent to Microsoft Teams
3. Log in as a user who does NOT have access to the MCP-connected service (e.g., no Confluence license)
4. Ask the agent any question completely unrelated to the MCP service
5. Observe: Agent does not route to any topic. Instead, it loops on MCP connection prompt indefinitely
EXPECTED BEHAVIOR
• MCP initialization failure for a specific service should NOT block unrelated topic routing
• The agent should gracefully degrade - if an MCP connection is unavailable for a user, it should skip that MCP and continue routing the query to relevant topics
• There should be a way to scope MCP connections to specific topics, or at minimum, mark them as optional/non-blocking
ACTUAL BEHAVIOR
• Agent-level MCP initialization blocks the entire conversation flow
• Users without MCP access cannot use ANY functionality of the agent, even features completely unrelated to the MCP service
• There is no graceful fallback or bypass mechanism available to agent builders
BUSINESS IMPACT
This is a critical gap for enterprise deployments where:
• Not all users have access to every integrated service
• Agents serve a broad user base with varying entitlements
• Admins have no control over MCP initialization order or failure handling
In our case, a large portion of our Teams users are completely locked out of the agent’s core functionality simply because they don’t have a Confluence license - even though they never intended to use Confluence-related features.
FEATURE REQUEST / SUGGESTED RESOLUTION
1. Allow MCP servers to be scoped at the topic level, not just agent level
2. Introduce an optional flag for MCP connections so initialization failure is non-blocking
3. Provide agent builders with a connection status condition node in the topic flow to handle MCP failures gracefully
4. At minimum, allow the Cancel button in the auth prompt to fall through to normal topic routing
I’d appreciate any guidance on whether there is a current workaround, or if this is a known limitation on the roadmap for resolution.
Thank you for your time and support.
1 Reply
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.
