Connecting MCP Servers to Copilot Studio: Lessons From Real Deployments

By Kaustubh Giri, Sr Solution Engineer. ~12 min read.

“The MCP server connects, the tools show up, but every call fails. What are we doing wrong?” I’ve heard some version of this from several customers this year. It’s a common point of confusion, and in my experience the cause is almost never the protocol itself. It’s usually authentication and connections.

Adding an MCP server to a Copilot Studio agent takes a few minutes. Getting it to work for every user, with the right permissions and inside your governance rules, takes more planning. Here’s how I approach it.

A quick caveat: MCP support in Copilot Studio is changing quickly. Everything below reflects Microsoft Learn as of October 2026. Some pieces, like bring-your-own MCP registration, are still in preview. Check current docs before you build production plans on them.

In this post:

1. What MCP is, in one paragraph
2. Two ways to add an MCP server
3. Authentication options
4. End-user vs maker-provided credentials
5. Entra ID tokens: audience and scopes
6. “Tools are discovered, but calls fail”
7. Governance: DLP, ACP, and consent
8. How I test an MCP integration
9. Troubleshooting checklist

1. What MCP is, in one paragraph

Model Context Protocol (MCP) is an open standard that lets an AI client discover and call tools hosted by a separate server. The server describes each tool, including its name, description, inputs, and outputs, and the client decides when to call it. In Copilot Studio, every tool and resource a connected server publishes shows up in your agent automatically, and changes on the server are reflected without you re-importing anything. Copilot Studio currently supports MCP tools and resources, not prompts, and you need generative orchestration turned on. One more thing that matters later: under the hood, Copilot Studio reaches MCP servers through the Power Platform connector framework. That’s why connections, credentials, and data policies all apply.

The takeaway: An MCP server in Copilot Studio is a connector. If you already know how connectors, connections, and DLP behave, you already understand most of what can go wrong.

2. Two ways to add an MCP server

Microsoft documents two paths for an existing server, plus a governed registration path that’s in preview. Here’s how I think about them.

Path	Status (Oct 2026)	When I use it
MCP onboarding wizard (Tools -> Add a tool -> New tool -> Model Context Protocol)	Recommended path	Most cases. You enter a name, description, URL, and authentication type, then create a connection. It creates a custom connector for you in the background.
Custom connector in Power Apps (import an OpenAPI YAML)	Supported	When you need full control over the connector definition, custom parameters, or security settings. The schema marks the endpoint with the streamable MCP protocol extension.
Built-in / certified MCP servers	Available · New certification process in preview	When a Microsoft or partner server already exists in the catalog. Certification goes through the Microsoft connector certification program.
Bring your own (BYO) MCP via Agent 365 CLI and Microsoft 365 admin center	Preview	Internal servers you want IT to approve, govern, and observe centrally. Once registered and approved, the server becomes available in Copilot Studio.

Transports: streamable HTTP only

This one catches teams who built their server from an older sample. Copilot Studio supports the Streamable transport. SSE was deprecated in the MCP spec, and Copilot Studio stopped supporting SSE for MCP after August 2025. If your server only speaks SSE, update it before you spend time on anything else.

My tip: Write the server description carefully. The orchestrator uses it to decide whether to call your server at all. A vague description shows up as “the agent never uses my tool,” which looks like a connection problem but isn’t.

3. Authentication options

The wizard offers three choices. Pick based on what the server supports and whose identity should reach the back end.

• Option 1: None - Fine for public, read-only data like documentation search. Don’t use it for anything that returns business data or performs actions.
• Option 2: API key - Sent in a header or query parameter. Simple, but a key identifies an application, not a person. The back end can’t tell which user is asking.
• Option 3: OAuth 2.0 - Three flavors: Dynamic discovery (server supports dynamic client registration with discovery), Dynamic (registration without discovery, you supply endpoints), and Manual (client ID, secret, authorization, token, and refresh URLs, plus optional scopes).

With Dynamic or Manual OAuth, Copilot Studio gives you a callback URL after you select Create. Copy it into the redirect URIs of the app registration in your identity provider. A missing or wrong redirect URI is one of the most common reasons sign-in fails.

If each user should act with their own permissions, OAuth 2.0 with the authorization code flow is the only option of the three that gets you there.

4. End-user vs maker-provided credentials

Once you’ve chosen an authentication type, you still have to decide whose credentials the connection uses at runtime. Copilot Studio gives you two models.

	End-user (user) credentials	Maker-provided credentials
Whose identity	Each signed-in user	The maker’s connection, shared by everyone
First use	User sees a connection or consent card and signs in	No prompt for users
Access control	Back end enforces each user’s own permissions	Every user can do whatever the maker can do
Audit trail	Actions logged as the real user	Actions logged as the maker
Autonomous / scheduled agents	Need a live user. Background runs fail.	Works without a user present
Good fit	Personal or permissioned data, any write action	Low-risk, shared lookups (for example, a weather API or support phone numbers)

