How to Connect a Custom MCP Server to Copilot Studio to Debug Power Automate

Copilot Studio supports custom MCP servers as tools. This post shows how to connect Flow Studio MCP to a Copilot Studio agent so it can debug Power Automate flows at the action level: read per-action error breakdowns, inspect action inputs and outputs including loop iterations, and trace root causes back to source data. Five-step setup inside Copilot Studio, no code. Includes a real debug session with every MCP tool call visible on screen.

Microsoft 365 Copilot, calling get_live_flow_runs on a real Power Automate flow. Inspecting action inputs and outputs at the trigger level. Printing a per-flow verdict table that traces root causes back to the source data.

This is not a standard Copilot Studio capability. Plain Copilot Studio has no action-level visibility into Power Automate. Microsoft shipped Model Context Protocol (MCP) server support in Copilot Studio (public preview March 2025, generally available May 2025 at Build), so you can plug in a custom MCP server and give the agent exactly the tools it's missing. The one in this post is Flow Studio MCP, a Power Automate MCP server I built. It exposes about 15 tools covering environments, flow definitions, run history, action inputs and outputs, connections, and deploy operations.

This post covers three things. First the 5-step setup inside Copilot Studio. Then a real debug session with the tool calls visible. Then what your end users see once the agent is published to the Microsoft 365 Copilot app on their machine.

Setup (5 steps, ~5 minutes)

Full walkthrough: getting-started guide. Short version for Copilot Studio:

1. Open copilotstudio.microsoft.com, create or open an agent, go to Tools.
2. Click + Add a tool, pick Model Context Protocol from the Create new row.
3. Fill the form: Server URL https://mcp.flowstudio.app/mcp, Authentication = API key, Type = Header, Header name = x-api-key (lowercase with hyphen). Click Create.
4. In the Test pane, send "List my Power Platform environments." Paste your API key from the dashboard when prompted.
5. Click Publish, pick Microsoft Teams and Microsoft 365 Copilot channels.

The MCP server form. Header name x-api-key (lowercase with hyphen) is the most common setup mistake.

API key is free to try (100 calls, 21 days, no credit card). Details including the test step and the x-api-key gotcha: getting-started guide.

A real debug session with the tool calls visible

I tested this on a Power Automate flow I actually use. It's an RSS monitor that pulls from four feeds: r/PowerAutomate, r/PowerApps, r/CopilotMicrosoft, and the Stack Overflow power-automate tag. Four parent flows, one per feed. When a post mentions a keyword I care about, the flow pings me. I use it to find Power Automate questions worth answering.

This week a few of the parent flows went quiet. No new posts surfaced. So I opened the Copilot Studio test pane (which shows the agent reasoning trace, unlike the production M365 Copilot app which hides it) and typed one prompt:

Some of the parent flows have not been triggered. It could be that the RSS URL is incorrect. Can you investigate?

The agent worked through the investigation in three stages, with every MCP tool call visible in the reasoning sidebar:

1. Called list_live_environments and returned a list of 9 Power Automate environments connected to my tenant. Asked me which one to investigate. I picked Flow Studio Default.
2. Called list_live_flows to filter by name and find the Forum Monitor parent flows. Then called get_live_flow on each one to read the RSS trigger configuration.
3. Called get_live_flow_runs per parent flow to pull the recent run history and build a verdict table.

Then it printed a table, one row per parent flow. The working ones looked like this:

rPowerAutomate: 1 feed item processed, last run Apr 10 17:08 UTC. Working fine.

rCopilotMicrosoft: 2 feed items processed, last run Apr 10 17:08 UTC. Working fine.

Stack Overflow power-automate: 1 feed item processed, last run Apr 10 01:47 UTC. Working fine.

The agent then flagged three issues across the other flows:

1. Reddit Index Monitors: private authenticated RSS feed. The RSS URL pointed to a private Reddit feed requiring an OAuth token. The RSS connector does not support authenticated requests, so the trigger never fired. The agent recommended switching to the Reddit API with OAuth.
2. Stack Overflow: wrong tag in the RSS URL. The feed was pulling from the power-automate tag, but the primary Stack Overflow tag is microsoft-power-automate. The wrong tag had very few questions, explaining why the flow only ran once in three days. The agent offered to update the URL to the correct tag.
3. YouTube Reps: possibly inactive channel. The RSS URL format was technically correct, but YouTube throttles RSS from server-side scrapers, and the channel may not have published new videos since the flow was created.

