Skip to main content
Glama

Power Automate MCP Server by Flow Studio

update_live_flow

DestructiveIdempotent

Update or create a flow. Use dryRun: true to preview any change without writing. Omit flowName to create: definition and displayName are required. Give flowName to update: displayName and/or definition and/or connectionReferences. SURGICAL EDIT: pass operations — an ordered list of set/add/remove/merge ops on array-of-keys paths — to change one action or parameter without resending the whole definition. Provide EITHER operations OR definition; connectionReferences may accompany either and lands in the same save. WHOLE definition: call get_live_flow, mutate properties.definition, pass it here. RENAME: pass displayName alone. Power Automate rejects a PATCH carrying no flow content, so this re-saves the unchanged definition — the maker portal does the same. definition.description is required, and must be brief — we append " #flowstudio-mcp" to it.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
dryRunNoPreview only, on BOTH paths: with flowName, apply the change to the live definition and return the result + what changed; without flowName, return the flow that WOULD be created. Nothing is written either way.
flowNameNoName (ID) of the flow to update. Omit or leave blank to create a new flow.
definitionNoFull flow definition as a JSON object (triggers + actions + parameters + outputs + description). MUST be a JSON object — strings are rejected. Do not JSON.stringify the definition; pass the parsed object directly. Required when creating. For updates, obtain from get_live_flow (properties.definition), modify it, then pass the modified object here. definition.description is required (a short note about what changed); when updating, if you omit it we reuse the flow's existing description.
operationsNoSURGICAL EDIT of an existing flow (requires flowName; do not combine with definition). An ordered list applied to the LIVE definition. Each item = { op, path, value? }. path is an ARRAY of literal keys, e.g. ["actions","Send_Email","inputs","parameters","subject"] (each element is one key; a "/" inside an element is literal, so it addresses SharePoint/Dataverse columns like ["actions","Update_Item","inputs","parameters","item/Title"]). ops: set (create/overwrite), add (new key — errors if it already exists), remove (delete key — no-op if absent), merge (deep-merge an object value, keeping sibling keys).
displayNameNoDisplay name for the flow. Required when creating.
environmentNameYesName of the Power Platform environment.
connectionReferencesNoConnection references map copied from get_live_flow. Direct-flow entries use { connectionName, id }. Solution-aware entries also include { connectionReferenceLogicalName, source } and must retain those fields exactly. A freshly migrated entry may instead be keyed by the physical connection name and carry no connectionName field at all — copy it back as-is. The action/trigger inputs.host.connectionName must match the map key; the physical connectionName stays inside the entry. Never invent a solution logical name. Adding a connectionReferenceLogicalName to an entry that lacks one does not always take: the save can return success without storing it, so re-read with get_live_flow to confirm. MAY BE PASSED ALONGSIDE operations: your entries are merged over the stored map and saved in the SAME request as the edit. That is how you add the first action for a connector the flow does not use yet — a reference saved on its own does not stick, because Power Automate prunes an entry no action references. Your entries win on a key collision.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / connectionReferences / description
      Previous value: -"Connection references map copied from get_live_flow. Direct-flow entries use { connectionName, id }. Solution-aware entries also include { connectionReferenceLogicalName, source } and must retain those fields exactly. A freshly migrated entry may instead be keyed by the physical connection name and carry no connectionName field at all — copy it back as-is. The action/trigger inputs.host.connectionName must match the map key; the physical connectionName stays inside the entry. Never invent a solution logical name. Adding a connectionReferenceLogicalName to an entry that lacks one does not always take: the save can return success without storing it, so re-read with get_live_flow to confirm."New value: +"Connection references map copied from get_live_flow. Direct-flow entries use { connectionName, id }. Solution-aware entries also include { connectionReferenceLogicalName, source } and must retain those fields exactly. A freshly migrated entry may instead be keyed by the physical connection name and carry no connectionName field at all — copy it back as-is. The action/trigger inputs.host.connectionName must match the map key; the physical connectionName stays inside the entry. Never invent a solution logical name. Adding a connectionReferenceLogicalName to an entry that lacks one does not always take: the save can return success without storing it, so re-read with get_live_flow to confirm. MAY BE PASSED ALONGSIDE operations: your entries are merged over the stored map and saved in the SAME request as the edit. That is how you add the first action for a connector the flow does not use yet — a reference saved on its own does not stick, because Power Automate prunes an entry no action references. Your entries win on a key collision."
  2. Changed1 schema field changed
    • changedInput schema / properties / dryRun / description
      Previous value: -"Preview only: apply the change to the live definition and return the result + what changed, WITHOUT writing."New value: +"Preview only, on BOTH paths: with flowName, apply the change to the live definition and return the result + what changed; without flowName, return the flow that WOULD be created. Nothing is written either way."
  3. Changed1 schema field changed
    • changedInput schema / properties / connectionReferences / description
      Previous value: -"Connection references map — keyed by logical name (e.g. shared_sharepointonline), each value is { connectionName, id }. Goes into properties.connectionReferences on the PA API call."New value: +"Connection references map copied from get_live_flow. Direct-flow entries use { connectionName, id }. Solution-aware entries also include { connectionReferenceLogicalName, source } and must retain those fields exactly. A freshly migrated entry may instead be keyed by the physical connection name and carry no connectionName field at all — copy it back as-is. The action/trigger inputs.host.connectionName must match the map key; the physical connectionName stays inside the entry. Never invent a solution logical name. Adding a connectionReferenceLogicalName to an entry that lacks one does not always take: the save can return success without storing it, so re-read with get_live_flow to confirm."
  4. Changed2 schema fields changed
    • addedInput schema / properties / dryRun
      Added value: +{
      +  "description": "Preview only: apply the change to the live definition and return the result + what changed, WITHOUT writing.",
      +  "type": "boolean"
      +}
    • addedInput schema / properties / operations
      Added value: +{
      +  "description": "SURGICAL EDIT of an existing flow (requires flowName; do not combine with definition). An ordered list applied to the LIVE definition. Each item = { op, path, value? }. path is an ARRAY of literal keys, e.g. [\"actions\",\"Send_Email\",\"inputs\",\"parameters\",\"subject\"] (each element is one key; a \"/\" inside an element is literal, so it addresses SharePoint/Dataverse columns like [\"actions\",\"Update_Item\",\"inputs\",\"parameters\",\"item/Title\"]). ops: set (create/overwrite), add (new key — errors if it already exists), remove (delete key — no-op if absent), merge (deep-merge an object value, keeping sibling keys).",
      +  "items": {
      +    "properties": {
      +      "op": {
      +        "description": "Edit verb.",
      +        "enum": [
      +          "set",
      +          "add",
      +          "remove",
      +          "merge"
      +        ],
      +        "type": "string"
      +      },
      +      "path": {
      +        "description": "Array of literal keys, one per level, e.g. [\"actions\",\"Compose\",\"inputs\"]. A \"/\" inside an element is a literal character, so SharePoint/Dataverse column params (flat keys like \"item/Title\") are addressable: [\"actions\",\"Update_Item\",\"inputs\",\"parameters\",\"item/Title\"]. Do NOT pass a slash-delimited string — it cannot distinguish a literal \"/\" from a separator.",
      +        "items": {
      +          "type": "string"
      +        },
      +        "type": "array"
      +      },
      +      "value": {
      +        "description": "New value (required for set/add/merge; merge requires an object)."
      +      }
      +    },
      +    "required": [
      +      "op",
      +      "path"
      +    ],
      +    "type": "object"
      +  },
      +  "type": "array"
      +}
  5. Changed2 schema fields changed
    • changedInput schema / properties / definition / description
      Previous value: -"Full flow definition as a JSON object (triggers + actions + parameters + outputs). MUST be a JSON object — strings are rejected. Do not JSON.stringify the definition; pass the parsed object directly. Required when creating. For updates, obtain from get_live_flow (properties.definition), modify it, then pass the modified object here."New value: +"Full flow definition as a JSON object (triggers + actions + parameters + outputs + description). MUST be a JSON object — strings are rejected. Do not JSON.stringify the definition; pass the parsed object directly. Required when creating. For updates, obtain from get_live_flow (properties.definition), modify it, then pass the modified object here. definition.description is required (a short note about what changed); when updating, if you omit it we reuse the flow's existing description."
    • removedInput schema / properties / description
      Removed value: -{
      -  "description": "Brief description of what is being changed or created. Required. Will be appended with \"Updated via Flow Studio MCP #flowstudio-mcp\" and stored as the flow description.",
      -  "type": "string"
      -}
  6. Changed2 schema fields changed
    • changedInput schema / properties / definition / description
      Previous value: -"Full flow definition object (triggers + actions + parameters + outputs). A JSON string is also accepted and will be parsed into an object. Required when creating. For updates, obtain from get_live_flow (properties.definition), modify it, then pass the modified version here."New value: +"Full flow definition as a JSON object (triggers + actions + parameters + outputs). MUST be a JSON object — strings are rejected. Do not JSON.stringify the definition; pass the parsed object directly. Required when creating. For updates, obtain from get_live_flow (properties.definition), modify it, then pass the modified object here."
    • changedInput schema / properties / definition / type
      Previous value: -[
      -  "object",
      -  "string"
      -]New value: +"object"
  7. First observed

