Power Automate MCP: Create, Run and Debug Flows from Chat

power-automate-mcp is a single-file MCP server that exposes 10 tools over the Power Automate management API. Point any MCP client at it and the model can list your flows, read a definition, create one, bind its connections, run it, and then explain why the run failed.

It authenticates through the Azure CLI session you already have, so there is no app registration, no admin consent, and no device-code dance. Sign in with az login, start the server, and the tools work against your default environment.

Run it as a stdio MCP server. That is the right transport here, and it falls straight out of how the server authenticates: it borrows the Azure CLI session already sitting on your machine, so it has to run as a local process next to that CLI. Your client launches it over stdio from a few lines of config, which means no hosting, no public endpoint, no tunnel, and no second auth layer to build. The token never leaves your machine.

The point is not that it wraps an API. The point is the debugging loop below, which the model drives on its own because the tools tell it what they are for.

The same block works in claude_desktop_config.json. Use an absolute path to server.py; the server resolves its .env relative to its own file, so the working directory does not matter.

Power Automate does not put the error message on the action record. When an action fails, the API hands you this:

error is null. The real message lives inside a blob behind that short-lived, SAS-signed URL. The maker portal follows the link for you, which is exactly why the portal shows a real error and a naive API wrapper shows you Failed and nothing else.

This is the gap that makes a generic HTTP wrapper useless for debugging, and it is the reason this server exists.

explain_run does 2 things a wrapper does not:

1. It follows the link. For every failed action it fetches the outputs blob and digs the message out, so the model receives resolved error text rather than null.
2. It supplies upstream context. A failure is rarely explained by the failing action alone. The cause is almost always in what an earlier action produced, so the response pairs each failed action with the outputs of the actions that succeeded before it, in execution order.

The result is that symptom and cause arrive together. Compute_batches is where the run died, but Load_settings is where the problem was.

One tool call, in place of roughly a dozen clicks through the run history view. 2 companion tools cover the cases where the error is clear but the reason is not: compare_runs diffs a failed run against a working baseline to find the point of divergence, and analyze_flow_health samples the last 50 runs to tell you whether a flow is flaky or genuinely broken, and which action is responsible.

Every useful MCP server is 4 layers, and only 2 of them are interesting. The whole server is one file, kept that way so it can be read top to bottom in a few minutes, with the layers appearing in order.

Layer 1, auth. Getting the token is one shell call against a Microsoft first-party app the tenant already trusts. Change the resource constant and the same 3 lines authenticate against Microsoft Graph, Dataverse, or Azure Resource Manager.

Layer 2, transport. One request helper covering the 4 things that always come up: a single 401 retry with a force-refreshed token, 429 with Retry-After honoured, exponential backoff on 503 and 504, and terminal errors re-raised carrying the API's own message, because the model can frequently act on it directly.

Layer 3, shaping. Where the judgement lives. list_flows returns 4 fields per flow where the API returns about 60, mostly GUIDs and internal plumbing. The rule of thumb: if you would not read the field while debugging, the model does not need it either.

Layer 4, docstrings. The docstrings are not documentation for humans, they are the prompt the model reads to decide what to call and how. They carry what each tool returns, which field feeds which other tool, the API's non-obvious constraints, and what each failure mode actually means.

10 tools in 3 groups, sized to cover a complete loop: author, bind, run, diagnose.

Each of these cost real hours to discover once. Each is now written into the relevant docstring, so the model sees it at call time and nobody pays for it again.

• Connector flows need 2 magic parameters. If any trigger or action is an OpenApiConnection variant, the definition must declare $connections and $authentication at top level. Omit them and creation fails with an HTTP 400 blaming the trigger, which sends you hunting in entirely the wrong place. There is no trigger-versus-action asymmetry; both fail identically. They are harmless on connector-free flows, so always include them.
• Creating a flow does not bind its connections. A 201 Created gives you a flow whose connectionReferences is empty and which cannot be turned on. Passing connection references on the create call does not help; the service rewrites them into a solution-style binding that stays unstartable. The working sequence is create, then update the definition with the references, then start. bind_connection collapses all 3 into one call.
• Portal-bound and solution flows cannot be updated through this API. The call succeeds and changes nothing. Edit those in the maker portal.
• Look connector operationIds up rather than guessing them. The docstrings say so explicitly, because a guessed operationId produces a flow that creates cleanly and fails at runtime.

Docstrings teach the model one tool at a time. They cannot teach it the loop: which tool to reach for first, when to move to the next one, and when to stop. That knowledge lives one layer up, in skills, which are markdown playbooks a coding agent loads when the task matches.

2 ship with the repo. debug-flow encodes the diagnose loop: list_runs, then explain_run, then compare_runs when the error is clear but the cause is not, then analyze_flow_health when it recurs, then fix and verify. build-flow encodes the authoring sequence: the definition rules, create then bind then start, and closing the loop with a run after every change.

The division of labour mirrors the 4 layers. Put per-tool constraints in the docstring, put cross-tool workflow in a skill. When the model gets a single call wrong, fix the docstring. When it picks the wrong tool or gives up too early, fix the skill.

This is a teaching artifact rather than a complete client. Environment discovery, solution-bound flow editing, HTTP trigger URL retrieval, resubmit and cancel, desktop flows and approvals are all left out on purpose. 10 tools is about the number that fits in a talk while still covering a real loop.

The production server this was extracted from runs 21 Power Automate tools alongside Microsoft Graph and Teams, and it is the same 4 layers throughout. Swap the base URL and the scope and the structure holds for Copilot Studio, Dataverse or Azure DevOps.