Microsoft is explicit about the risk: with maker credentials, an end user might retrieve information or take actions that only the maker’s account is allowed to. Admins can now control this per environment or environment group, under Control maker credential options in the Power Platform admin center, and allow end-user credentials, maker-provided credentials, or both.

From the field: A software customer connected their work-tracking tool’s MCP server to an agent. The server initialized and the tools were discovered, but creating an issue only worked when we switched the connection to maker-provided credentials and turned off the user prompt. That got them unblocked, but I told them I wasn’t comfortable leaving it there. Every user was effectively acting as the maker, which bypassed user-level access control and made the audit trail meaningless.

The root cause was the authentication model. They were using an API token, which behaves like a static service credential, not a signed-in user. When we switched to end-user credentials, there was no real user token to pass through, so the calls failed. What I recommended was moving to OAuth 2.0 with the vendor’s three-legged (authorization code) flow, with refresh-token support and the Copilot Studio callback URL registered as the redirect. As a fallback, I suggested a small middleware service that manages per-user tokens. In my own testing I could only get it working with maker credentials, through either OAuth or the API key. Support later traced the delegated failure to the platform’s token-exchange layer, and after a product fix shipped, OAuth with end-user credentials worked.

What I recommend: Use maker-provided credentials only as a temporary, documented exception for low-risk tools. For anything that writes data or returns user-specific data, design for end-user OAuth from day one, and get conversation IDs and a support case open early if delegated calls fail.

5. Entra ID tokens: audience and scopes

If your MCP server is protected by Microsoft Entra ID, most failures come down to a token the server won’t accept. When I first meet a team in this situation, these are the questions I ask:

1. What kind of MCP server is it, and which identity provider does it trust today?
2. Is it set up to validate tokens issued by Entra ID, or does its trust configuration need to change?
3. If user sign-in already works somewhere else, which identity provider was used there?
4. When Copilot Studio calls it, do the server logs show no token or the wrong token?

From the field: Those four questions came straight from an email I sent to a design software company that was trying to bring its own MCP tool into an agent. Asking them early saved a lot of time. “No token” points to the connection or credential model. “Wrong token” usually points to audience, scope, or tenant settings.

For a wrong-token problem, here’s what I check:

• Audience. The token’s audience must match what the server expects, typically the Application ID URI or client ID of the app registration that protects the server.
• Scopes. The server’s app registration exposes a scope, and the connector’s app registration has that delegated permission with consent granted.
• Two app registrations. One represents the server, and one represents the connector with its own client secret. Mixing them up is common.
• Redirect URI. The callback URL from Copilot Studio is registered on the connector’s app.
• Wizard-created connectors. The wizard creates a custom connector in the background. For Entra ID single sign-on, Microsoft’s Power CAT guidance is to finish the wizard first and then edit the custom connector’s security settings.

Watch for this: SSO that works for the maker but fails for the second user is a classic sign of a missed setup step. It’s commonly the Azure API Connections service not being added as an authorized client, or the connector not being shared with users in the environment. Always test with a second, non-maker account.

6. “Tools are discovered, but calls fail”

This symptom is confusing because discovery succeeding feels like proof that everything works. It isn’t. Discovery and invocation can use different credentials and code paths, and a tool showing up doesn’t mean the caller has permission to run it. Here’s how I narrow it down.

What you see	What I’d check first
Works with maker credentials, fails with end-user credentials	Is the auth method truly delegated? API keys and service tokens can’t represent a user. Move to OAuth authorization code.
Works for the maker, fails for everyone else	Connector sharing, users existing in the environment, Entra authorized clients, user connection creation
Fails before reaching your server (nothing in server logs)	Connection, consent, token exchange, or a data policy. Capture conversation IDs and open a support case.
Server returns 401 or 403	Token audience, scopes, tenant, and the user’s permissions in the back-end system
Fails only for a brand-new user	Whether the user exists in the back-end system yet. In one test, a call failed because the account had only just been registered. Retrying later worked.
A specific tool is missing from the list	Known schema issues: reference-type inputs get filtered out, and multi-type type arrays get truncated. Use a single type per field.
Agent never calls the tool	Server and tool descriptions, agent instructions, generative orchestration turned on
Fails in Teams but works in the test pane	Teams SSO configuration. Without it, user authentication for tools fails in Teams.

7. Governance: DLP, ACP, and consent

Because MCP goes through Power Platform connectors, your existing data policies apply. If a data policy restricts connectors, it also restricts the MCP server and its tools for your agent.

Advanced Connector Policies (ACP)

