Build and Debug Power Automate Flows with MCP and GitHub Copilot CLI

Power Automate is usually treated as a visual development environment: open the designer, add a trigger, configure actions, test, and inspect run history when something breaks. That workflow remains useful, but it is no longer the only way to work.

Microsoft’s Power Platform Skills marketplace includes a Power Automate plugin for Claude Code and GitHub Copilot CLI. The plugin packages the FlowAgent Model Context Protocol (MCP) server, giving an AI coding agent tools to inspect environments, discover connector operations, create and edit flows, validate definitions, manage runs, and diagnose failures.¹

This is more than chat beside a designer. It is a tool-driven authoring loop in which the agent can inspect the platform, act on it, and use the result of one operation as context for the next. That makes the workflow relevant to both experienced developers and technically confident makers: developers gain a programmable, inspectable interface, while makers can express intent in natural language without losing access to the underlying flow and run history.

What MCP changes

A useful mental model is to separate the system into three layers:

1. The client is GitHub Copilot CLI or Claude Code. It hosts the conversation and decides which skill or tool to invoke.
2. The plugin supplies task-oriented skills such as build-flow, debug-flow, and route-environments.
3. The FlowAgent MCP server exposes the lower-level operations that read and modify Power Automate resources.

MCP is the tool contract between the agent and FlowAgent. Instead of asking a language model to invent a flow definition from memory, the client can call tools to list environments, inspect connectors, resolve dynamic values, validate a definition, publish a flow, and examine run details.

Think of the language model as the planner and FlowAgent as the instrument panel. The planner proposes the next move; the MCP tools provide platform-specific controls and return structured evidence about what actually happened.

That distinction matters. Natural-language generation is probabilistic, but environment IDs, connector parameter names, connection references, and run results are not. A reliable workflow uses the model for intent and orchestration while using MCP tools to retrieve exact platform data.

What the Power Automate plugin can do

The repository documents nine user-invocable skills:¹

Under those skills sits a broader tool surface. The plugin can list, get, create, edit, copy, update, publish, disable, and delete flows. It can also inspect run history and action details, cancel or resubmit runs, discover connectors, resolve dynamic values, validate definitions, perform preflight checks, and provide expression help.¹

The key point is that a skill is not the same as a single API call. A skill is an operating procedure. For example, guided flow creation can discover connector metadata, verify connections, resolve SharePoint or Teams values, generate the definition, validate it, create the flow, and run a smoke test.²

Guided versus autonomous authoring

The plugin exposes two complementary authoring styles:

• create-flow is guided. The agent gathers requirements, asks for decisions, presents the proposed design, and moves through creation step by step. Use it when the requirements are still taking shape or when you want a review checkpoint before creation.
• build-flow is autonomous. You provide a sufficiently detailed specification and allow the agent to orchestrate discovery, generation, validation, and deployment. Use it when the trigger, actions, mappings, destination, and expected result are already clear.

The same distinction applies to troubleshooting. debug-flow supports an interactive investigation, while diagnose-flow is intended for a deeper autonomous diagnosis. Autonomous does not mean unaccountable: inspect the resulting definition and run evidence before treating the flow as complete.

Prerequisites and supported clients

For the Power Automate plugin, the documented runtime requirements are:

• Node.js 18 or later
• Azure CLI authentication through az login
• Claude Code or GitHub Copilot CLI
• Access to the target Power Platform environment and the connections required by the flow¹

The plugin contains a self-contained MCP bundle. You do not need to install a separate npm package for the server. The included .mcp.json starts the bundled server/mcp.mjs process over standard input and output.¹

This distinction corrects a common source of confusion: the documented GitHub client for this plugin is GitHub Copilot CLI, not a separate GitHub Copilot desktop application. GitHub also supports MCP-based workflows in products such as Visual Studio Code, but this plugin’s own installation instructions explicitly target Copilot CLI and Claude Code.¹³

Install the marketplace and plugin

Inside a GitHub Copilot CLI or Claude Code session, add Microsoft’s marketplace and install the Power Automate plugin:

/plugin marketplace add microsoft/power-platform-skills
/plugin install power-automate@power-platform-skills

Microsoft’s repository also provides a cross-platform installer that can detect supported clients, install required Power Platform tooling, register the marketplace, and enable plugin updates. Review the script before running it, especially on managed devices.⁴