Three different root causes, each traced from the run history into the trigger configuration and back to the source. The Stack Overflow finding was the most subtle: the agent cross-referenced the RSS feed tag against actual Stack Overflow tagging conventions and found a mismatch that a manual inspection would likely have missed.

The Copilot Studio test pane showing MCP tool calls (get_live_flow, get_live_flow_runs) in the reasoning sidebar alongside the verdict table.

Three MCP tools, three pieces of the puzzle, one conversation, about 30 seconds of real work. Without this, tracking down which parent flows were silent would have meant opening the Power Automate portal, switching into each of my 9 environments, filtering by flow name, checking run history by hand on every parent flow, opening each trigger configuration, and eyeballing the RSS URL. Probably 20 minutes of clicking for a 30-second diagnosis.

What end users see in the Microsoft 365 Copilot app

The debug session above happened in the Copilot Studio test pane, which is where makers verify the agent works before publishing. The test pane shows every tool call in the reasoning sidebar so you can watch the agent work.

End users don't see the test pane. They see the published agent inside the Microsoft 365 Copilot desktop app: same agent, same prompts, same answers, different surface. The tool calls still run under the hood, but the reasoning sidebar is hidden by design to keep the experience conversational. What the user gets back is the verdict table and the root cause, inside the same Copilot chat they already have open.

No separate app to install. No browser tab to switch to. The Microsoft 365 Copilot app is available to M365 Copilot license holders. Once the agent is published to your tenant, it's one click away in the Agents section of the left rail.

Why this matters

Copilot Studio's built-in tools are great at what they're designed for: querying tenant data, answering employee questions, working with connectors. They weren't designed to debug Power Automate flows at the action-input level. That's a different problem and it needs a different tool.

MCP is how you add that tool without writing custom code. You point the Copilot Studio agent at an MCP server, the agent discovers the tools the server exposes, and Copilot calls them whenever a user's question needs them. The difference between plain Copilot and the demo above isn't intelligence. It's visibility. The visibility comes from the tool, not the model.

And this isn't a Flow Studio-specific story. Any custom MCP server works the same way. If you've built an internal API that your team wishes Copilot could call, you can wrap it as an MCP server and plug it in the same way I plugged in Flow Studio MCP. The work Microsoft did with MCP support unlocks a lot of doors.

What Copilot Studio can see through Flow Studio MCP

To give you a sense of what becomes available to your Copilot users the moment you connect the server:

The additive framing

There's been a lot of chatter lately about what Copilot Studio "can't do" for Power Automate. Some of it is fair criticism. Most of it misses the point that Microsoft built the extension hook on purpose. MCP support is the mechanism for plugging in exactly the capabilities the built-in agent doesn't have.

The story isn't "Copilot Studio is bad at Power Automate, use something else." The story is "Microsoft shipped the extension point, and here's what you can plug into it." Flow Studio MCP is one option. The pattern works for any MCP server.

Marcel Broschk said it well in his recent Featured post: "Claude + Microsoft is not a battle of brands. The future is Claude AND Microsoft used intentionally." I think the same applies here. The interesting work happens at the intersection.

Try it in your tenant

If you want to try this in your own tenant this afternoon:

1. Get a Flow Studio MCP API key at mcp.flowstudio.app. Starter plan is free, 100 calls included, no credit card.
2. Follow the Copilot Studio section of the Getting Started guide, or just replay the 5 steps above.
3. Publish the agent to your tenant. You decide who has access via the normal Copilot Studio permissions.
4. Test with a real flow. Ask the agent about any flow you want to understand and see what it returns.

About Flow Studio MCP: Flow Studio MCP is a Model Context Protocol server that gives AI agents action-level visibility into Power Automate. It's listed on GitHub's awesome-copilot, the awesome-copilot collection on GitHub. Works with Microsoft Copilot Studio, GitHub Copilot, Claude, and any MCP-compatible agent.

Related reading:

• Getting Started with Flow Studio MCP
• Debugging Power Automate Flows with an AI Agent
• The Dictionary Pattern for AI-Built Power Automate Flows

Catherine Han, Flow Studio