Build Power Automate Flows with MCP

Overview

Describe what you want in plain English. Your agent builds the flow definition, wires the connections, and deploys it to Power Automate. No portal, no drag-and-drop, no manual JSON editing.

This guide walks through how the build process works so you understand what your agent is doing behind the scenes.

What a flow definition looks like

Power Automate flows are stored as JSON. Understanding the structure helps you verify what your agent builds. Here is a simple flow with a manual trigger, a Compose action, and a Send Email action:

{
  "definition": {
    "triggers": {
      "manual": {
        "type": "Request",
        "kind": "Button",
        "inputs": { "schema": {} }
      }
    },
    "actions": {
      "Compose_Summary": {
        "type": "Compose",
        "inputs": "Monthly report generated on @{utcNow()}",
        "runAfter": {}
      },
      "Send_Email": {
        "type": "ApiConnection",
        "inputs": {
          "host": { "connection": { "name": "@parameters('$connections')['office365']['connectionId']" } },
          "method": "post",
          "path": "/v2/Mail",
          "body": {
            "To": "finance@contoso.com",
            "Subject": "Monthly Report",
            "Body": "@{outputs('Compose_Summary')}"
          }
        },
        "runAfter": { "Compose_Summary": [ "Succeeded" ] }
      }
    }
  }
}

Key parts to know:

• triggers — What starts the flow. Every flow has exactly one trigger
• actions — The steps the flow runs. Each action has a type (Compose, ApiConnection, Http, etc.) and inputs
• runAfter — Controls execution order. {} means the action runs first; { "Compose_Summary": [ "Succeeded" ] } means it waits for that action to succeed
• @parameters('$connections') — References to authenticated connectors in your environment

You do not need to write this JSON yourself. Your agent constructs it from your natural language description. But recognizing the structure lets you spot mistakes before deploying.

Before you start

This guide assumes you have already connected your agent to Flow Studio MCP. If not, follow Getting Started with Flow Studio MCP first.

How it works

Building a flow with MCP follows four steps:

1. Check for existing flows — Avoid creating duplicates
2. Discover connections — Find authenticated connectors in your environment
3. Build the definition — Construct the flow JSON (triggers, actions, parameters)
4. Deploy — Create or update the flow with a single MCP call
   
   

Step 1 - Check for existing flows

Before building, your agent should check if a flow with a similar name already exists. This prevents accidental duplicates.

“Do I already have a flow called Invoice Notifications?”

The agent calls list_live_flows and searches for a match. If the flow exists, the agent can modify it instead of creating a new one.

Step 2 - Discover connections

Every connector action in Power Automate (SharePoint, Teams, Outlook, etc.) needs an authenticated connection in your environment. Your agent discovers available connections automatically:

“What connections do I have in my default environment?”

The agent calls list_live_connections and returns all active connections with their connector names and IDs.

If a connection is missing

Connections require OAuth consent in a browser — no API can create them. If your agent reports a missing connection, you will need to create it manually:

1. Open make.powerautomate.com/connections
2. Select the correct environment from the top-right picker
3. Click + New connection for the missing connector
4. Sign in and authorize when prompted
5. Tell your agent when done — it will re-check and continue

Step 3 - Build the definition

Power Automate flows are JSON definitions. Your agent constructs the definition based on your description, using the correct action types and patterns for each connector.

Common building blocks your agent works with:

Triggers - What starts the flow

• Recurrence — Run on a schedule (e.g. every day, every hour)
• Request (HTTP) — Triggered by an HTTP POST
• When an item is created — SharePoint, Dataverse, or other connector events

Actions — What the flow does

• Compose — Transform data with expressions
• Connector actions — SharePoint (get/create items), Teams (post messages), Outlook (send email)
• Control flow — If/else conditions, Switch, Apply to each loops, Scope
• HTTP — Call external APIs directly

You do not need to know these patterns yourself — your agent handles the JSON construction. But understanding the building blocks helps you describe what you want more clearly.

Step 4 - Deploy

Once the definition is ready, your agent deploys it with a single call:

“Deploy the flow”

The agent calls update_live_flow with the definition and connection references. This tool handles both creation (new flows) and updates (existing flows).

If your organization requires flows to be part of a Dataverse solution, ask your agent to add it after deployment: “Add this flow to the [solution name] solution.”

Test the deployed flow

After deployment, verify the flow works. Ask your agent: “Trigger a test run of the flow and check the result.” For HTTP-triggered flows, the agent can call the trigger URL directly. For other triggers, you may need to trigger it manually and then ask the agent to check the run history. For a full debugging workflow, see Debug Power Automate Flows.

Example: build a notification flow

Here is a real example of building a flow through natural language:

1. “Build a flow that runs every Monday at 9 AM, checks a SharePoint list called Invoices for overdue items, and sends a Teams message to the Finance channel with the overdue count.”
2. The agent checks your connections (SharePoint and Teams must be available)
3. The agent constructs the definition with a Recurrence trigger, SharePoint Get Items action with a filter query, and a Teams Post Message action
4. The agent deploys the flow and reports the result

Modifying existing flows

Your agent can also modify flows that already exist:

• “Add an error notification to my HR Sync flow”
• “Change the schedule of my Daily Report flow to run at 8 AM instead of 6 AM”
• “Add a condition to skip weekends in my notification flow”

The agent reads the current definition with get_live_flow, makes the changes, and redeploys with update_live_flow.

Example: adding error handling

Suppose you have a document processing flow that uploads files to SharePoint but fails silently when the upload action errors. You can say:

“Add error handling to the SharePoint upload action in my Document Processing flow. If the upload fails, send me an email with the error details and the file name.”

The agent will:

1. Read the existing flow definition
2. Wrap the upload action in a Scope
3. Add a parallel branch that runs on failure with a Send Email action containing the error output
4. Redeploy the updated flow

Common connectors

Here are the connectors your agent works with most frequently:

Expression syntax gotchas

Power Automate expressions have quirks that trip up both humans and AI agents. If your agent-built flow fails with expression errors, check for these common mistakes:

• @triggerOutputs() vs @triggerBody() — @triggerOutputs() returns the full trigger output including headers; @triggerBody() returns just the body payload. Most flows want @triggerBody() for data access
• Referencing other actions — Use @actions('ActionName')?['outputs'] to get outputs from a previous action. The action name must match exactly, including spaces and underscores
• Type conversion — @json() parses a string into an object; @string() converts an object to a string. Mismatched types cause silent failures or cryptic errors
• Nested scope references — Actions inside an Apply_to_each or Scope block cannot be referenced directly from outside. Use @result('Scope_Name') to access the collected outputs
• Single quotes inside expressions — Single quotes must be doubled: @equals(variables('status'), 'it''s done'). Missing the doubled quote breaks the entire expression

Your agent handles most of these automatically, but knowing the patterns helps you troubleshoot when a deployed flow does not behave as expected.

What’s next

• Debug Power Automate Flows with MCP — When your flow does not work as expected
• MCP Tools Reference — Complete catalog of all build and deployment tools
• Copilot Agent Skills — Pre-built build skill for GitHub Copilot