After installation, authenticate Azure CLI. If you are already signed in to another tenant, verify the active identity rather than assuming the agent will select the intended development environment:

az login

Then run the setup skill:

/setup What do I need to run the Power Automate plugin?

The goal of this preflight is simple: fail early on local prerequisites and authentication rather than halfway through flow creation.

Start with a controlled workspace

Create a dedicated project directory before you begin. Agentic clients may write plans, flow definitions, payload samples, or diagnostic notes to the current workspace.

mkdir PowerAutomate_Deployment
cd PowerAutomate_Deployment

A separate workspace gives you three practical benefits:

• generated artifacts are easy to inspect;
• secrets and unrelated files are less likely to enter the agent’s context;
• changes can be placed under version control before deployment.

GitHub Copilot CLI includes an autopilot mode that can continue without approval at every step.³ That can make multi-tool workflows smoother, but convenience changes the risk profile. Microsoft’s marketplace guidance warns that auto-approval gives the agent the same access you have on the machine.⁴

Build a flow from a precise specification

Suppose you want a feedback flow with three Microsoft Forms fields: Name, Email, and Feedback. When a response arrives, the flow should retrieve the response details, create a correctly mapped SharePoint list item, and send a notification email containing a direct link to that item. This is a useful end-to-end test because it exercises a trigger, dynamic content, two connectors, field mapping, link construction, and observable business output.

A weak prompt describes only the business intention:

/build-flow Save form responses to SharePoint and email me.

A better prompt supplies the identifiers and outcomes the agent would otherwise need to discover or ask about:

/build-flow When a response is submitted to [exact form name], retrieve the response details, create an item in [exact list name] at [exact site URL], map [form fields] to [list columns], and send [recipient] an email containing a direct link to the created item.

Use exact names, URLs, field mappings, and recipients. Also state important behavioral requirements, such as what should happen when an optional answer is empty or whether duplicate submissions must be prevented.

Still, do not assume that supplying names eliminates discovery. Connector operations have exact parameter schemas, and some values must be resolved dynamically. The plugin’s guided workflow is designed to inspect operation metadata and retrieve real values rather than guess parameter names or types.²

A sound build sequence looks like this:

1. Resolve the target environment.
2. Discover the required connectors and operations.
3. Verify that usable connections exist.
4. Resolve dynamic values such as sites, lists, forms, or channels.
5. Generate the flow definition and connection references.
6. Validate and preflight the definition.
7. Create or update the flow.
8. Publish and run a smoke test.
9. Inspect the run result and generated business output.

This is where MCP earns its keep. The agent is not merely writing JSON. It is closing the loop between intent, platform metadata, deployment, and observed execution.

Handle authentication and environment routing deliberately

FlowAgent uses your local Azure CLI sign-in. During connector authorization, the workflow may open a localhost callback in the operating system’s default browser. If that browser is signed in with the wrong Microsoft 365 profile, the authorization can fail even though another browser already has the correct session. Complete the authorization in the browser profile associated with the intended account. If you move a localhost callback URL between browser profiles, treat it as sensitive, use it only for that immediate sign-in, confirm that the success page appears, and do not store or share it.

Environment selection deserves the same care. A friendly display name is not always unique, and your default environment may not be the correct deployment target. Ask the agent to list or resolve environments, then verify the selected environment ID before allowing creation or update operations.

/route-environments Resolve the environment named [name], show its environment ID and tenant, and make it current only after I review the result.

Do not use model switching as the first fix for routing errors. Environment problems are usually better addressed by inspecting the authenticated account, tenant, permissions, environment identifiers, and current session state. A more capable model cannot compensate for the wrong identity or an inaccessible environment.

Verify the generated flow in the maker portal

An agent reporting that creation succeeded is not the same as proving that the automation works. Open the target environment in the Power Apps or Power Automate maker portal and inspect the generated flow before testing it.

For the Forms-to-SharePoint example, confirm that the designer contains the expected sequence:

1. When a new response is submitted points to the correct form.
2. Get response details uses the response ID from the trigger.
3. Create item targets the correct SharePoint site and list.
4. The Name, Email, and Feedback values map to the intended list columns.
5. Send an email addresses the intended recipient and builds a working link to the created item.