Generally available · PPAC -> Security -> Data and privacy · or environment group rules

A default-deny allowlist for certified connectors. MCP servers appear alongside other connectors.

What to know:

1. You can block an entire MCP server. Per-tool control inside a server isn’t available yet.
2. ACP covers certified connectors only. Custom connectors, including the ones the MCP wizard creates, are still governed by classic data policies.
3. Start in mixed mode so classic policies keep working while you curate the allowlist.

Maker credential controls

Available · PPAC -> environment -> Features -> Copilot Studio agents

Lets you allow end-user credentials, maker-provided credentials, or both. If you block maker credentials, agents that run on schedules or in the background will fail, so check which agents depend on them before you switch it on.

Connector consent bypass

Check current docs · Power Platform API · per agent

By default, the first time an agent uses a connector on a user’s behalf, it shows a consent card. Admins can bypass those cards for a specific agent through the Power Platform API. It requires an admin role, an app registration with the right delegated permission, and a PowerShell script.

From the field: A cybersecurity company asked me how to stop users from seeing repeated consent prompts for tools. At the time I remembered the product team working on an admin option and promised to confirm. The documented answer now is the per-agent consent bypass setting. I’d still treat consent as a feature, not a bug. It’s the user agreeing to let the agent act for them. Bypass it only for agents your security team has reviewed.

For a broader view of environment strategy and DLP, see my post on environment strategy and DLP. For the full admin toolbox, including Inventory’s connector column, see the 2026 governance toolbox.

8. How I test an MCP integration

Step 1: One tool, one user

• Pick a single read-only tool
• Test in the Copilot Studio test pane as the maker
• Confirm the call reaches your server logs

Step 2: Real identities

• Switch to end-user credentials
• Test with a second, non-maker account
• Then add write tools, one at a time

Step 3: Real channels

• Publish to the target channel (Teams, M365 Copilot, web)
• Repeat the second-user test there
• Check DLP or ACP behavior in the target environment

When something fails, collect evidence before changing settings:

• Type /debug conversationid in the chat for a custom agent to get the conversation ID. Capture one for a working scenario and one for a failing scenario.
• In the test pane, save a snapshot of the failing conversation. It includes the orchestration trace and tool calls. Redact it before sharing.
• Note the authentication type, the credential model, the channel, and the exact time of the failure.
• Open a support case with all of the above. In the case I described earlier, support traced the problem only after we provided conversation IDs from both the working and failing configurations.

9. Troubleshooting checklist

#	Check	What good looks like
1	Transport	Server uses streamable HTTP, not SSE
2	Generative orchestration	Turned on for the agent
3	Server and tool descriptions	Clear, specific, and matched to how users phrase requests
4	Tool schemas	Single type per field, no reference-type inputs
5	Authentication type	OAuth 2.0 authorization code for anything user-specific
6	Callback URL	Registered as a redirect URI with the identity provider
7	Credential model	End-user credentials, unless a reviewed exception exists
8	Entra token	Correct audience, exposed scope, delegated permission consented
9	Second-user test	A non-maker account can connect and call the tool
10	Back-end account	The user exists and has permissions in the target system
11	Data policies	Connector allowed by classic DLP and, if used, ACP
12	Channel	Teams SSO configured if the agent is published to Teams
13	Evidence	Conversation IDs for working and failing runs, snapshot saved

Where I’d start

Pick one MCP server and one read-only tool. Connect it with the wizard over streamable HTTP, choose OAuth 2.0 with end-user credentials, and test with a second user before you add anything else. Agree with your admins up front on which data policies and credential controls apply. If something fails, get conversation IDs before you start changing settings.

Happy to go deeper on any of this.

K.G.

Sources

• Microsoft Learn: Extend your agent with Model Context Protocol (updated Aug 2026)
• Microsoft Learn: Connect your agent to an existing Model Context Protocol (MCP) server (updated May 2026)
• Microsoft Learn: Troubleshooting Model Context Protocol (MCP) integration (updated Aug 2026)
• Microsoft Learn: Microsoft MCP server certification; Built-in MCP servers catalog
• Microsoft Learn: Bring your own (BYO) MCP server in Microsoft 365 admin center (preview)
• Microsoft Learn: Configure user authentication for tools; Control maker-provided credentials for authentication
• Microsoft Learn: Bypass connector consent cards for an agent
• Microsoft Learn: Advanced connector policies (updated Sep 2026)
• Power CAT blog (The Custom Engine): “Seamless SSO with Custom Connectors”; “How to Get Your Conversation ID When Chatting with Agents”

---

Statuses reflect publicly available information as of October 2026. Preview features may change. Customer examples are anonymized.

Get new posts by email

Email addressSubscribe

Provider: your email provider