Power Platform MCP: Flows and Copilot Studio Agents from Chat

power-platform-mcp (renamed from power-automate-mcp in November 2026) lets any MCP client build, run and debug your Power Automate flows, and build the Copilot Studio agents that use them. It is 3 small local servers, 28 tools in all: server.py, the 10-tool teaching core (author, bind, run, diagnose), extras.py with 9 more for real work (environments, start and stop, cancel, resubmit, solutions), and copilot_studio.py with 9 that read, export and edit agents, on the standard and the new GitHub Copilot harness.

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, ideally in a separate az profile for your demo tenant (AZURE_CONFIG_DIR), and the tools work against that tenant while your everyday az stays where it is.

Everything runs locally, over stdio. It borrows the Azure CLI session already on your machine, so it has to run as a local process next to that CLI. No hosting, no public endpoint, no second auth layer. Each colleague runs their own copy, signed in as themselves.

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 a connector action fails, the API hands you this:

There is no error property at all. The real message lives inside a blob behind that short-lived, 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. (Expression errors, like a divide by zero, are the exception: their message is inline. Connector failures are the case worth building for.)

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.

The core stays at 10 tools, the number that fits in a talk while still covering a real loop. The other 2 servers import its auth and transport, so they add tools without adding auth code.

Copilot Studio agents are Dataverse rows: a bots row, plus one botcomponents row per topic, tool, knowledge source and instruction set. So the same az session that runs flows edits agents too, with a token for the environment's org URL. copilot_studio.py adds 9 tools and no auth code.

The loop it exists for: Claude builds a flow, plugs it into an agent as a tool, rewrites the agent's instructions to use it, and publishes. Every step was run against a real tenant: instructions read and rewritten, the flow added as a tool, and the agent published successfully in about 30 seconds. Two guards are written into the tools because the platform does not raise them early enough: instructions containing curly braces are refused (Copilot Studio parses them as Power Fx and the agent then fails on every message), and so is a flow the agent cannot call.

Both harnesses. Copilot Studio now builds agents on two runtimes that store them differently: the standard harness keeps the instructions in a gpt.default component and the behaviour in topics, the new GitHub Copilot harness keeps the instructions in the agent's configuration and the behaviour in skills. Every tool reads the agent's template first and does the right thing for each. export_agent reads an agent in any environment, which is how a test agent gets rebuilt in production, and remove_agent_component cleans up what a new agent can start with, such as Work IQ write access to the user's mailbox, with a dry run first.

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. 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. bind_connection collapses the create, update and start sequence into one call.
• Solution flows cannot be updated through the Power Automate API. Flows built in the portal under My flows update fine; solution flows bind through Dataverse connection references, so extras.py edits their stored definition in Dataverse instead.
• Resubmit belongs to the trigger, not to the run. The obvious /runs/{run}/resubmit route is a 404; the real one is /triggers/{trigger}/histories/{run}/resubmit, and it only replays runs the service started.
• MCP SDK 2.x hides the text of any exception that is not a ToolError. Ported naively, every API message becomes a bare "Error executing tool". Every deliberate error here is a ToolError, and a test fails the build if that ever regresses.
• Look connector operationIds up rather than guessing them. 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 a procedure: 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: markdown files whose description tells the agent when to load them.

5 ship with the repo. debug-flow and build-flow encode the diagnose and authoring loops. agent-tool walks giving a Copilot Studio agent a new tool, end to end. dataverse-schema creates a publisher, solution, tables, columns and lookups from a short JSON spec. solution-from-base exports a solution with the Power Platform CLI (or takes a colleague's .zip), unpacks it, changes it by copying a block that already works, bumps the version, packs it and imports it back. Both Power Platform skills were run end to end against a real tenant before they were committed.

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.

The repo ships with an offline test suite (93 tests, run in CI on Windows and Linux), a 30-minute live demo script in English and French, and the explainer video above, generated from the narration file so that changing a sentence re-renders the captions and timings.

The production server this was extracted from runs 27 Power Automate tools alongside Microsoft Graph and Teams, and it is the same 4 layers throughout.