Stop Clicking Through Run History: Build Your Own MCP to Debug Power Automate Flows

Watch the session

About this session

A flow failed overnight. Finding out why means six clicks: open the flow, run history, the failed run, the red action, the error, then walk upstream to find the value that caused it. The API is worse. The run says "An action failed", and for connector failures the action record carries error: null, because the real message sits behind a short-lived signed link. Generic API wrappers hand the model that same dead end. This session builds a Power Automate MCP server that follows those links, pairs the failure with the outputs of the actions that ran before it, and hands an agent enough context to explain the cause in words. Wrapping the API is commodity: auth and transport are under a hundred lines. The value sits above it, in shaping the payload for the model and in docstrings that encode every trap you only want to hit once. We run the whole loop live, build, run, debug and fix, against a Dataverse sales digest that breaks on Sunday, and I only type prompts.

Inside the demo

• The scenario: every morning a store manager gets revenue, staff on shift and revenue per staff member by mail, read live from the Account table in Dataverse. On Sunday the Lausanne store was closed, so staff is 0 and the KPI divides by zero.
• Build and connect: Claude creates the flow from workflow-definition JSON. The Dataverse connection is created live in the portal, because connections are OAuth and no API can create one. Claude then binds every connector and starts the flow.
• Run: the flow fails, and the Power Automate API only says "An action failed". That is the WHAT, and it is where a naive wrapper stops.
• Debug: explain_run reads the run actions, follows the signed link that hides the connector error, and pairs the failure with the upstream output: Get_store returned numberofemployees: 0. The answer names the cause, not the symptom, in one call instead of about twelve clicks.
• Fix: Claude changes the logic so a closed day still sends the digest, updates the definition while keeping the connection bindings, reruns it, and the mail lands in the inbox.
• The four layers: auth (about 45 lines) and transport (about 50) are commodity that Claude writes in one prompt. Shaping (about 160 lines, sixty API fields down to the few that matter) and docstrings (about 200 lines, what the API will never tell the model) are the work you actually own.
• Hard-won lessons, encoded: error: null on connector failures; the two magic parameters $connections and $authentication, without which you get a 400 that wrongly blames the trigger; bind every connector at once or the flow cannot start or even save; a bare Button trigger schema that crashed the new designer; no secrets in definitions, because they are stored in plain text.
• Why build your own: measured on 17 August 2026 against the same failed run, Microsoft's 56-tool flowagent server returned an empty error message on a connector failure, while explain_run returned the 404 text, the failing action's inputs and the upstream value, and compare_runs diffed it against a good run. Microsoft's plugin is broader: use it. Build your own for the one question that keeps costing you hours.
• Microsoft Learn MCP sits next to it, so the model looks up connector operationIds and parameter schemas instead of guessing them. Two skills in the repo, build-flow and debug-flow, teach the loop across tools.

Prompts to try

The first three are the prompts typed live in the demo. The rest are the examples from the repository. Point the server at a test environment and start here:

• ›We are building a daily sales digest for a store manager. Create the flow, bind the existing connections and start it. Explain what each step does and what you had to do to make a connector flow work headlessly.
• ›It is Monday morning, and on Sunday the Lausanne store was closed. Run the flow. Tell me the result and exactly what the Power Automate API itself says about it.
• ›Why did it fail? Explain which action failed, the upstream value that caused it, and what I would have had to click through in the portal to find that out. Then fix it so a closed day still sends the digest, run it again, and explain why the change is safe.
• ›List my flows.
• ›This flow works most days. Why did it fail last night?
• ›Create a flow from demo-flow.json and run it. It is meant to fail: then ask why.

Build it yourself

1. 1

   Clone it and install the dependencies

   Python 3.10 or newer. The server is a single server.py built on the MCP Python SDK (FastMCP) with httpx and python-dotenv. git clone the repo, then pip install -r requirements.txt. Or hand the repo to your favourite vibe coding platform and let it do the setup for you.

   The repository→
2. 2

   Borrow a token instead of registering an app

   Install the Azure CLI and run az login. The server calls az account get-access-token for the Flow resource and reuses that session. No app registration, no secret, no admin consent. If your az is signed in to more than one tenant, pin the right one with PA_TENANT_ID in a .env file: the server fails loudly anywhere else.

   Prerequisites in full→
3. 3

   Point your MCP client at server.py

   Stdio transport, so the client starts the server as a local child process: nothing to host and no token on the wire. In Claude Code, add a power-automate entry to .mcp.json with command python and the absolute path to server.py, and optionally microsoft-learn at https://learn.microsoft.com/api/mcp so connector operations are looked up rather than guessed.

   Client configuration→
4. 4

   Use a test environment. It acts as you.

   Create, edit and run are live, with no confirmation step, and it can change anything you can. There is deliberately no delete tool in the core server. For production, split read tools and write tools into two servers. The live demo runs in an MVP tenant, never a client's.

   Security notes→
5. 5

   Break something on purpose

   The repo includes demo-flow.json, intentionally broken: Load_settings emits batch_size: 0 and Compute_batches divides by it. Run it, ask what happened, and watch explain_run surface the upstream output that caused it. Then ask for the fix and let compare_runs confirm what changed.

   The demo flow→
6. 6

   Every bug you hit twice belongs in a docstring

   The docstrings are the prompt the model reads before every call. The debug-and-fix loop happens without step-by-step instructions because each tool says what it is for and which trap it avoids. The code is regenerable; that knowledge is the asset.

   Gotchas this server encodes→

Slides

Download the deck (PDF) ↓

Resources