Then save the flow and submit a real test response through the form. Verify all three layers of evidence:

• Platform evidence: the run appears in history and every expected action succeeds.
• Data evidence: the SharePoint item contains the correct values.
• User-facing evidence: the notification arrives and its link opens the intended item.

This visual inspection is not busywork. It catches wrong-environment deployments, incorrect connection ownership, surprising mappings, and plausible-looking definitions that do not match the business requirement.

Debug failures with evidence, not screenshots alone

The plugin can inspect run history, run details, individual actions, loop iterations, past trigger inputs, and diagnostic results.¹ That means the best debugging input is usually the flow identity and failed run, not only a screenshot of the designer.

A screenshot that includes the failed action and error code can help the agent understand what you are seeing, especially in a multimodal client. Treat it as supporting context, not as the primary diagnostic record. Screenshots can omit collapsed details and may expose names, email addresses, or business data. The structured run record is more complete.

Start with a request such as:

/debug-flow Diagnose the latest failed run of [flow name] in [environment]. Identify the failing action, show the relevant input and output schema, propose the smallest safe change, and do not update the flow until I approve the plan.

A dependable debugging loop has five stages:

1. Identify the run. Confirm the environment, flow, run ID, status, and timestamp.
2. Inspect evidence. Retrieve the failed action’s inputs, outputs, error code, and surrounding control-flow context.
3. Explain the cause. Separate the platform error from the inferred root cause.
4. Preview the repair. Prefer the smallest action-level edit and review the proposed change.
5. Validate the result. Re-run, resubmit, or use an appropriate trigger emulator, then inspect the new run.

Typical causes include malformed expressions, unexpected nulls, JSON schema mismatches, invalid connection references, and dynamic values that differ between environments.

The tool surface supports resubmission, diagnosis, trigger-input retrieval, update previews, backups, and smoke tests.² Depending on the failure and available tools, the agent may resubmit the failed run or create a temporary test path to validate a repair. It may also clean up temporary test artifacts afterward. Treat those behaviors as actions to review, not guaranteed outcomes. The capabilities do not mean every failure can be repaired automatically or that replaying a trigger is safe. A resubmitted flow can create duplicate list items, send duplicate messages, or call an external system twice.

Where the approach is strong, and where it is not

This workflow is especially useful when:

• a flow spans several connectors;
• exact operation metadata is difficult to remember;
• you need repeatable validation and diagnostics;
• you manage multiple environments;
• or you want a reviewable, developer-oriented workspace around low-code assets.

It does not remove the need to understand Power Automate. You still need to recognize connector behavior, trigger semantics, expression rules, retry policies, concurrency, data shape, and side effects. The agent can accelerate discovery and execution, but the maker remains accountable for the resulting automation.

Claims such as “10x faster” should be treated as personal benchmarks unless supported by a defined test. Measure the workflow that matters to you: time to first successful run, number of manual corrections, failure rate, or time to diagnose a known defect.

Practical operating checklist

Before the first build:

• Use a dedicated local workspace.
• Sign in with the intended account and tenant.
• Resolve and verify the target environment.
• Confirm required connections are available.
• Start in a development environment.

Before deployment:

• Review the generated trigger and actions.
• Check connection references and dynamic values.
• Validate expressions and payload schemas.
• Preview updates and preserve a backup where supported.
• Confirm that the test cannot cause unwanted side effects.

After deployment:

• Inspect the actual run, not only the agent’s summary.
• Verify the SharePoint item, email, or other business output.
• Check for duplicate artifacts created by automated and manual validation runs.
• Record environment-specific assumptions.
• Keep manual recovery and rollback paths available.

The larger shift

The important development is not that an AI can describe a flow. It is that an agent can use a structured tool interface to discover the environment, retrieve connector metadata, create or edit the automation, and inspect the execution result.

That turns Power Automate authoring into an observable loop:

Intent -> Discovery -> Definition -> Validation -> Deployment -> Run evidence -> Repair

The visual designer is still valuable, especially for reviewing logic and explaining it to makers. MCP adds another interface, one optimized for tool-driven agents, repeatable procedures, and evidence-based debugging. Used carefully, it can shorten the distance between an automation idea and a verified flow without pretending that natural language removes the need for engineering judgment.

Sources