Skip to main content
Glama
power-automate-mcp

power-automate-mcp

by OwnOptic

bind_connection

Idempotent

Resolve and bind an existing environment connection to a flow's definition, then start it, completing headless flow creation that leaves connection references empty.

Instructions

Bind an existing connection to a flow and start it. The missing step of create_flow.

This is the tool that makes headless connector-flow creation actually work. create_flow returns 201 but leaves connectionReferences empty, and the flow cannot be started ("CannotStartUnpublishedSolutionFlow"). Binding is a separate PATCH that has to carry both the full definition AND the connection reference. This tool does the whole three-step sequence in one call:

1. resolve the connection      (which connectionName for this connector?)
2. PATCH definition + reference
3. start the flow

connector is the connector's logical name, e.g. "shared_office365", "shared_teams", "shared_sharepointonline".

connection_name is the concrete connection id. In the environments measured it is a bare 32-hex GUID ("4f9d05ecf89048a09f58d4f8f718785e"), not "shared-office365-...". Leave it empty and the tool resolves it automatically from the environment's connection list, so a connection created in the portal a minute ago is found even though no flow uses it yet. Only Connected connections count. If several match, it does NOT guess: it returns status "ambiguous" with display names and created times so you can pass one explicitly (the newest is usually the one just created).

THE CONNECTION MUST ALREADY EXIST in the environment. No API reachable with a Flow token can create and authenticate a brand new connection - that is a portal action. If none is found this returns status "not_found" rather than failing, with create_url pointing at the portal Connections page: give the user that link.

A flow with several connectors (say Dataverse + Outlook) is bound in ONE call: name any one of them, and the tool resolves the others by the same rule and saves them together, because the API rejects a save that leaves any connector action unbound. If one is missing it binds nothing and returns status "incomplete", listing each unresolved connector with a create_url. Existing bindings are merged, never dropped.

Does NOT work on solution flows: their connections are Dataverse connection references, which cannot be minted here. Bind those in the portal, or edit the stored definition with update_solution_flow_definition in extras.py.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "flow_id": "<flow_id>",
      "connector": "<connector>"
    },
    "name": "bind_connection"
  }
}

Input Schema

NameRequiredDescriptionDefault
startNo
flow_idYes
connectorYes
connection_nameNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv2.1.0

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only cover safety hints (readOnlyHint=false, idempotentHint=true, destructiveHint=false), while the description discloses the three step behavior, that a PATCH carries definition plus reference, non-exception status returns ('ambiguous', 'not_found', 'incomplete') with their payload contents, merge-don't-drop semantics for existing bindings, and the platform rule that unbound connectors block the save. This is well beyond what any structured field conveys.

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?

It is long, but front-loaded with the purpose and a numbered three-step list, and most paragraphs map to a distinct failure mode or parameter. A few lines are promotional filler ('actually work', 'the newest is usually the one just created'), which keeps it from a 5.

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 multi-step mutating tool with four params, no output schema and no schema descriptions, the description covers the sequence, all likely non-success statuses and what to do with them, multi-connector binding, merge behavior, and the solution-flow limitation. Nothing an agent needs to invoke it safely is missing.

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 description coverage is 0%, so the description must carry parameter meaning, and it does for the two non-obvious ones: connector as the logical name with concrete examples ('shared_office365') and connection_name as a bare 32-hex GUID with an empty-string auto-resolve rule and ambiguity behavior. It says nothing about the 'start' boolean (default true) or flow_id, leaving the agent to infer that start=false skips step 3.

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 first sentence gives a specific verb and resource (bind an existing connection to a flow and start it) and the second frames it relative to create_flow as 'the missing step'. It also distinguishes itself from update_flow_definition by naming that sibling for the solution-flow case, so an agent can pick correctly without opening schemas.

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?

Usage is explicit and bounded: use after create_flow returns 201 with empty connectionReferences, leave connection_name empty to auto-resolve, and do NOT use on solution flows — bind those in the portal or via update_solution_flow_definition. The prerequisite (the connection must already exist in the environment) and the fallback action (hand the user the create_url) are both stated.

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