Skip to main content
Glama

Power Automate MCP Server by Flow Studio

Create or update flow

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

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.
expectedLastModifiedTimeNoWith a whole definition: refuse if the flow changed since you read it. Pass get_live_flow's lastModifiedTime.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • changedInput schema / properties / operations / items / properties / path / description
      Previous value: -"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."New value: +"Array of literal keys, one per level, e.g. [\"actions\",\"Compose\",\"inputs\"]. Inside an array, use the item index: [\"actions\",\"Condition\",\"expression\",\"and\",0]. 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."
    • addedInput schema / properties / operations / items / properties / path / items / oneOf
      Added value: +[
      +  {
      +    "type": "string"
      +  },
      +  {
      +    "minimum": 0,
      +    "type": "integer"
      +  }
      +]
    • removedInput schema / properties / operations / items / properties / path / items / type
      Removed value: -"string"
  2. Changed1 schema field changed
    • addedInput schema / properties / expectedLastModifiedTime
      Added value: +{
      +  "description": "With a whole definition: refuse if the flow changed since you read it. Pass get_live_flow's lastModifiedTime.",
      +  "type": "string"
      +}
  3. 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."
  4. 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."
  5. 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."
  6. 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"
      +}
  7. 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"
      -}
  8. 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"
  9. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Goes well beyond the annotations: explains that Power Automate rejects a PATCH with no flow content and that the tool re-saves the unchanged definition, that a connectionReferenceLogicalName save can return success without storing, that unreferenced connection references get pruned, and that ' #flowstudio-mcp' is appended to definition.description. These are exactly the non-obvious side effects an agent needs before a destructive write.

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?

Front-loaded with the create/update split, then organized under labeled modes (SURGICAL EDIT, WHOLE definition, RENAME). Dense but nearly every clause carries a decision rule; some statements about path arrays and connectionReferences duplicate the schema descriptions, which costs a point.

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 highly complex 8-parameter mutation tool with a nested operations object and no output schema, the description covers creation, update, rename, surgical edits, dry-run semantics, connection-reference edge cases, and the failure mode of empty PATCHes. An agent has enough to invoke it correctly without opening the schema.

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

Parameters4/5

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

Schema coverage is 100% so the baseline is 3, but the description adds cross-parameter rules the schema does not state at the top level: operations requires flowName, connectionReferences may accompany either path and wins on key collision, and dryRun behaves differently with and without flowName. Only expectedLastModifiedTime is left to the schema alone.

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?

Opens with a specific verb pair and resource ('Update or create a flow') and immediately distinguishes the two modes by parameter (omit flowName to create, provide it to update). The surgical-edit path is named as a distinct operation mode, so an agent can tell what this does versus get_live_flow or set_live_flow_state in the sibling list.

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?

Explicit when-to-use for every mode: dryRun for preview, omit flowName to create, flowName alone to rename, operations vs definition mutual exclusivity ('Provide EITHER operations OR definition'), and a recommended workflow ('call get_live_flow, mutate properties.definition, pass it here'). Alternatives and prerequisites are named rather than inferred.

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.