TDQS

A4.9/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations mark this as destructive and idempotent, but the description adds substantial behavioral context: Power Automate's rejection of PATCH with no flow content, the forced re-save of unchanged definition for rename, the #flowstudio-mcp suffix on description, the requirement to re-read after adding a connectionReferenceLogicalName, and the merging behavior of connectionReferences. No contradictions with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but well-organized with visual emphasis (SURGICAL EDIT, WHOLE definition, RENAME) that front-loads key decisions. Every section carries essential information for a complex tool, and there is negligible redundancy. It could be condensed slightly, but the density is justified by the many modes and edge cases.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with high complexity, no output schema, and many nuanced behaviors, the description covers all critical aspects: the create/update distinction, dryRun behavior, the two update paths, rename handling, connection reference quirks, and the description suffix requirement. The only minor gap is a lack of explicit return-value description, but the schema's dryRun description already covers that, and the tool's purpose implies the return.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Despite 100% schema coverage, the description significantly enhances parameter understanding: it clarifies that definition must be a parsed object (not stringified), details the path array semantics for literal '/' and how to address SharePoint/Dataverse columns, explains the meaning of each operation (set/add/remove/merge), and describes the exact structure required for connectionReferences. It adds far more than the schema provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with 'Update or create a flow', using a specific verb and resource, and immediately distinguishes the two modes based on flowName presence. It further differentiates from siblings (e.g., update_store_flow) by explicitly focusing on live flows, and explains the surgical-edit vs whole-definition approaches, making the tool's purpose unmistakable.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit when-to-use guidance: dryRun for previewing, get_live_flow for whole definition edits, displayName alone for rename, and clearly states 'Provide EITHER operations OR definition' and that operations requires flowName. It also implicitly excludes use for store flows by naming live-flow siblings. Highly actionable.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.